From arapte at openjdk.org  Thu Aug  1 07:40:38 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 1 Aug 2024 07:40:38 GMT
Subject: RFR: 8337281: build.gradle assumes all modules are named
 "javafx.$project" [v2]
In-Reply-To: <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
References: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
 <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
Message-ID: <_P_IUaD4-_qQWpkheLy7oQuq0nYvdVnFVvZ2ockqa3c=.4fefc17b-c9b0-4bcc-b4be-1d9a7bd7508f@github.com>

On Fri, 26 Jul 2024 23:00:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced.
>> 
>> I discovered this while working on the following two RFEs, both of which hit this bug:
>> 
>> [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules
>> [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX
>> 
>> Both of them need this bug to be fixed, so I am separating it out into its own issue.
>> 
>> ### Notes to reviewers
>> 
>> Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit.
>> 
>> I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug where String was being used as if it were a Project

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1518#pullrequestreview-2211882793

From jvos at openjdk.org  Thu Aug  1 08:46:05 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 08:46:05 GMT
Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never
 being removed
Message-ID: <jQjKySrRhVwx496Pve3a_By5gxsVbjkDaEzg4_pGUWw=.af078246-b039-454f-b28e-8b566c45d50b@github.com>

Backport of  8323787: Mac System MenuBar throws IOB exception

Required manual changes as the location of the test has changed.

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

Commit messages:
 - 8319779: SystemMenu: memory leak due to listener never being removed

Changes: https://git.openjdk.org/jfx21u/pull/63/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=63&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319779
  Stats: 603 lines in 5 files changed: 462 ins; 132 del; 9 mod
  Patch: https://git.openjdk.org/jfx21u/pull/63.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/63/head:pull/63

PR: https://git.openjdk.org/jfx21u/pull/63

From jvos at openjdk.org  Thu Aug  1 08:53:11 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 08:53:11 GMT
Subject: [jfx21u] RFR: 8334874: Horizontal scroll events from touch pads should
 scroll the TabPane tabs
Message-ID: <qa8vtgWKVBXdm3-Ps4j6QGQajEpyUdx4MEoNxw_RLg4=.ef3a1cea-61f6-424b-9cfb-46dbebc4aaa4@github.com>

Almost clean backport of JDK-8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs
The only change was the (c) date that had changed.

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

Commit messages:
 - 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs

Changes: https://git.openjdk.org/jfx21u/pull/64/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=64&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334874
  Stats: 111 lines in 2 files changed: 107 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx21u/pull/64.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/64/head:pull/64

PR: https://git.openjdk.org/jfx21u/pull/64

From jvos at openjdk.org  Thu Aug  1 09:32:06 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 09:32:06 GMT
Subject: [jfx21u] RFR: 8318841: macOS: Memory leak with MenuItem when
 Menu.useSystemMenuBar(true) is used
Message-ID: <UF6n9aoOwU4ViiHhEddWgmyzoMGPr6BOiGhrhdFnA8o=.8370c3d1-ff60-4196-826f-5d0c35eda328@github.com>

8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used

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

Commit messages:
 - Backport 8dd3c37cae3dd52dc3a258033d0e8f168ceaf307

Changes: https://git.openjdk.org/jfx21u/pull/65/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=65&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318841
  Stats: 80 lines in 4 files changed: 80 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/65.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/65/head:pull/65

PR: https://git.openjdk.org/jfx21u/pull/65

From jvos at openjdk.org  Thu Aug  1 09:53:37 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 09:53:37 GMT
Subject: [jfx21u] Integrated: 8318841: macOS: Memory leak with MenuItem when
 Menu.useSystemMenuBar(true) is used
In-Reply-To: <UF6n9aoOwU4ViiHhEddWgmyzoMGPr6BOiGhrhdFnA8o=.8370c3d1-ff60-4196-826f-5d0c35eda328@github.com>
References: <UF6n9aoOwU4ViiHhEddWgmyzoMGPr6BOiGhrhdFnA8o=.8370c3d1-ff60-4196-826f-5d0c35eda328@github.com>
Message-ID: <gemL1JxAbh7Kpn0mPUlsFK48NzVogxf-27luz1o5X8k=.56a05327-2929-4353-b497-cdaf68f5879d@github.com>

On Thu, 1 Aug 2024 09:23:42 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used

This pull request has now been integrated.

Changeset: e6f725f5
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/e6f725f59a801805bab090387685907fe30e1fff
Stats:     80 lines in 4 files changed: 80 ins; 0 del; 0 mod

8318841: macOS: Memory leak with MenuItem when Menu.useSystemMenuBar(true) is used

Backport-of: 8dd3c37cae3dd52dc3a258033d0e8f168ceaf307

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

PR: https://git.openjdk.org/jfx21u/pull/65

From jvos at openjdk.org  Thu Aug  1 10:09:40 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 10:09:40 GMT
Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener
 never being removed
In-Reply-To: <jQjKySrRhVwx496Pve3a_By5gxsVbjkDaEzg4_pGUWw=.af078246-b039-454f-b28e-8b566c45d50b@github.com>
References: <jQjKySrRhVwx496Pve3a_By5gxsVbjkDaEzg4_pGUWw=.af078246-b039-454f-b28e-8b566c45d50b@github.com>
Message-ID: <-KaT5Zrp47Ap-7ymnGYwaXGBdBDAl2p8nP9CzLzXvFc=.590270ef-d033-4ce1-8588-1771c3d44af4@github.com>

On Thu, 1 Aug 2024 08:41:59 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Backport of  8323787: Mac System MenuBar throws IOB exception
> 
> Required manual changes as the location of the test has changed.

closed in favor of #66

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

PR Comment: https://git.openjdk.org/jfx21u/pull/63#issuecomment-2262658260

From jvos at openjdk.org  Thu Aug  1 10:09:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 10:09:41 GMT
Subject: [jfx21u] Withdrawn: 8319779: SystemMenu: memory leak due to listener
 never being removed
In-Reply-To: <jQjKySrRhVwx496Pve3a_By5gxsVbjkDaEzg4_pGUWw=.af078246-b039-454f-b28e-8b566c45d50b@github.com>
References: <jQjKySrRhVwx496Pve3a_By5gxsVbjkDaEzg4_pGUWw=.af078246-b039-454f-b28e-8b566c45d50b@github.com>
Message-ID: <d9j6D9gQIkr2dVvVak6iSZnllKNBrgrJ10PbHW5DBOU=.3fec650c-b7ea-4b7d-82bb-d726548d9e9a@github.com>

On Thu, 1 Aug 2024 08:41:59 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Backport of  8323787: Mac System MenuBar throws IOB exception
> 
> Required manual changes as the location of the test has changed.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx21u/pull/63

From jvos at openjdk.org  Thu Aug  1 10:09:52 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 10:09:52 GMT
Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener never
 being removed
Message-ID: <FcmaGbZCNDLbMR-qzPBpVdnxFIhDR4YLUlAjpRDrKFQ=.dbc3bd45-1c87-4ff0-be82-9f4bbb0cc288@github.com>

almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed
Didn't apply clean because the imports where shuffled.

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

Commit messages:
 - Backport 25ac6fed22d0f49d01c831aaa48049c34899fe96

Changes: https://git.openjdk.org/jfx21u/pull/66/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=66&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319779
  Stats: 667 lines in 5 files changed: 462 ins; 196 del; 9 mod
  Patch: https://git.openjdk.org/jfx21u/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/66/head:pull/66

PR: https://git.openjdk.org/jfx21u/pull/66

From jvos at openjdk.org  Thu Aug  1 10:25:36 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 10:25:36 GMT
Subject: [jfx21u] Integrated: 8334874: Horizontal scroll events from touch pads
 should scroll the TabPane tabs
In-Reply-To: <qa8vtgWKVBXdm3-Ps4j6QGQajEpyUdx4MEoNxw_RLg4=.ef3a1cea-61f6-424b-9cfb-46dbebc4aaa4@github.com>
References: <qa8vtgWKVBXdm3-Ps4j6QGQajEpyUdx4MEoNxw_RLg4=.ef3a1cea-61f6-424b-9cfb-46dbebc4aaa4@github.com>
Message-ID: <u-Ah8mkrSCDNEBMtHctM-LoBw8wPw7zwxudvb45q6G4=.67169139-941e-4bdc-bfeb-bda01c4ef8db@github.com>

On Thu, 1 Aug 2024 08:47:38 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs
> The only change was the (c) date that had changed.

This pull request has now been integrated.

Changeset: 29aa85ab
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/29aa85ab2a2c624db9f84e05eaff51ee3b9e248a
Stats:     111 lines in 2 files changed: 107 ins; 0 del; 4 mod

8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs

Backport-of: 1bdb93c792cf7c218c74ec5cacda8bac1242f73b

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

PR: https://git.openjdk.org/jfx21u/pull/64

From jpereda at openjdk.org  Thu Aug  1 10:26:34 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 1 Aug 2024 10:26:34 GMT
Subject: [jfx21u] RFR: 8319779: SystemMenu: memory leak due to listener
 never being removed
In-Reply-To: <FcmaGbZCNDLbMR-qzPBpVdnxFIhDR4YLUlAjpRDrKFQ=.dbc3bd45-1c87-4ff0-be82-9f4bbb0cc288@github.com>
References: <FcmaGbZCNDLbMR-qzPBpVdnxFIhDR4YLUlAjpRDrKFQ=.dbc3bd45-1c87-4ff0-be82-9f4bbb0cc288@github.com>
Message-ID: <V_B2xvq1aNf1FlvhtUWND-lvw7Ge9VtMkHS-Ye2hxdc=.31c03fcf-e4f0-4da5-a1db-5123068740c8@github.com>

On Thu, 1 Aug 2024 10:04:12 GMT, Johan Vos <jvos at openjdk.org> wrote:

> almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed
> Didn't apply clean because the imports where shuffled.

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/66#pullrequestreview-2212342712

From jvos at openjdk.org  Thu Aug  1 10:36:39 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 1 Aug 2024 10:36:39 GMT
Subject: [jfx21u] Integrated: 8319779: SystemMenu: memory leak due to listener
 never being removed
In-Reply-To: <FcmaGbZCNDLbMR-qzPBpVdnxFIhDR4YLUlAjpRDrKFQ=.dbc3bd45-1c87-4ff0-be82-9f4bbb0cc288@github.com>
References: <FcmaGbZCNDLbMR-qzPBpVdnxFIhDR4YLUlAjpRDrKFQ=.dbc3bd45-1c87-4ff0-be82-9f4bbb0cc288@github.com>
Message-ID: <D6jerYW4_1N00bhKct62N-JM88Wz59NIlxbwbe8_5rA=.a9b08217-fa5a-4cd4-9156-41bdbd7e121e@github.com>

On Thu, 1 Aug 2024 10:04:12 GMT, Johan Vos <jvos at openjdk.org> wrote:

> almost clean backport of 8319779: SystemMenu: memory leak due to listener never being removed
> Didn't apply clean because the imports where shuffled.

This pull request has now been integrated.

Changeset: ef8397aa
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/ef8397aa4886c2d1ac38b44a45c6adee3269827a
Stats:     667 lines in 5 files changed: 462 ins; 196 del; 9 mod

8319779: SystemMenu: memory leak due to listener never being removed
8323787: Mac System MenuBar throws IOB exception

Reviewed-by: jpereda
Backport-of: 25ac6fed22d0f49d01c831aaa48049c34899fe96

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

PR: https://git.openjdk.org/jfx21u/pull/66

From fkirmaier at openjdk.org  Thu Aug  1 11:45:05 2024
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 1 Aug 2024 11:45:05 GMT
Subject: RFR: 8337656 iOS WebView Position
Message-ID: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>

Fixing WebView on iOS
(I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.)

@johanvos 
If this looks reasonable to you, can you provide a test build for @dlemmermann ?
Then he can test it with his JFX-Central iOS version.

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

Commit messages:
 - JDK-8337656-ios-webview-position
 - JDK-8337656-ios-webview-position

Changes: https://git.openjdk.org/jfx/pull/1526/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337656
  Stats: 9 lines in 1 file changed: 1 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1526.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1526/head:pull/1526

PR: https://git.openjdk.org/jfx/pull/1526

From angorya at openjdk.org  Thu Aug  1 15:14:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 15:14:41 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Added debug trace for formats. Disabled by default.

This might sound silly, but these formats seem to differ by the way color bits are laid out in memory - would it be possible to write a utility that does the direct conversion instead of calling two conversion methods?

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2263322069

From duke at openjdk.org  Thu Aug  1 17:03:47 2024
From: duke at openjdk.org (8Mi_Yile)
Date: Thu, 1 Aug 2024 17:03:47 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <FWwyClBajZVhlfZ-jpXdpKfrMZTVK7dSEQ_zrQwffRg=.77fcddec-6479-454d-95d2-2abae8c6b0af@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

pls test and accept this pr
can use this [app](https://github.com/HMCL-dev/HMCL/releases) test this fix

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2263531801

From angorya at openjdk.org  Thu Aug  1 17:19:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 17:19:43 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <FWwyClBajZVhlfZ-jpXdpKfrMZTVK7dSEQ_zrQwffRg=.77fcddec-6479-454d-95d2-2abae8c6b0af@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <FWwyClBajZVhlfZ-jpXdpKfrMZTVK7dSEQ_zrQwffRg=.77fcddec-6479-454d-95d2-2abae8c6b0af@github.com>
Message-ID: <6AxPpiiKIhuGEc3s0obVTv5klMcEiQiVOXgtgQRpNoo=.ad27a3e3-f7fd-4afe-8446-ed6eb5e4e736@github.com>

On Thu, 1 Aug 2024 16:57:40 GMT, 8Mi_Yile <duke at openjdk.org> wrote:

> pls test and accept this pr can use this [app](https://github.com/HMCL-dev/HMCL/releases) test this fix

@8MiYile : are you saying that the proposed fix works with this app?  Would you provide more information on which platform(s) you've tested, how, and whether there were any issues?

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2263569079

From angorya at openjdk.org  Thu Aug  1 18:18:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 18:18:36 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v4]
In-Reply-To: <VIbTLg5rE-xl4vmeLRkjEzK0j24B36-szo7Gn-wfQtU=.4be08c36-ebdb-4137-9e0e-61332f633aa7@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <VIbTLg5rE-xl4vmeLRkjEzK0j24B36-szo7Gn-wfQtU=.4be08c36-ebdb-4137-9e0e-61332f633aa7@github.com>
Message-ID: <rH9MIIXZl5P48NO5C10QLydig5W-1yvV7UmBeiYr52o=.1c938738-b3d0-4af0-b140-d88f21a2fab0@github.com>

On Tue, 30 Jul 2024 23:34:13 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comments concerning the AWT Robot

The reproducer in the ticket fails without the fix and works as described on 2021 macOS 14.5 M1, using built-in retina and an external Samsung LS27A600U display (which seems to have a different color profile).

I would like to request a change for SRGBTest.COMPONENT_TOLERANCE value (or comment), please see inline comments.

modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m line 423:

> 421:                         components[1] = (CGFloat)((color & 0x0000FF00) >> 8) / 255.0;
> 422:                         components[2] = (CGFloat)((color & 0x000000FF)) / 255.0;
> 423:                         components[3] = (CGFloat)((color & 0xFF000000) >> 24) / 255.0;

is this line guaranteed not to produce negative values?  e.g. when `color = 0xffffffff`

tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 100:

> 98:     // An AWT Robot is color space aware and will correctly convert from the
> 99:     // screeen's color space to sRGB. We use one to verify that the JavaFX
> 100:     // Robot is performing the same conversions.

this comment is much clearer, thank you!

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

PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2213465658
PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700569990
PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700605558

From angorya at openjdk.org  Thu Aug  1 18:18:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 18:18:38 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v3]
In-Reply-To: <UL_GviXoub1EDlVIGNIQDpn8rlhfFMZmbk7ZyX2iXWM=.7c2a948f-537c-4eca-9d25-32b271fa74dc@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <gIyVwJ7kxRblfUhkwXwlGY-3qV-0kO59vJemeAPW7as=.fde64a88-d988-48b7-a600-bb16d270c216@github.com>
 <UEq_fF9zUMd_XJrvznW4jXIpVgi3rMhgvcsvmaUPWbQ=.39bafe32-300c-4a71-98ee-87882aff5e4d@github.com>
 <UL_GviXoub1EDlVIGNIQDpn8rlhfFMZmbk7ZyX2iXWM=.7c2a948f-537c-4eca-9d25-32b271fa74dc@github.com>
Message-ID: <Cri6HmxZ09v9H5aD5ueBwXiYVHFuc3_D7jk16DVTa8g=.6256fb62-c7db-4473-b4c2-041605790ca8@github.com>

On Tue, 30 Jul 2024 23:31:38 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 52:
>> 
>>> 50: 
>>> 51: import org.junit.Test;
>>> 52: import static org.junit.Assume.assumeTrue;
>> 
>> should we use junit5 for the new tests?
>
> This test is based on the VisualTestBase test harness class which is written using junit4. I use that test harness since it contains waitFirstFrame and waitNextFrame as well as existing utility routines for reporting on color mismatches.

you are right, please disregard.

>> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 68:
>> 
>>> 66:     // The component tolerance allows one bit of rounding when writing a color
>>> 67:     // out and another bit when reading it back in.
>>> 68:     static final double COMPONENT_TOLERANCE = 2.0 / 255.0;
>> 
>> suggestion: 2.0001 / 255.0 to account for floating point errors
>
> I'm not sure this test needs to be that precise. And I'm fine with the threshold falling below 2.0/255.0 since it should be as small as possible (I even experimented briefly with lower numbers). I haven't run into an issue on the three platforms I've run this test on.

Then the comment might not be technically correct, because it is possible to have "two bit difference" in the integer color values, yet fail due to small error intrinsic in floating point operations.

Example:

a=253 b=251 delta=0.007843137254902044 tol=0.00784313725490196

delta=0.007843137254902044
  tol=0.00784313725490196  (2.0 / 255.0)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700570982
PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700598001

From mfox at openjdk.org  Thu Aug  1 19:51:09 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 1 Aug 2024 19:51:09 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
Message-ID: <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>

> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
> 
> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
> 
> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
> 
> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
> 
> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback: floating point precision in test, ensure unsigned int handling in Robot

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1473/files
  - new: https://git.openjdk.org/jfx/pull/1473/files/20c23759..2dad883c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=03-04

  Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1473.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1473/head:pull/1473

PR: https://git.openjdk.org/jfx/pull/1473

From mfox at openjdk.org  Thu Aug  1 19:51:09 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 1 Aug 2024 19:51:09 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v4]
In-Reply-To: <rH9MIIXZl5P48NO5C10QLydig5W-1yvV7UmBeiYr52o=.1c938738-b3d0-4af0-b140-d88f21a2fab0@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <VIbTLg5rE-xl4vmeLRkjEzK0j24B36-szo7Gn-wfQtU=.4be08c36-ebdb-4137-9e0e-61332f633aa7@github.com>
 <rH9MIIXZl5P48NO5C10QLydig5W-1yvV7UmBeiYr52o=.1c938738-b3d0-4af0-b140-d88f21a2fab0@github.com>
Message-ID: <fuc2TPjCI2-NYN2WGaCQLoc54IURqd1mqubEBlFyy3E=.59b8b9e8-f181-4ebc-bb98-5016c97fb462@github.com>

On Thu, 1 Aug 2024 17:42:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comments concerning the AWT Robot
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m line 423:
> 
>> 421:                         components[1] = (CGFloat)((color & 0x0000FF00) >> 8) / 255.0;
>> 422:                         components[2] = (CGFloat)((color & 0x000000FF)) / 255.0;
>> 423:                         components[3] = (CGFloat)((color & 0xFF000000) >> 24) / 255.0;
> 
> is this line guaranteed not to produce negative values?  e.g. when `color = 0xffffffff`

Good catch. I've updated the code to read the pixel value into an unsigned integer.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700742971

From mfox at openjdk.org  Thu Aug  1 19:51:09 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 1 Aug 2024 19:51:09 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v3]
In-Reply-To: <Cri6HmxZ09v9H5aD5ueBwXiYVHFuc3_D7jk16DVTa8g=.6256fb62-c7db-4473-b4c2-041605790ca8@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <gIyVwJ7kxRblfUhkwXwlGY-3qV-0kO59vJemeAPW7as=.fde64a88-d988-48b7-a600-bb16d270c216@github.com>
 <UEq_fF9zUMd_XJrvznW4jXIpVgi3rMhgvcsvmaUPWbQ=.39bafe32-300c-4a71-98ee-87882aff5e4d@github.com>
 <UL_GviXoub1EDlVIGNIQDpn8rlhfFMZmbk7ZyX2iXWM=.7c2a948f-537c-4eca-9d25-32b271fa74dc@github.com>
 <Cri6HmxZ09v9H5aD5ueBwXiYVHFuc3_D7jk16DVTa8g=.6256fb62-c7db-4473-b4c2-041605790ca8@github.com>
Message-ID: <UoNH1YEJErMWCYCEBgKrrRCG2ksUPoQQxaHgAIZikb4=.966b35c3-c2af-45ab-bb1a-485b6b0c818a@github.com>

On Thu, 1 Aug 2024 18:02:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I'm not sure this test needs to be that precise. And I'm fine with the threshold falling below 2.0/255.0 since it should be as small as possible (I even experimented briefly with lower numbers). I haven't run into an issue on the three platforms I've run this test on.
>
> Then the comment might not be technically correct, because it is possible to have "two bit difference" in the integer color values, yet fail due to small error intrinsic in floating point operations.
> 
> Example:
> 
> a=253 b=251 delta=0.007843137254902044 tol=0.00784313725490196
> 
> delta=0.007843137254902044
>   tol=0.00784313725490196  (2.0 / 255.0)

I've updated the constant as you suggested.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1700739626

From angorya at openjdk.org  Thu Aug  1 19:55:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 19:55:35 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
Message-ID: <h5O2mMFB6xODCpKjez0l1VeDXXEK7sbjTG0FGiZeE9Y=.b816da3a-61b4-45f3-8a1a-1b549b74622b@github.com>

On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: floating point precision in test, ensure unsigned int handling in Robot

retested, looks good.
thank you for the meticulously commented unit tests!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2213781126

From almatvee at openjdk.org  Thu Aug  1 20:52:36 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 1 Aug 2024 20:52:36 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
Message-ID: <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>

On Thu, 1 Aug 2024 15:12:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This might sound silly, but these formats seem to differ by the way color bits are laid out in memory - would it be possible to write a utility that does the direct conversion instead of calling two conversion methods?

NV12 and IYUV are different in memory layout only, but P010 is 10-bit per pixel and NV12 is 8-bit per pixel. I filed enhancement request https://bugs.openjdk.org/browse/JDK-8337686 to support P010 and NV12 directly by Graphics. I think it is better approach, then doing conversion in Media. For now this approach is good enough until JDK-8337686 is implemented.

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2263960073

From angorya at openjdk.org  Thu Aug  1 21:24:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 21:24:35 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
 <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>
Message-ID: <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com>

On Thu, 1 Aug 2024 20:49:35 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> JDK-8337686

thank you for filing the RFE.  Should JDK-8337686 explicitly specify that the double conversion introduced  in this PR be replaced?

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264025287

From kcr at openjdk.org  Thu Aug  1 22:13:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 22:13:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
Message-ID: <l20KynKISqlNOEx0Rozz27gvjpkfbVh_3ZxDqou9yxo=.483dc7b2-c752-463b-b908-c4f70d6fa316@github.com>

On Wed, 31 Jul 2024 19:34:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed a bug

I note that PR #1471 was originally proposed to address this. Can you highlight the differences? Are any of the comments added to that PR still relevant?

I also note that [JDK-8226911](https://bugs.openjdk.org/browse/JDK-8226911) was added as an issue to the original PR? Should it also be added here?

I'd like a review by at least two with a "Reviewer" role in addition to the CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2264099474

From angorya at openjdk.org  Thu Aug  1 22:25:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 22:25:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <NdNgGQyrH7iS6tAQweqbQkqDFQEj-kgCwb822cIzW8c=.5e12c217-798e-44ec-bd36-cda60cb9bd5d@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

how do I set 3 reviewers and at least 2 "R"eviewers?

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2264115220

From kizune at openjdk.org  Thu Aug  1 22:41:05 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 1 Aug 2024 22:41:05 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
Message-ID: <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>

> Initial implementation of the protocol.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1507/files
  - new: https://git.openjdk.org/jfx/pull/1507/files/ce4cc10b..aeedf36f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=01-02

  Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1507.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1507/head:pull/1507

PR: https://git.openjdk.org/jfx/pull/1507

From kcr at openjdk.org  Thu Aug  1 22:43:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 22:43:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <NdNgGQyrH7iS6tAQweqbQkqDFQEj-kgCwb822cIzW8c=.5e12c217-798e-44ec-bd36-cda60cb9bd5d@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <NdNgGQyrH7iS6tAQweqbQkqDFQEj-kgCwb822cIzW8c=.5e12c217-798e-44ec-bd36-cda60cb9bd5d@github.com>
Message-ID: <4RRw8Xsqq0p_P7DOIU3BTpVfKym2v6crTMC7ra7NlDc=.e11ad5df-e709-495a-ab83-74e4d8875b71@github.com>

On Thu, 1 Aug 2024 22:22:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> how do I set 3 reviewers and at least 2 "R"eviewers?

You can't. You can set it to `/reviewers 2 reviewers` and ask others to also review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2264139892

From kizune at openjdk.org  Thu Aug  1 22:44:37 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 1 Aug 2024 22:44:37 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
Message-ID: <OPwVW4iL--DiqHbkMR462SAdcxdQEqO-BzofBEOv0Zw=.e5944e3e-d1a3-4669-bbf2-77dff6538188@github.com>

On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation of the protocol.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested.

Fixed the crash by eliminating request to unsupported type of metadata.

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

PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2264140752

From kcr at openjdk.org  Thu Aug  1 22:45:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 22:45:35 GMT
Subject: RFR: 8320232: Cells duplicated when table collapsed and expanded
In-Reply-To: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
References: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
Message-ID: <YTLGne9fdRAX-IX-ocM3metICSA9Uukmao6SEVGzzxs=.131214a0-5c72-4960-913a-07a8c228f02f@github.com>

On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing.
> 
> The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. 
> This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node).
> 
> The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells.
> So before we clear the pile (or cells), we always reset the index to -1.
> Added a bunch of tests, some pass before and after.

Looks good. I confirm that 3 of the newly-added test methods fail without the fix and pass with the fix.

I agree with Andy about the unrelated change. I'll reapprove if you fix it.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1521#pullrequestreview-2214160824

From kcr at openjdk.org  Thu Aug  1 22:48:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 22:48:37 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <lYfDJ-ZfoAP1h3kGxE-yqkrQMKOSuX8oYy63pRrwwA4=.c1fe6e01-4190-47ce-9473-25a8e70a0f97@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

I've noticed a few Ubuntu 24.04 failures both on Xorg and on Wayland. I'll test them with this patch.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2264145178

From kcr at openjdk.org  Thu Aug  1 22:49:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 22:49:36 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2]
In-Reply-To: <tRiNP7y_lNxPEcAU-3CiBk2QVCTDI2mPpQl71pl06nU=.5318c6a1-b03b-413a-92cd-f5050aa6bed7@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com>
 <IbAD0kcuWw5-zaHe_R3c_5XkAex9l4dbI7Xv30zvyE8=.23a8d437-cd89-43b3-8684-914d81413651@github.com>
 <LRcIp-W_wsS1zxzbyRImBFFOWxLiPN80Cgaz8gqAFNs=.f670a12a-595f-48f4-8f19-3053d5be9ddd@github.com>
 <tRiNP7y_lNxPEcAU-3CiBk2QVCTDI2mPpQl71pl06nU=.5318c6a1-b03b-413a-92cd-f5050aa6bed7@github.com>
Message-ID: <sLWWd21ZJp2fOiFak35Mibjk1Rdv50s2KP56hLkqO2U=.07902cd7-24dc-4a80-ab85-a0ceab81fd91@github.com>

On Mon, 22 Jul 2024 20:30:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does).
>> 
>> Skara woke up and reported the merge conflict, so you will need to merge master anyway.
>
> @kevinrushforth 
> 
>> I'll approve it as-is and reapprove if you are able to add a check for `CssParser::errorsProperty`.
> 
> So, I added a check there, but must say the error system seems a bit unfinished/unpolished... this took way longer than it should have for the following reasons:
> 
> - The `errorsProperty` will simply **not** be filled at all if you didn't access it first at least once.  This is undocumented.
> - The strings produced use a mix of line-endings on Windows (sometimes `\r\n`, sometimes `\n`), which isn't at all apparent when logging them to the console and trying to match them
> - The produced strings are hard to read; it's some kind of text/xml/json hybrid
> - Value is sometimes `value` sometimes `Value`
> - The word `value` seems a bit overused, a part of the output:
> 
> 
> <Value>
>   <value values="2">
>     <Value>
>       <value>50.0%</value>
> 
> 
> - Sometimes the produced string contains "indents" that are not preceded by a newline...
> 
> 
> </Value>    <Value>
> 
> - Indents use a mix of tabs and spaces
> - Quotes are sometimes unmatched: `'-fx-base''`
> 
> In the PR you can see the strings it produces...

@hjohn This is pending resolution of the merge conflict (then we can re-review)

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

PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2264146155

From kcr at openjdk.org  Thu Aug  1 23:05:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Aug 2024 23:05:41 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
Message-ID: <94OGUzkD2amykoduDwP4194OKF8Lq3G-0-j39t7MJRY=.958e69f3-3169-432d-aaf8-35a1b7676db6@github.com>

On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: floating point precision in test, ensure unsigned int handling in Robot

I'll test the updated version. From my earlier testing, I think the following two things need to be addressed, but I'll let you know for sure:

1. The new system test that uses both AWT and FX robot will need a timeout value, so it won't hang due to [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). We might separately consider skipping the test on Linux until that bug is fixed, but since that is an AWT bug, we need the timeout regardless so it doesn't hang the test run when run on a JDK without that fix.
2. I want to test this with the [metal branch](https://github.com/openjdk/jfx-sandbox/tree/metal) of the jfx-sandbox repo, which will require fixing a merge conflict. When I did this last time I ran into a few unexpected test failures. It's possible I made a mistake in resolving the merge conflicts, but that will need to be checked.

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

PR Comment: https://git.openjdk.org/jfx/pull/1473#issuecomment-2264164399

From almatvee at openjdk.org  Thu Aug  1 23:27:38 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 1 Aug 2024 23:27:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
 <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>
 <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com>
Message-ID: <QlGvOWTsZFj1Cm_RhNQtprYx2B3KbvC2Mk3zSTH6Nw4=.1b91282d-e720-479f-90de-8783bc05be5a@github.com>

On Thu, 1 Aug 2024 21:21:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > JDK-8337686
> 
> thank you for filing the RFE. Should JDK-8337686 explicitly specify that the double conversion introduced in this PR be replaced?

I think this issue/PR should specify it. I just updated description for this PR that color conversion is temporary solution.

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264196640

From angorya at openjdk.org  Thu Aug  1 23:57:46 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 23:57:46 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
Message-ID: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>

On Wed, 31 Jul 2024 19:34:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed a bug

Not a complete review, but the first batch of comments (I stopped at Stop, will continue).  I think it's better to send smaller batches than one giant one (and I am afraid losing the comments due to some GH glitch).

modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 37:

> 35:  *     <caption><b>Interpolation types</b></caption>
> 36:  *     <tbody>
> 37:  *         <tr><td><a id="default" style="white-space: nowrap">default</a></td>

very minor: is it possible to top-align the first column content instead of center?

something like
`<td style="vertical-align: top;">`

modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57:

> 55:  *             </td>
> 56:  *         </tr>
> 57:  *         <tr><td style="white-space: nowrap">(see prose)</td>

"see prose" - could you be more specific?  maybe give an example?

modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157:

> 155:         @Override
> 156:         public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) {
> 157:             var mediator = (TransitionMediatorImpl)existingMediator;

minor: should we use an instanceof pattern here, or do we want to throw ClassCastException?
(here and elsewhere)

example:

if(existingMediator instanceof TransitionMediatorImpl mediator) {
...
}

modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136:

> 134:         @Override
> 135:         public void onUpdate(double progress) {
> 136:             set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue);

minor: should it use (long)Math.round() ?

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 124:

> 122:             // value of the existing transition. This scenario can sometimes happen when a CSS value
> 123:             // is redundantly applied, which would cause unexpected animations if we allowed the new
> 124:             // transition to interrupt the existing transition.

TODO
is there a unit test for this scenario?

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 210:

> 208:             // the running transition by adding its mediator to the newly created transition controller
> 209:             // that manages the hover->base transition. In this way, the new transition controller will
> 210:             // continue to aggregate the effects of the pre-existing transition.

TODO
add a unit test?

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273:

> 271: 
> 272:     private StyleOrigin origin = null;
> 273:     private TransitionController<T> controller = null;

minor: `= null` is unnecessary

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 312:

> 310:             // refers to the reversing controller, and not to this controller. We need to be careful to only
> 311:             // clear references to this controller.
> 312:             if (controller == this) {

is it guaranteed that the reference will be cleared eventually?
TODO
is there a unit test?

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 465:

> 463:                 if (mediators.get(i) == mediator) {
> 464:                     mediators.remove(i);
> 465:                     break;

how do we ensure there are no duplicates in the `mediators` list?

modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 538:

> 536:                 } else if (startValue instanceof Interpolatable && endValue instanceof Interpolatable) {
> 537:                     value = ((Interpolatable<U>)startValue).interpolate(endValue, progress);
> 538:                 } else {

minor: does this if-else block ordered by the expected frequency?

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

> 9008:          *
> 9009:          * @param property the {@code StyleableProperty}
> 9010:          * @param result the map into which results are stored, should be {@code null}

should be or could be?
see L9032

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

> 9182:          *
> 9183:          * @param metadata the CSS metadata of the property
> 9184:          * @param result the map into which results are stored, should be {@code null}

same comment, `could be null`?

modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 301:

> 299:         boolean opaqueFill = false;
> 300: 
> 301:         // We need to iterate over all of the supplied elements in the fills list.

TODO
check if there is a unit test for this

modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157:

> 155:         return this.fill == fill
> 156:             && this.radii == radii
> 157:             && this.insets == insets;

are you sure these don't need equals()?

modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundImage.java line 212:

> 210:             && this.repeatY == repeatY
> 211:             && this.position == position
> 212:             && this.size == size;

same comment on equals().

'size' comes from interpolate() on L178, so there is no guarantee as of its identity

modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java line 266:

> 264:                            Side verticalSide, double verticalPosition, boolean verticalAsPercentage) {
> 265:         return this.horizontalSide == horizontalSide
> 266:             && this.horizontalPosition == horizontalPosition

so here `==` seems to be ok since we are comparing enums and primitive values, but...
should we account for floating point errors that might appear during interpolation?
i.e.

isClose(this.horizontalPosition, horizontalPosition) &&


where

private static boolean isClose(double a, double b) {
 return Math.abs(a - b) < EPSILON; // 0.00001 or something like that should be ok for screen coordinates
}

modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundSize.java line 258:

> 256:         return this.width == width
> 257:             && this.height == height
> 258:             && this.widthAsPercentage == widthAsPercentage

same comment - use isClose() for doubles?

modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331:

> 329: 
> 330:         for (int i = 0, max = strokes.size(); i < max; i++) {
> 331:             final BorderStroke stroke = strokes.get(i);

just curious: do we really need `final` keyword for local variables after java8?

modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270:

> 268:             case ROUND -> BackgroundRepeat.ROUND;
> 269:             case SPACE -> BackgroundRepeat.SPACE;
> 270:             case STRETCH -> BackgroundRepeat.NO_REPEAT;

what do you think of adding default: case?
this code will not compile if BorderRepeat ever acquires a new value.

modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 279:

> 277:             case ROUND -> BorderRepeat.ROUND;
> 278:             case SPACE -> BorderRepeat.SPACE;
> 279:             case NO_REPEAT -> BorderRepeat.STRETCH;

same here // "non-comprehensive switch expression over evolved enum problem"

modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956:

> 1954: 
> 1955:         // If both instances are equal, return this instance to prevent the creation of numerous small objects.
> 1956:         if (t <= 0.0 || equals(endValue)) return this;

This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960).

See for example
https://www.alanzucconi.com/2016/01/06/colour-interpolation/

The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm.

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

PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2213806821
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700900660
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700902994
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700911902
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700915376
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700918183
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700925072
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700933990
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700936434
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700942231
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700956059
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700960388
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700962134
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700967627
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700988085
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700990366
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700995142
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700997569
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1700999656
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701010560
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701011685
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701018016

From angorya at openjdk.org  Thu Aug  1 23:59:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Aug 2024 23:59:35 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <QlGvOWTsZFj1Cm_RhNQtprYx2B3KbvC2Mk3zSTH6Nw4=.1b91282d-e720-479f-90de-8783bc05be5a@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
 <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>
 <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com>
 <QlGvOWTsZFj1Cm_RhNQtprYx2B3KbvC2Mk3zSTH6Nw4=.1b91282d-e720-479f-90de-8783bc05be5a@github.com>
Message-ID: <ceLh90FhWpwXivGhurs_wJ1Cg7iypQaBbfCIOGAD09Y=.021217b1-5668-482c-9d3e-d563623011b2@github.com>

On Thu, 1 Aug 2024 23:25:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> I think this issue/PR should specify it.

The main reason to mention what needs to be corrected is to help the person who will be working on JDK-8337686 many years from now ;-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2264237284

From mstrauss at openjdk.org  Fri Aug  2 00:40:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 00:40:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <l20KynKISqlNOEx0Rozz27gvjpkfbVh_3ZxDqou9yxo=.483dc7b2-c752-463b-b908-c4f70d6fa316@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <l20KynKISqlNOEx0Rozz27gvjpkfbVh_3ZxDqou9yxo=.483dc7b2-c752-463b-b908-c4f70d6fa316@github.com>
Message-ID: <gHbiPeXb8ksfcGo22HqyCzbNw-IK7_3_o2Ri-h7xos0=.7d5c74db-541b-45da-9752-b768d175c4fa@github.com>

On Thu, 1 Aug 2024 22:10:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I note that PR #1471 was originally proposed to address this. Can you highlight the differences? Are any of the comments added to that PR still relevant?

The CSS specification allows specifying separate transitions for sub-properties (see "Independent transitions of sub-properties" in this PR). The previous implementation didn't account for that, while this implementation does. The comments are still applicable where they concern the `Interpolatable` implementations.

> I also note that [JDK-8226911](https://bugs.openjdk.org/browse/JDK-8226911) was added as an issue to the original PR? Should it also be added here?

Yes, I will add it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2264278865

From mstrauss at openjdk.org  Fri Aug  2 01:28:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 01:28:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>

On Thu, 1 Aug 2024 21:40:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 37:
> 
>> 35:  *     <caption><b>Interpolation types</b></caption>
>> 36:  *     <tbody>
>> 37:  *         <tr><td><a id="default" style="white-space: nowrap">default</a></td>
> 
> very minor: is it possible to top-align the first column content instead of center?
> 
> something like
> `<td style="vertical-align: top;">`

Sure.

> modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57:
> 
>> 55:  *             </td>
>> 56:  *         </tr>
>> 57:  *         <tr><td style="white-space: nowrap">(see prose)</td>
> 
> "see prose" - could you be more specific?  maybe give an example?

An example would be `LinearGradient.stops`, but this is rather arbitrary. This table is not exhaustive, and the last line is meant to mention that it's not exhaustive. I'm not sure how an example helps, as every example will probably be different.

> modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157:
> 
>> 155:         @Override
>> 156:         public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) {
>> 157:             var mediator = (TransitionMediatorImpl)existingMediator;
> 
> minor: should we use an instanceof pattern here, or do we want to throw ClassCastException?
> (here and elsewhere)
> 
> example:
> 
> if(existingMediator instanceof TransitionMediatorImpl mediator) {
> ...
> }

A reversing mediator must be the same type, otherwise something is seriously broken. I prefer a `ClassCastException` to highlight that this is very unexpected.

> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 124:
> 
>> 122:             // value of the existing transition. This scenario can sometimes happen when a CSS value
>> 123:             // is redundantly applied, which would cause unexpected animations if we allowed the new
>> 124:             // transition to interrupt the existing transition.
> 
> TODO
> is there a unit test for this scenario?

`StyleableProperty_transition_Test.testRedundantTransitionIsDiscarded`

> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273:
> 
>> 271: 
>> 272:     private StyleOrigin origin = null;
>> 273:     private TransitionController<T> controller = null;
> 
> minor: `= null` is unnecessary

I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there.

> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 465:
> 
>> 463:                 if (mediators.get(i) == mediator) {
>> 464:                     mediators.remove(i);
>> 465:                     break;
> 
> how do we ensure there are no duplicates in the `mediators` list?

The only mediators that are added are new ones (L418) or ones that don't come from this controller (L430). This applies to all controllers, so there can never be a duplicate.

> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 538:
> 
>> 536:                 } else if (startValue instanceof Interpolatable && endValue instanceof Interpolatable) {
>> 537:                     value = ((Interpolatable<U>)startValue).interpolate(endValue, progress);
>> 538:                 } else {
> 
> minor: does this if-else block ordered by the expected frequency?

Most of the time, we get an array series from CSS, so the common case is at the top.

> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9010:
> 
>> 9008:          *
>> 9009:          * @param property the {@code StyleableProperty}
>> 9010:          * @param result the map into which results are stored, should be {@code null}
> 
> should be or could be?
> see L9032

_Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map.

> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157:
> 
>> 155:         return this.fill == fill
>> 156:             && this.radii == radii
>> 157:             && this.insets == insets;
> 
> are you sure these don't need equals()?

This is an internal optimization, see the comment at L135. Since we control the implementation of all types here, we _know_ that these types will return the existing instance if the intermediate value is equal to either the start value or the end value. Using `equals()` here is not necessary, and is not required for correctness.

> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundImage.java line 212:
> 
>> 210:             && this.repeatY == repeatY
>> 211:             && this.position == position
>> 212:             && this.size == size;
> 
> same comment on equals().
> 
> 'size' comes from interpolate() on L178, so there is no guarantee as of its identity

See my other comment. We _know_ that `BackgroundSize` returns existing instances if the intermediate value would be equal.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068408
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068436
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068449
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068468
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068503
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068540
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068594
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068658
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068704
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701068718

From mstrauss at openjdk.org  Fri Aug  2 01:34:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 01:34:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com>

On Thu, 1 Aug 2024 23:21:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java line 266:
> 
>> 264:                            Side verticalSide, double verticalPosition, boolean verticalAsPercentage) {
>> 265:         return this.horizontalSide == horizontalSide
>> 266:             && this.horizontalPosition == horizontalPosition
> 
> so here `==` seems to be ok since we are comparing enums and primitive values, but...
> should we account for floating point errors that might appear during interpolation?
> i.e.
> 
> isClose(this.horizontalPosition, horizontalPosition) &&
> 
> 
> where
> 
> private static boolean isClose(double a, double b) {
>  return Math.abs(a - b) < EPSILON; // 0.00001 or something like that should be ok for screen coordinates
> }

I don't think that this is necessary. It would only save an allocation in a exceedingly rare case where the interpolation factor was microscopically different from either 0 or 1. This shouldn't happen in practice.

> modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331:
> 
>> 329: 
>> 330:         for (int i = 0, max = strokes.size(); i < max; i++) {
>> 331:             final BorderStroke stroke = strokes.get(i);
> 
> just curious: do we really need `final` keyword for local variables after java8?

I don't use it, but I didn't change the existing code here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701071650
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701072138

From mstrauss at openjdk.org  Fri Aug  2 01:39:11 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 01:39:11 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

 - fix since tag
 - adjust table styling

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/675bc7f4..7a92bbf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=01-02

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Fri Aug  2 01:39:12 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 01:39:12 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <TYVVC7mnQL4orzC4Q2ws8UKoNXPVVQ2i_37IgvfZ7dc=.41c07c8a-09dd-413c-9700-9ad8a4d7bef1@github.com>

On Thu, 1 Aug 2024 23:36:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270:
> 
>> 268:             case ROUND -> BackgroundRepeat.ROUND;
>> 269:             case SPACE -> BackgroundRepeat.SPACE;
>> 270:             case STRETCH -> BackgroundRepeat.NO_REPEAT;
> 
> what do you think of adding default: case?
> this code will not compile if BorderRepeat ever acquires a new value.

Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701073308

From mstrauss at openjdk.org  Fri Aug  2 02:15:35 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 02:15:35 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>

On Thu, 1 Aug 2024 23:49:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956:
> 
>> 1954: 
>> 1955:         // If both instances are equal, return this instance to prevent the creation of numerous small objects.
>> 1956:         if (t <= 0.0 || equals(endValue)) return this;
> 
> This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960).
> 
> See for example
> https://www.alanzucconi.com/2016/01/06/colour-interpolation/
> 
> The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm.

CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701105059

From duke at openjdk.org  Fri Aug  2 05:41:46 2024
From: duke at openjdk.org (8Mi_Yile)
Date: Fri, 2 Aug 2024 05:41:46 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v21]
In-Reply-To: <QeLBtUrjuT-BJNQgZtj6UE-F5-ihoP_Csf54T6vL3WQ=.40ad44e5-412d-4a48-87c3-87f0c7db3212@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com>
 <QeLBtUrjuT-BJNQgZtj6UE-F5-ihoP_Csf54T6vL3WQ=.40ad44e5-412d-4a48-87c3-87f0c7db3212@github.com>
Message-ID: <TCmbcuo5gKCpFewk524WvYMLxpVDnyvXvlI7e6IZHwU=.d6abc68f-ec88-4c82-b423-c65acddf3117@github.com>

On Sat, 8 Jun 2024 09:11:03 GMT, Glavo <duke at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits:
>> 
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'master' into new_ime
>>  - Add signals to avoid warnings
>>  - Merge branch 'master' into new_ime
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>>  - Add check for jview
>>  - - Fix comment path
>>  - - Fix double keyrelease
>>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>>    - Unref pango attr list
>>  - Merge branch 'master' into new_ime
>>  - Account the case of !filtered
>>  - ... and 85 more: https://git.openjdk.org/jfx/compare/94aa2b68...8c152c80
>
> I also tested it on GNOME and KDE and it worked just fine, I didn?t face any issues.
> 
> I have provided it to some Linux x86-64/ARM64/LoongArch64 users and they have not had any issues so far.

@Glavo @andy-goryachev-oracle 
i'm tried test @Glavo build
can get this report
> [!TIP]
> ???? (these is Chinese)
Linux??? ?? 20.9
???? 5.17.3
????? 3.5.8.251
???Java?? ????????
???log https://mclo.gs/C1XiAVu
?????????? https://mclo.gs/ajAjNju

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2264598621

From hmeda at openjdk.org  Fri Aug  2 06:41:03 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Fri, 2 Aug 2024 06:41:03 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42
Message-ID: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>

Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen

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

Commit messages:
 - Update libxslt to v1.1.42

Changes: https://git.openjdk.org/jfx/pull/1527/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336941
  Stats: 288 lines in 18 files changed: 111 ins; 126 del; 51 mod
  Patch: https://git.openjdk.org/jfx/pull/1527.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1527/head:pull/1527

PR: https://git.openjdk.org/jfx/pull/1527

From fkirmaier at openjdk.org  Fri Aug  2 09:37:38 2024
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Fri, 2 Aug 2024 09:37:38 GMT
Subject: RFR: 8337656 iOS WebView Position
In-Reply-To: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
References: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
Message-ID: <2deowhT-3jGtQVwX8dBtvDn0m39smJojLKnJp8gtlhI=.c057784f-f20e-4c4a-92f8-d5d210dcb676@github.com>

On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Fixing WebView on iOS
> (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.)
> 
> @johanvos 
> If this looks reasonable to you, can you provide a test build for @dlemmermann ?
> Then he can test it with his JFX-Central iOS version.

Some Background:
Dirk made a new jfx-central mobile version, in the hope of getting it through the app review.
But in this version the WebView is buggy.
So I looked into the code, and I assume, my change would fix it.

<img src="https://github.com/user-attachments/assets/91bc6fbf-7ee5-4665-a6c7-7f4cad71922f" width="200" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2264971784

From duke at openjdk.org  Fri Aug  2 10:11:36 2024
From: duke at openjdk.org (danielpeintner)
Date: Fri, 2 Aug 2024 10:11:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <m8W8xPcK9XnWGsxi4V_Q4yIkiEOrvIGxXICAaD9_2dM=.0be9f84d-b170-49fc-b253-92a4efa61de5@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com>
 <m8W8xPcK9XnWGsxi4V_Q4yIkiEOrvIGxXICAaD9_2dM=.0be9f84d-b170-49fc-b253-92a4efa61de5@github.com>
Message-ID: <d_tJOEuLrzdTT1goK61veGcB8ZreCMiKLWxvECsn5Oo=.8cba5580-0d01-4eb9-807b-d5a9b0b5f095@github.com>

On Wed, 31 Jul 2024 15:08:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 157:
>> 
>>> 155:  * @since 999 TODO
>>> 156:  */
>>> 157: public class RichTextArea extends Control {
>> 
>> The *old* `TextField` and `TextArea` controls extend `TextInputControl`.
>> 
>> I wonder whether there is a a _good_ reason not doing the same for `RichTextArea`?
>> Doing so would allow to more easily switch between one or the other.
>
> Thank you for a very good question!  
> 
> The main reason is that RichTextArea (RTA) can work with a large text model which needs to be represented differently from **TextInputControl**'s simple String **text** property.  Other things, like position within the text is also very different, using `{paragraphIndex,charOffset}` instead of a simple `int` offset.  The fact that the model is separated from the control also makes it very different.
> 
> At the end, there is simply no benefit in dragging the `TextInputControl` into the picture.

I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ?

Let me provide the use-case I have in mind (which may explain better what I am looking for).
I would like to use/keep textfields and textareas with pure text. Anyhow, having the  possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea`  loading) on request only.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1701641116

From jvos at openjdk.org  Fri Aug  2 13:10:05 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 2 Aug 2024 13:10:05 GMT
Subject: [jfx21u] RFR: 8329011: Update SQLite to 3.45.3
Message-ID: <n5s5qJi1Q5IiTRDsU_yX41_3Mb8VAN0VdjZv3Oq_dd4=.91a3df8c-a12b-4d80-b73f-dc26f0f92af9@github.com>

8329011: Update SQLite to 3.45.3

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

Commit messages:
 - Backport 581e3a70a45a550a97e391e06735f4837336ada8

Changes: https://git.openjdk.org/jfx21u/pull/67/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=67&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329011
  Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod
  Patch: https://git.openjdk.org/jfx21u/pull/67.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/67/head:pull/67

PR: https://git.openjdk.org/jfx21u/pull/67

From jvos at openjdk.org  Fri Aug  2 13:14:50 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 2 Aug 2024 13:14:50 GMT
Subject: [jfx17u] RFR: 8329011: Update SQLite to 3.45.3
Message-ID: <x5RUiFMBmi4obA1HWhk7arX_n0A4mui1M7GlKBcxlzo=.aa8f69dc-e050-4f03-b99b-ea3efe7f3da6@github.com>

8329011: Update SQLite to 3.45.3

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

Commit messages:
 - Backport 581e3a70a45a550a97e391e06735f4837336ada8

Changes: https://git.openjdk.org/jfx17u/pull/197/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=197&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329011
  Stats: 26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod
  Patch: https://git.openjdk.org/jfx17u/pull/197.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/197/head:pull/197

PR: https://git.openjdk.org/jfx17u/pull/197

From jvos at openjdk.org  Fri Aug  2 14:10:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 2 Aug 2024 14:10:41 GMT
Subject: [jfx21u] Integrated: 8329011: Update SQLite to 3.45.3
In-Reply-To: <n5s5qJi1Q5IiTRDsU_yX41_3Mb8VAN0VdjZv3Oq_dd4=.91a3df8c-a12b-4d80-b73f-dc26f0f92af9@github.com>
References: <n5s5qJi1Q5IiTRDsU_yX41_3Mb8VAN0VdjZv3Oq_dd4=.91a3df8c-a12b-4d80-b73f-dc26f0f92af9@github.com>
Message-ID: <ttactc8aUMuSOWRXluVIRLtXOXKYwYufaOUvJn4jyLk=.40d46773-472a-4cf1-9808-46aa4b7f6df9@github.com>

On Fri, 2 Aug 2024 13:04:30 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8329011: Update SQLite to 3.45.3

This pull request has now been integrated.

Changeset: 454ac50c
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/454ac50cea8f93f5c8bd7c30393d0ca2648b245f
Stats:     26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod

8329011: Update SQLite to 3.45.3

Backport-of: 581e3a70a45a550a97e391e06735f4837336ada8

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

PR: https://git.openjdk.org/jfx21u/pull/67

From jvos at openjdk.org  Fri Aug  2 14:10:41 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 2 Aug 2024 14:10:41 GMT
Subject: [jfx17u] Integrated: 8329011: Update SQLite to 3.45.3
In-Reply-To: <x5RUiFMBmi4obA1HWhk7arX_n0A4mui1M7GlKBcxlzo=.aa8f69dc-e050-4f03-b99b-ea3efe7f3da6@github.com>
References: <x5RUiFMBmi4obA1HWhk7arX_n0A4mui1M7GlKBcxlzo=.aa8f69dc-e050-4f03-b99b-ea3efe7f3da6@github.com>
Message-ID: <R1_Z0MR8SwoUVEnKIWAg4VxpeRKrQMB7zcKznqRCecQ=.face0d95-4f33-482a-9a51-73be178d450d@github.com>

On Fri, 2 Aug 2024 13:08:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 8329011: Update SQLite to 3.45.3

This pull request has now been integrated.

Changeset: eb330d88
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/eb330d883d32b9cc1f9d0c894b01b160b2bfe2c3
Stats:     26451 lines in 4 files changed: 17765 ins; 2993 del; 5693 mod

8329011: Update SQLite to 3.45.3

Backport-of: 581e3a70a45a550a97e391e06735f4837336ada8

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

PR: https://git.openjdk.org/jfx17u/pull/197

From jhendrikx at openjdk.org  Fri Aug  2 14:39:49 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Aug 2024 14:39:49 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v6]
In-Reply-To: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
Message-ID: <I1_iM4UYEuz1GjhEuFHUZEN4fceh9S0wNk_SrkgTKh8=.53f3a49a-2f38-4e90-99ae-b67ed27e741f@github.com>

> Fixes an infinite loop that can occur while resolving lookups.
> 
> There were 2 bugs:
> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates
> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far
> 
> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code).

John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into feature/fix-stackoverflow-in-resolve-lookups
 - Add lines I forgot to commit
 - Add check on errorProperty
 - Merge branch 'master' of https://git.openjdk.org/jfx into
   feature/fix-stackoverflow-in-resolve-lookups
 - Fix formatting and spelling
 - Fix loop detection in resolveLookups

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

Changes: https://git.openjdk.org/jfx/pull/1505/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=05
  Stats: 171 lines in 2 files changed: 158 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1505.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505

PR: https://git.openjdk.org/jfx/pull/1505

From angorya at openjdk.org  Fri Aug  2 14:54:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 14:54:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>
Message-ID: <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com>

On Fri, 2 Aug 2024 02:13:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/paint/Color.java line 1956:
>> 
>>> 1954: 
>>> 1955:         // If both instances are equal, return this instance to prevent the creation of numerous small objects.
>>> 1956:         if (t <= 0.0 || equals(endValue)) return this;
>> 
>> This question might be outside of the current PR, but I think the naive color interpolation algorithm is a bad choice here (L1960).
>> 
>> See for example
>> https://www.alanzucconi.com/2016/01/06/colour-interpolation/
>> 
>> The question that is relevant to this PR is whether we should enable the user to specify the interpolation algorithm.
>
> CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec.

pardon my ignorance, could you clarify what a "CSS Transition 1" is?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701960667

From jhendrikx at openjdk.org  Fri Aug  2 15:02:13 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Aug 2024 15:02:13 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7]
In-Reply-To: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
Message-ID: <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>

> Fixes an infinite loop that can occur while resolving lookups.
> 
> There were 2 bugs:
> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates
> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far
> 
> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code).

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Update CssStyleHelper.java

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1505/files
  - new: https://git.openjdk.org/jfx/pull/1505/files/72d64b0f..ff5788c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=05-06

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

PR: https://git.openjdk.org/jfx/pull/1505

From jhendrikx at openjdk.org  Fri Aug  2 15:02:13 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Aug 2024 15:02:13 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5]
In-Reply-To: <jslgMCiiQALB4BBzdzEos95wy5BDvhwa84yJZjfWw_Y=.0be33ef3-ad28-4230-ae07-2828a4d419e4@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <VR0--Tv0zSg4JiEVCD0d-YuVvg2GcbPuX2JJsD2Y5Js=.a9392320-1f95-4339-8d08-05a70bb117ab@github.com>
 <xSN-xnjq96eXQ_JgsaaKILpjFZ36a8oRpCUoBM6rue0=.96437fea-69cb-4595-9880-7e772c84c95e@github.com>
 <jslgMCiiQALB4BBzdzEos95wy5BDvhwa84yJZjfWw_Y=.0be33ef3-ad28-4230-ae07-2828a4d419e4@github.com>
Message-ID: <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com>

On Thu, 25 Jul 2024 14:54:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 699:
>> 
>>> 697: 
>>> 698:         // Note: on Windows, the message is using inconsistent line endings (sometimes Windows, sometimes Linux)
>>> 699:         // so I've stripped it.
>> 
>> would looking for substrings be a better solution?  for example:
>> 
>> 
>> contains("Caught java.lang.IllegalArgumentException: Loop detected in *.root{") &&
>> contains("while resolving '-fx-base'' while calculating value for '-fx-background-color' from rule '*.pane' in stylesheet"
>
> Yeah, this seems less fragile. If we ever run into a problem because the message changes slightly, we could consider such a change in the future.

I'm not sure what way is being advocated.  It seems both of you favor a contains check?

For me, I always verify strings intended for user consumption completely so that any change would fail a test.  If the change is intended (like fixing the missing line feeds), then the string can be fixed at the same time.  With the complete string, the test also serves as a way to see the full output (which in this case, is a bit abysmal, so perhaps we should follow up with a fix).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1701968325

From angorya at openjdk.org  Fri Aug  2 15:03:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 15:03:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
Message-ID: <b9IOydoeomTNQj2wcisrSjbtFpJCaTijoMNbsogRvi0=.ff2cb7c8-324c-4e7d-9971-0aae7bf52f26@github.com>

On Fri, 2 Aug 2024 01:25:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 273:
>> 
>>> 271: 
>>> 272:     private StyleOrigin origin = null;
>>> 273:     private TransitionController<T> controller = null;
>> 
>> minor: `= null` is unnecessary
>
> I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there.

I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes"

as long as the new code omits `= null` we should be fine.

(rationale for omitting: explicit initialization creates an unnecessary step in the debugger)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701970897

From angorya at openjdk.org  Fri Aug  2 15:07:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 15:07:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
Message-ID: <oE6rYMSTEfnmWImcshlcvqasRxwA8ia5u__NK3e7jj0=.49649c7e-82da-4f64-9dfc-91d3d3dcba2c@github.com>

On Fri, 2 Aug 2024 01:25:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9010:
>> 
>>> 9008:          *
>>> 9009:          * @param property the {@code StyleableProperty}
>>> 9010:          * @param result the map into which results are stored, should be {@code null}
>> 
>> should be or could be?
>> see L9032
>
> _Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map.

I suggest we clarify this behavior in the method description.  Simply saying "should" increases cognitive load and creates a question: why have this argument in the first place, and the need to search the code for an explanation.

(yes, I understand we could also create a private method with the `map` argument)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701974659

From mstrauss at openjdk.org  Fri Aug  2 15:07:40 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:07:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>
 <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com>
Message-ID: <jwnVywZRd0oZCGALl_Bh7dcEDdkiPnVvwBe29uFr9Ww=.5f98ba38-52ca-40ef-b475-951d084bd03d@github.com>

On Fri, 2 Aug 2024 14:52:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> CSS Transitions 1 is a feature-complete spec, and it doesn't include an option to specify the transition color space. That might come with CSS Transitions 2, but it's not there yet. I think we should revisit this once the feature has landed in the spec.
>
> pardon my ignorance, could you clarify what a "CSS Transition 1" is?

It's basically the feature level of the specification.
Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX)
Here's level 2: https://www.w3.org/TR/css-transitions-2/
There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701975936

From mstrauss at openjdk.org  Fri Aug  2 15:37:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:37:16 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v4]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <c-lnkUjDFxolqpn3q1IHT8WbfAITcpn5tifKR5Sk-gw=.ddb57ddc-3a20-4937-a504-518b7c41b855@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  add test for inherited transitions

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/7a92bbf6..8f53f3a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=02-03

  Stats: 147 lines in 2 files changed: 116 ins; 28 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Fri Aug  2 15:37:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:37:16 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <cCgQsrBYQvKlJftJJOL0TU1M3U4pk3M7R8zHv87Ck-4=.b281b613-63fd-40a1-804b-3c626731f157@github.com>

On Thu, 1 Aug 2024 22:05:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/css/StyleableObjectProperty.java line 210:
> 
>> 208:             // the running transition by adding its mediator to the newly created transition controller
>> 209:             // that manages the hover->base transition. In this way, the new transition controller will
>> 210:             // continue to aggregate the effects of the pre-existing transition.
> 
> is there a unit test for this scenario?

Done: `StyleableProperty_transition_Test.testExistingTransitionOfComponentTransitionableIsPreserved`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702014530

From mstrauss at openjdk.org  Fri Aug  2 15:41:11 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:41:11 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v5]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <kPZdOWuqiwoRMRER0n-cud5vrNyChmXvvk36sIT_9tU=.7b4162a5-8c82-480e-b850-376fe9f50062@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

 - update documentation
 - remove redundant null initialization

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/8f53f3a8..3b8fa919

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=03-04

  Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Fri Aug  2 15:44:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:44:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <b9IOydoeomTNQj2wcisrSjbtFpJCaTijoMNbsogRvi0=.ff2cb7c8-324c-4e7d-9971-0aae7bf52f26@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
 <b9IOydoeomTNQj2wcisrSjbtFpJCaTijoMNbsogRvi0=.ff2cb7c8-324c-4e7d-9971-0aae7bf52f26@github.com>
Message-ID: <aNcnDkDIVcwaW-eOw6uuHgGb_JPQbxQXMoRZDev6ZG0=.87e943c5-6329-4f61-a0fe-2045d6e3f6cd@github.com>

On Fri, 2 Aug 2024 15:00:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I agree. Not sure if I should remove it from all of the StyleableProperty implementations, as the `origin = null` is already there.
>
> I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes"
> 
> as long as the new code omits `= null` we should be fine.
> 
> (rationale for omitting: explicit initialization creates an unnecessary step in the debugger)

I've removed the `= null` for consistency on both fields.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702023744

From mstrauss at openjdk.org  Fri Aug  2 15:47:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:47:36 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <oE6rYMSTEfnmWImcshlcvqasRxwA8ia5u__NK3e7jj0=.49649c7e-82da-4f64-9dfc-91d3d3dcba2c@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
 <oE6rYMSTEfnmWImcshlcvqasRxwA8ia5u__NK3e7jj0=.49649c7e-82da-4f64-9dfc-91d3d3dcba2c@github.com>
Message-ID: <JrpVofkNysdXchQG4fi4eZyT2gAme_a14ZShgXTZ960=.9aeeff24-c5a7-4c6c-87fb-5a0440dd8795@github.com>

On Fri, 2 Aug 2024 15:03:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> _Should_ be `null` to get the non-allocating behavior if nothing is found, but _could_ also be non-null if we want to provide our own output map.
>
> I suggest we clarify this behavior in the method description, since this is a public API documentation.  
> 
> Simply saying "should" increases cognitive load and immediately triggers a question: why have this argument at all?, and the need to search the code for an explanation.
> 
> (yes, I understand we could also create a private method with the `map` argument)

I've worded it more strongly such that callers _must_ pass in `null`. This is a private method, so we don't need to account for other usage scenarios.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702027303

From kcr at openjdk.org  Fri Aug  2 15:51:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 15:51:36 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5]
In-Reply-To: <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <VR0--Tv0zSg4JiEVCD0d-YuVvg2GcbPuX2JJsD2Y5Js=.a9392320-1f95-4339-8d08-05a70bb117ab@github.com>
 <xSN-xnjq96eXQ_JgsaaKILpjFZ36a8oRpCUoBM6rue0=.96437fea-69cb-4595-9880-7e772c84c95e@github.com>
 <jslgMCiiQALB4BBzdzEos95wy5BDvhwa84yJZjfWw_Y=.0be33ef3-ad28-4230-ae07-2828a4d419e4@github.com>
 <9YIR4N0_FlczeBabLT5g5UUzUBaTWUvkyj0-fGa3Ggk=.613a1420-871d-49dd-8531-d0134547cbc9@github.com>
Message-ID: <NvgvZFpX0hfM0qNHCWQDSD4WmhbCil_pYhVu1tr-zXk=.c2622aa5-a4f8-4eff-a81e-88365557ce97@github.com>

On Fri, 2 Aug 2024 14:58:32 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> It seems both of you favor a contains check?

Yeah, that is what I was saying, but I don't mind either way. And you raise a good point about the advantage of having any change to the string cause a failure (as long as the string isn't prone to spurious changes).

So I have no objection to your leaving it as is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1702031515

From kcr at openjdk.org  Fri Aug  2 15:54:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 15:54:38 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7]
In-Reply-To: <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>
Message-ID: <LCVCKJDxdcxoJCZVJV19aLEIr8PtOJUT910PsQu8nSM=.fab7e690-ad6d-4ea7-9a3c-25ccbec1f0eb@github.com>

On Fri, 2 Aug 2024 15:02:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes an infinite loop that can occur while resolving lookups.
>> 
>> There were 2 bugs:
>> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates
>> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far
>> 
>> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code).
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CssStyleHelper.java

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2215916092

From mstrauss at openjdk.org  Fri Aug  2 15:55:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 15:55:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <PIXJMJss5dj-HHZfqTyLQ6XYPqs2ZjnEQNcnmQoJM6U=.0d186a3b-0d01-4f3b-8d21-e691c255aab7@github.com>

On Thu, 1 Aug 2024 22:51:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 301:
> 
>> 299:         boolean opaqueFill = false;
>> 300: 
>> 301:         // We need to iterate over all of the supplied elements in the fills list.
> 
> is there a unit test for this scenario?

The closest one I can find is `BackgroundTest.backgroundOutsetsAreDefinedByFills`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702036374

From kcr at openjdk.org  Fri Aug  2 16:00:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 16:00:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <aNcnDkDIVcwaW-eOw6uuHgGb_JPQbxQXMoRZDev6ZG0=.87e943c5-6329-4f61-a0fe-2045d6e3f6cd@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
 <b9IOydoeomTNQj2wcisrSjbtFpJCaTijoMNbsogRvi0=.ff2cb7c8-324c-4e7d-9971-0aae7bf52f26@github.com>
 <aNcnDkDIVcwaW-eOw6uuHgGb_JPQbxQXMoRZDev6ZG0=.87e943c5-6329-4f61-a0fe-2045d6e3f6cd@github.com>
Message-ID: <VKUb-RpWZbfLmzmhLqJxxIjH3a09aMZQOfUfeKlt5L0=.b7c913ae-0db1-4015-aad1-1b23225b5786@github.com>

On Fri, 2 Aug 2024 15:41:36 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes"
>> 
>> as long as the new code omits `= null` we should be fine.
>> 
>> (rationale for omitting: explicit initialization creates an unnecessary step in the debugger)
>
> I've removed the `= null` for consistency on both fields.

> I know what @kevinrushforth would say: "it is better to avoid introducing unrelated changes"

Yes, that is what I would say. :)

> as long as the new code omits `= null` we should be fine.
> 
> (rationale for omitting: explicit initialization creates an unnecessary step in the debugger)

In this case, omitting it is fine. There are cases where I prefer to explicitly initialize fields to `null`, `false`, or `0`, for clarity, even though those values are the default. I don't care that it creates an unnecessary step in your debugger.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702041658

From angorya at openjdk.org  Fri Aug  2 16:13:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:13:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
Message-ID: <EBE_fVki3WNGo_ADHM4hq-hQzPMc8cfTDn1R5XFaxzg=.7f547146-8c8f-4d4b-a453-03f532b1bad1@github.com>

On Fri, 2 Aug 2024 01:39:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix since tag
>  - adjust table styling

Thank you for this contribution!

This is the second batch of code review comments.  Will probably have more after testing.

modules/javafx.graphics/src/main/java/javafx/scene/paint/Stop.java line 162:

> 160:         // re-allocating when we run out of space. In general, we expect the size of stop lists
> 161:         // to be quite small (a single-digit number of stops at most).
> 162:         Stop[] stops = new Stop[firstList.size() + secondList.size()];

are there unit tests to cover most of the scenarios, at least using short sequences?

modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java line 264:

> 262:                 new Stop(1, color2)),
> 263:             res);
> 264:         }

Do you think any other combinations should be added, for completeness sake?

For example, let's consider two lists with 2 points each.  We might want to test scenarios:


--
     --

--|
  |--

---
 ---

----|
 ---|

------
  --

  |-----
  |--

  |---|
  |---|

    |--
  --|

     ---
--


and also have the two lists swapped maybe?

what do you think?

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

PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2215836542
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702023646
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702046900

From angorya at openjdk.org  Fri Aug  2 16:13:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:13:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
Message-ID: <TTTA6GcbgqimjSLuwxz4qKSMkAksMPJaZVtV-Dla7fo=.394ec567-9b8a-48bb-b1b7-14369fa3463d@github.com>

On Fri, 2 Aug 2024 01:24:59 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/StyleableDoubleProperty.java line 157:
>> 
>>> 155:         @Override
>>> 156:         public boolean updateReversingAdjustedStartValue(TransitionMediator existingMediator) {
>>> 157:             var mediator = (TransitionMediatorImpl)existingMediator;
>> 
>> minor: should we use an instanceof pattern here, or do we want to throw ClassCastException?
>> (here and elsewhere)
>> 
>> example:
>> 
>> if(existingMediator instanceof TransitionMediatorImpl mediator) {
>> ...
>> }
>
> A reversing mediator must be the same type, otherwise something is seriously broken. I prefer a `ClassCastException` to highlight that this is very unexpected.

that's what I thought, thanks for clarification.

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 157:
>> 
>>> 155:         return this.fill == fill
>>> 156:             && this.radii == radii
>>> 157:             && this.insets == insets;
>> 
>> are you sure these don't need equals()?
>
> This is an internal optimization, see the comment at L135. Since we control the implementation of all types here, we _know_ that these types will return the existing instance if the intermediate value is equal to either the start value or the end value. Using `equals()` here is not necessary, and is not required for correctness.

I see, so it only checks for hitting the start/end point.  thanks for clarification!

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderConverter.java line 270:
>> 
>>> 268:             case ROUND -> BackgroundRepeat.ROUND;
>>> 269:             case SPACE -> BackgroundRepeat.SPACE;
>>> 270:             case STRETCH -> BackgroundRepeat.NO_REPEAT;
>> 
>> what do you think of adding default: case?
>> this code will not compile if BorderRepeat ever acquires a new value.
>
> Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose).

IllegalArgumentException?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701991167
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702001112
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702004500

From angorya at openjdk.org  Fri Aug  2 16:13:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:13:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <aKltM_2o2y244jXJsPP7c-LOo82QDosAOsJCvN_by6k=.61da8305-bba9-4e32-be4a-c71c25090524@github.com>

On Thu, 1 Aug 2024 22:45:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9184:
> 
>> 9182:          *
>> 9183:          * @param metadata the CSS metadata of the property
>> 9184:          * @param result the map into which results are stored, should be {@code null}
> 
> same comment, `could be null`?

or perhaps remove it by adding a private method with the second argument?
what do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701996909

From angorya at openjdk.org  Fri Aug  2 16:13:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:13:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <jwnVywZRd0oZCGALl_Bh7dcEDdkiPnVvwBe29uFr9Ww=.5f98ba38-52ca-40ef-b475-951d084bd03d@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>
 <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com>
 <jwnVywZRd0oZCGALl_Bh7dcEDdkiPnVvwBe29uFr9Ww=.5f98ba38-52ca-40ef-b475-951d084bd03d@github.com>
Message-ID: <IC9nSqR818-2LxNzQ4jAWi_jfJw2Gotzmc_Aff_mArM=.d38e9fe2-51f2-4296-8c5a-5188313021fa@github.com>

On Fri, 2 Aug 2024 15:04:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> pardon my ignorance, could you clarify what a "CSS Transition 1" is?
>
> It's basically the feature level of the specification.
> Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX)
> Here's level 2: https://www.w3.org/TR/css-transitions-2/
> There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet.

thank you for clarification!

would it make sense to add an option for programmatic interpolation, i.e. when the app developer does it in code as opposed to CSS?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702015968

From angorya at openjdk.org  Fri Aug  2 16:21:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:21:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
Message-ID: <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com>

On Thu, 1 Aug 2024 21:54:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug
>
> modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136:
> 
>> 134:         @Override
>> 135:         public void onUpdate(double progress) {
>> 136:             set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue);
> 
> minor: should it use (long)Math.round() ?

edit: I think it should.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702063665

From angorya at openjdk.org  Fri Aug  2 16:21:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:21:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
Message-ID: <t797c4mVspSzLxMo_20pCcn_6SWAgZGGaIZrvBL30aQ=.ca884011-2ce0-4a6d-a827-86e89ccb895b@github.com>

On Fri, 2 Aug 2024 01:24:56 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57:
>> 
>>> 55:  *             </td>
>>> 56:  *         </tr>
>>> 57:  *         <tr><td style="white-space: nowrap">(see prose)</td>
>> 
>> "see prose" - could you be more specific?  maybe give an example?
>
> An example would be `LinearGradient.stops`, but this is rather arbitrary. This table is not exhaustive, and the last line is meant to mention that it's not exhaustive. I'm not sure how an example helps, as every example will probably be different.

I just feel a bit confused by the last entry in this table, or may be the choice of word "prose" (the description is good).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702061354

From mstrauss at openjdk.org  Fri Aug  2 16:21:40 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 16:21:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <IC9nSqR818-2LxNzQ4jAWi_jfJw2Gotzmc_Aff_mArM=.d38e9fe2-51f2-4296-8c5a-5188313021fa@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <vEzOJ8eFeA9gTpq6OW9TBGqOX1vDKf4loSy0ZwMVcTk=.bcd9b1ac-09c2-4ba3-b6cb-d820e033d3d8@github.com>
 <3vskDXOg9nkuFeKjlZ2jNKeqd_F0aEYoY76W5IcqE4g=.df298f97-a069-43af-a172-a641f0c065e6@github.com>
 <jwnVywZRd0oZCGALl_Bh7dcEDdkiPnVvwBe29uFr9Ww=.5f98ba38-52ca-40ef-b475-951d084bd03d@github.com>
 <IC9nSqR818-2LxNzQ4jAWi_jfJw2Gotzmc_Aff_mArM=.d38e9fe2-51f2-4296-8c5a-5188313021fa@github.com>
Message-ID: <oDNtYRCwg7qRo3lHGSvGM9oNdn3B-MPd0-ItimWxhxw=.64f86117-4e09-41a6-8920-133a21d54262@github.com>

On Fri, 2 Aug 2024 15:35:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> It's basically the feature level of the specification.
>> Here's level 1: https://www.w3.org/TR/css-transitions-1/ (this is implemented in JavaFX)
>> Here's level 2: https://www.w3.org/TR/css-transitions-2/
>> There seems to be an ongoing discussion around different color interpolation options, but nothing has made it into the level 2 specification yet.
>
> thank you for clarification!
> 
> would it make sense to add an option for programmatic interpolation, i.e. when the app developer does it in code as opposed to CSS?

Yes, I think this would be a good enhancement.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702064093

From angorya at openjdk.org  Fri Aug  2 16:25:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 16:25:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <JrpVofkNysdXchQG4fi4eZyT2gAme_a14ZShgXTZ960=.9aeeff24-c5a7-4c6c-87fb-5a0440dd8795@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
 <oE6rYMSTEfnmWImcshlcvqasRxwA8ia5u__NK3e7jj0=.49649c7e-82da-4f64-9dfc-91d3d3dcba2c@github.com>
 <JrpVofkNysdXchQG4fi4eZyT2gAme_a14ZShgXTZ960=.9aeeff24-c5a7-4c6c-87fb-5a0440dd8795@github.com>
Message-ID: <yWUBc4N74JgH2YM1X2PsuF05UagkHfMdnGNCOY2EPTw=.0ebc2f30-b790-481d-a59c-2782cbfd265c@github.com>

On Fri, 2 Aug 2024 15:44:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I suggest we clarify this behavior in the method description, since this is a public API documentation.  
>> 
>> Simply saying "should" increases cognitive load and immediately triggers a question: why have this argument at all?, and the need to search the code for an explanation.
>> 
>> (yes, I understand we could also create a private method with the `map` argument)
>
> I've worded it more strongly such that callers _must_ pass in `null`. This is a private method, so we don't need to account for other usage scenarios.

oh, right, it is private!  never mind then.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702066372

From mstrauss at openjdk.org  Fri Aug  2 16:25:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 16:25:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <TTTA6GcbgqimjSLuwxz4qKSMkAksMPJaZVtV-Dla7fo=.394ec567-9b8a-48bb-b1b7-14369fa3463d@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <E6VbmpZBxCvHOKN8mE2vQHEZi7t-22JGFw1hVTDc_S4=.e6371a8e-f2fb-440d-ae14-d48f3ea828be@github.com>
 <TTTA6GcbgqimjSLuwxz4qKSMkAksMPJaZVtV-Dla7fo=.394ec567-9b8a-48bb-b1b7-14369fa3463d@github.com>
Message-ID: <GUHUqi4_O-46m76hsK_SWLSSzBtuwhCm77d_3D_brLM=.ccf4c6a4-9bc8-4408-aedf-cd7b62ca7499@github.com>

On Fri, 2 Aug 2024 15:28:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, I think that's good, as it will alert us to the impact of adding a new enum value. We would probably need to account for the new value here (there's no good default we can choose).
>
> IllegalArgumentException?

Sure, but that would be a runtime errro as compared to a compile-time error, so we run the risk of missing it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702067250

From kcr at openjdk.org  Fri Aug  2 16:54:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 16:54:35 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <yywjt7bNk4fc0yVUvM-rdyRdupLZPlCpY4LTxkCBuas=.453c0c9e-1b18-4086-b9a6-55072de9cf72@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

The code changes look good. I tested it on Windows 11 and it now looks correct.

@arapte or @andy-goryachev-oracle can one of you be the second reviewer?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2216020305
PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2265790174

From kcr at openjdk.org  Fri Aug  2 16:58:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 16:58:41 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42
In-Reply-To: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
Message-ID: <_2Qqjyrc_vR1iG8cSXs0L6UNjGgwgbYPjmmaqNi0_mY=.f6c8ef35-e06e-4206-968c-0fba96ca7751@github.com>

On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2265795518

From quizynox at gmail.com  Fri Aug  2 17:43:11 2024
From: quizynox at gmail.com (quizynox at gmail.com)
Date: Fri, 2 Aug 2024 21:43:11 +0400
Subject: Font hinting on Linux
Message-ID: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>

Hello,

Sorry for asking here, but I seem to have tried everything I could find 
on SO/Reddit/JBS etc. Could someone please share what font settings I 
should be using to get decent font hinting on Linux? Please see the 
screenshot.

https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view

I'm not very picky, but the font I see is just not suitable for 
presenting app to customers. I've tried enabling and disabling hinting 
and autohinting, using different hinting styles, changing the font 
smoothing type and prism.lcdtext etc. Unfortunately no matter what I do, 
the font hinting is always bad.

Fedora, KDE, all latest versions.


From angorya at openjdk.org  Fri Aug  2 17:53:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 17:53:39 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7]
In-Reply-To: <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>
Message-ID: <WjI-y2pzPjP4uif7TzXPgQJ_0cLHWLMyapJcOX3SGCE=.d0104711-e20e-4f7d-80cc-755972213805@github.com>

On Fri, 2 Aug 2024 15:02:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes an infinite loop that can occur while resolving lookups.
>> 
>> There were 2 bugs:
>> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates
>> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far
>> 
>> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code).
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CssStyleHelper.java

re-tested on macOS, works as expected.

also tested in the Monkey Tester with the CSS provided in the ticket (errors appear in stderr as expected), and after the offending CSS is removed (gets back to normal).

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2216111787

From angorya at openjdk.org  Fri Aug  2 18:02:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 18:02:35 GMT
Subject: Integrated: 8336331: Doc: Clarification in AccessibleAttribute,
 AccessibleRole
In-Reply-To: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com>
References: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com>
Message-ID: <yM_6AzSv59dxdQpaGi6ao3mzvH4WdPW7X83KZylA2kc=.20c5fb92-22b1-46b9-966a-21f1c64f1282@github.com>

On Thu, 18 Jul 2024 19:00:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Minor clarifications in Javadoc
> 
> **AccessibleAttribute**:
> - Point2D and Bound values uses screen coordinates. Example: `BOUNDS`, `BOUNDS_FOR_RANGE`, `OFFSET_AT_POINT`, ...
> - clarified the meaning of `SELECTION_END`, `SELECTION_START`
> 
> **Accessible Role**:
> - missing accessible action `SHOW_TEXT_RANGE`
> 
> This will be a minor clarification, so no CSR is required.

This pull request has now been integrated.

Changeset: 41de0202
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/41de02023571d146f392de012a55011a5f87fc9d
Stats:     13 lines in 3 files changed: 4 ins; 0 del; 9 mod

8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole

Reviewed-by: arapte, kizune

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

PR: https://git.openjdk.org/jfx/pull/1512

From kcr at openjdk.org  Fri Aug  2 18:19:44 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 18:19:44 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42
In-Reply-To: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
Message-ID: <mSQoYI-hNGlSjS_BtR_Amtpgrx-dfNOYQVbsMy6GalA=.2493d5b2-17a0-45fc-96ad-534d617d42d6@github.com>

On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen

Looks good, although I notice one difference between the upstream libxslt repo and this PR in a now-unmaintained config file:


diff -u -w -r $JFX/modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.m4 $LIBXML/libxslt.m4
--- $JFX/modules/javafx.web/src/main/native/Source/ThirdParty/libxslt/src/libxslt.m4 2023-07-27 15:08:29.124274800 -0700
+++ $LIBXML/libxslt.m4        2024-08-02 10:18:29.007649600 -0700
@@ -5,6 +5,8 @@
 # Configure paths for GLIB
 # Owen Taylor     97-11-3
 #
+# Deprecated and unmaintained. Use pkg-config or xslt-config.
+#
 # Modified to work with libxslt by Thomas Schraitle 2002/10/25
 # Fixed by Edward Rudd 2004/05/12


Do we use `libxslt.m4` when we run configure to generate the platform-specific headers? If not, I recommend that you remove it from our repo. If we do, please add the two lines from the above patch so that we match the upstream.

Note that the deprecation comment was added by:

https://gitlab.gnome.org/GNOME/libxslt/-/commit/200ee26982b4c8cbe165555ae36aa684a744ccf4

so we will eventually need to stop using it if we still are.

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

PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2216151444

From kevin.rushforth at oracle.com  Fri Aug  2 18:31:46 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 2 Aug 2024 11:31:46 -0700
Subject: JavaFX 23 is in Rampdown Phase Two (RDP2)
Message-ID: <821ff1d7-3f5c-4b25-9dd9-16941959668d@oracle.com>

To: JavaFX Developers

As a reminder, JavaFX 23 is now in Rampdown Phase Two (RDP2). [1]

P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed 
during RDP2. Explicit approval is needed for all bug fixes and 
enhancements (except for doc and test fixes) to go in to the jfx23 
branch [2]. The bar for approving bug fixes is appropriately high at 
this point. We do not anticipate approving any more enhancements.

Now that we are in RDP2, the goal is to stabilize what is there, fixing 
bugs that are new in JavaFX 23. We need to be extremely careful about 
including anything that introduces risk.

We will use the same rules for RDP2 that the JDK uses [3], with two 
modifications:

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 23 release. As an obvious choice, derived from the 
JBS fix version, we will use "jfx23-fix-request", "jfx23-fix-yes", 
"jfx23-fix-no" and "jfx23-fix-nmi", "jfx23-enhancement-request", 
"jfx23-enhancement-yes", "jfx23-enhancement-no" and 
"jfx23-enhancement-nmi" as corresponding labels.

REMINDER: In this release we will integrate almost all stabilization 
changes via backports from the master branch [4].

 ? * Almost all fixes intended for the jfx23 stabilization branch will 
also be applicable to the master branch. Integrate such a change into 
the master branch first. Then, after you have obtained any required 
approvals, backport it to the stabilization branch using the Skara 
`/backport` command or, if necessary, by manually opening a backport PR 
with the title `Backport $HASH`, where `$HASH` is the original commit 
hash.? (The JDK Developers? Guide contains more information on working 
with backports [5].)

 ? * Some fixes will be specific to the stabilization branch and not 
applicable to the master branch. Integrate such a change directly into 
the stabilization 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 (JavaFX 24 as of today). This is usually what we 
want. A backport PR should be targeted to `jfx23` if, and only if, it is 
intended for JavaFX 23 and meets the criteria for the current rampdown 
phase (we're in RDP2 as of today). Reviewers are advised to be extra 
cautious in approving potentially risky fixes targeted to `jfx23`. If 
there is a concern, then a reviewer can as part of the review indicate 
that the PR should be retargeted to `master` for 24 (or withdrawn if it 
is a backport of a fix already in `master`). Reviewers also need to be 
extra careful when reviewing PRs targeted to jfx23 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. This should be less of a 
problem for this release, since almost all PRs for jfx23 will be done as 
backport-style PRs, but it can still be a problem if the developer 
mistakenly merges master into their backport branch.

Let me know if there are any questions.

-- Kevin


[1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-May/046924.html

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

[3] http://openjdk.org/jeps/3

[4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements

[5] https://openjdk.org/guide/#working-with-backports-in-jbs




From angorya at openjdk.org  Fri Aug  2 18:32:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 18:32:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <d_tJOEuLrzdTT1goK61veGcB8ZreCMiKLWxvECsn5Oo=.8cba5580-0d01-4eb9-807b-d5a9b0b5f095@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com>
 <m8W8xPcK9XnWGsxi4V_Q4yIkiEOrvIGxXICAaD9_2dM=.0be9f84d-b170-49fc-b253-92a4efa61de5@github.com>
 <d_tJOEuLrzdTT1goK61veGcB8ZreCMiKLWxvECsn5Oo=.8cba5580-0d01-4eb9-807b-d5a9b0b5f095@github.com>
Message-ID: <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com>

On Fri, 2 Aug 2024 10:09:21 GMT, danielpeintner <duke at openjdk.org> wrote:

>> Thank you for a very good question!  
>> 
>> The main reason is that RichTextArea (RTA) can work with a large text model which needs to be represented differently from **TextInputControl**'s simple String **text** property.  Other things, like position within the text is also very different, using `{paragraphIndex,charOffset}` instead of a simple `int` offset.  The fact that the model is separated from the control also makes it very different.
>> 
>> At the end, there is simply no benefit in dragging the `TextInputControl` into the picture.
>
> I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ?
> 
> Let me provide the use-case I have in mind (which may explain better what I am looking for).
> I would like to use/keep textfields and textareas with pure text. Anyhow, having the  possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea`  loading) on request only.

It looks like in this particular case you do want to preserve the semantics and APIs of TextArea, rather than switch to a new API.

You could simply extend TextArea/Skin and add functionality to superimpose the squiggly on top of TextArea.  You'll need to listen to several properties and make sure the clipping is set up correctly and you handle the scrolling et cetera, but I think it's doable.

Of course, once you decide that you need to further decorate your text, with let's say highlighted areas, then you might as well use the new component.

By the way, **CodeArea** is specifically designed for that purpose, even has `getText()` and `setText()` - but no textProperty because it's designed to work with large documents.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702187490

From angorya at openjdk.org  Fri Aug  2 18:37:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Aug 2024 18:37:38 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <4JnTmcqWMFRGiISe8BHeQntGJIb38rNdlOgBnS54jDE=.67aa1637-303f-40bc-be87-56cc9b0a2af8@github.com>
 <m8W8xPcK9XnWGsxi4V_Q4yIkiEOrvIGxXICAaD9_2dM=.0be9f84d-b170-49fc-b253-92a4efa61de5@github.com>
 <d_tJOEuLrzdTT1goK61veGcB8ZreCMiKLWxvECsn5Oo=.8cba5580-0d01-4eb9-807b-d5a9b0b5f095@github.com>
 <7AtaWg8Dvq0G0cJmEacIqaZICd0t6tzzEU05IoeHrEU=.460b03ad-08b9-44ca-bd01-58d5aa15b5d6@github.com>
Message-ID: <lH5UW5y6Z36KcCPHdKcHorQST0uIszvSQSth5tPsu1c=.bf083862-f30f-4891-8c0f-c5e544ef5334@github.com>

On Fri, 2 Aug 2024 18:30:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I was hoping to be able to easily replace one (old) control with the _new_ one. I mean `RichTextArea` still fulfilling the requirements of `TextInputControl`. Anyhow, I understand you rational not going along this path ?
>> 
>> Let me provide the use-case I have in mind (which may explain better what I am looking for).
>> I would like to use/keep textfields and textareas with pure text. Anyhow, having the  possibility to _squiggly_ parts of the text showing spelling mistakes. Since I assume that loading many `RichTextArea` controls (i.e., in tables) will take much longer I expect to offer spelling suggestions (and `RichTextArea`  loading) on request only.
>
> It looks like in this particular case you do want to preserve the semantics and APIs of TextArea, rather than switch to a new API.
> 
> You could simply extend TextArea/Skin and add functionality to superimpose the squiggly on top of TextArea.  You'll need to listen to several properties and make sure the clipping is set up correctly and you handle the scrolling et cetera, but I think it's doable.
> 
> Of course, once you decide that you need to further decorate your text, with let's say highlighted areas, then you might as well use the new component.
> 
> By the way, **CodeArea** is specifically designed for that purpose, even has `getText()` and `setText()` - but no textProperty because it's designed to work with large documents.

You might be right about impact on performance when trying to use many RichTextArea (RTA) controls as table cells - it is indeed a heavier component, but as long as you ensure there are no memory leaks and your table does not show 1000s of cells on screen we should be ok.

If performance is an issue, a full blown editor might indeed be overkill, and you might be better off created a subclass of Labeled adorned with decorations instead.  You can always set up RTA as an editor if you need to.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702191592

From mfox at openjdk.org  Fri Aug  2 19:12:47 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 2 Aug 2024 19:12:47 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled
 differently depending on the useSystemMenuBar value
Message-ID: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>

macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar.

We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.

This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.

I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into sysmenudup
 - Updated robot test to run on other platforms
 - Added Robot test
 - If JavaFX processes a shortcut it is not sent on to the system menu bar

Changes: https://git.openjdk.org/jfx/pull/1528/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8087863
  Stats: 279 lines in 12 files changed: 242 ins; 0 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1528.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1528/head:pull/1528

PR: https://git.openjdk.org/jfx/pull/1528

From andy.goryachev at oracle.com  Fri Aug  2 19:41:00 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 2 Aug 2024 19:41:00 +0000
Subject: RichTextArea: API Review
Message-ID: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>

Dear fellow developers:



Thank you for the early feedback on the RichTextArea proposal [0].



We are moving to the next phase by submitting the public pull request [1].  The main goal is to include the new control in an incubating module [8], hopefully in jfx24, as a means of putting non-final API in the hands of developers while the API and implementation progress towards either finalization or removal in a future release.



For your convenience, two test applications are provided - RichTextAreaDemoApp and CodeAreaDemoApp which demonstrate the new controls with a number of different models.  In addition to these two testers, please check out a simple standalone rich text editor application, RichEditorDemoApp,



We would encourage anyone - the javafx developers, and especially the application developers, to take a look at the public API [3].  It's probably less important at this stage to do a deep code review of the implementation, but we would certainly appreciate and welcome your code review comments.



Thank you in advance,

-andy





[0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md

[1] Pull request: https://github.com/openjdk/jfx/pull/1524

[2] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md

[3] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc

[4] CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html

[5] Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md

[6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[7] Previous (now obsolete) draft pull request: https://github.com/openjdk/jfx/pull/1374

[8] Incubator module JEP: https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240802/c723d3d5/attachment-0001.htm>

From kcr at openjdk.org  Fri Aug  2 20:15:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 20:15:37 GMT
Subject: RFR: 8337281: build.gradle assumes all modules are named
 "javafx.$project" [v2]
In-Reply-To: <Zykt1G8nR8KRfBDWqJN3X1mrzhQOXZfWw1eJpD-WCts=.86917c5e-32cc-4a89-9cf8-64e5d7ee6f7a@github.com>
References: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
 <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
 <Zykt1G8nR8KRfBDWqJN3X1mrzhQOXZfWw1eJpD-WCts=.86917c5e-32cc-4a89-9cf8-64e5d7ee6f7a@github.com>
Message-ID: <XU0bCUms66-1bXlhDJNeIs3vvZPavLn7ufW_nJXvv7A=.1c71b2ea-f755-4f07-aecd-4790b140fadc@github.com>

On Tue, 30 Jul 2024 12:41:24 GMT, Johan Vos <jvos at openjdk.org> wrote:

> In general, these changes look ok (and are indeed fixing an issue).

Thanks.

> I keep hoping that changes to build.gradle lead to a smaller file, but the monolith is only getting bigger (more lines). It would be great if more logic can be split into a separate file, which would make the huge build.gradle a bit more maintainable, but I understand this is not trivial.

Yeah, that would be a big job,

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

PR Comment: https://git.openjdk.org/jfx/pull/1518#issuecomment-2266078265

From kcr at openjdk.org  Fri Aug  2 20:15:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 20:15:38 GMT
Subject: RFR: 8337281: build.gradle assumes all modules are named
 "javafx.$project" [v2]
In-Reply-To: <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
References: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
 <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
Message-ID: <YMxFzcdrHpI-ATWerjw_8uH1EAaMNPrRq5AuaKXgf2M=.6f42b004-43d7-4f45-a2c4-3f1680ffcf8c@github.com>

On Fri, 26 Jul 2024 23:00:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced.
>> 
>> I discovered this while working on the following two RFEs, both of which hit this bug:
>> 
>> [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules
>> [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX
>> 
>> Both of them need this bug to be fixed, so I am separating it out into its own issue.
>> 
>> ### Notes to reviewers
>> 
>> Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit.
>> 
>> I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug where String was being used as if it were a Project

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jfx/pull/1518#issuecomment-2266078522

From kcr at openjdk.org  Fri Aug  2 20:15:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 20:15:39 GMT
Subject: RFR: 8337281: build.gradle assumes all modules are named
 "javafx.$project" [v2]
In-Reply-To: <9u2HU2DxK7ZCQmm9RDI9l43nkRIQxZQ8ncXpfCWQCzA=.79c198ab-8588-4be8-8206-8293b0e5964b@github.com>
References: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
 <HTfNyTJTCcKR3Sjt0HnJ6sjRtCbq5SSk0z6Xb2AP-0w=.c729a392-53ab-4349-ae26-379142cf10ac@github.com>
 <9u2HU2DxK7ZCQmm9RDI9l43nkRIQxZQ8ncXpfCWQCzA=.79c198ab-8588-4be8-8206-8293b0e5964b@github.com>
Message-ID: <fUD0KI79X-wXP4VP3BVwztXw7NAm2M8za3gK5_qKcaY=.b52e9e86-8a0f-4959-b377-1f4f7209ff1e@github.com>

On Mon, 29 Jul 2024 23:11:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug where String was being used as if it were a Project
>
> build.gradle line 970:
> 
>> 968: 
>> 969:     if (HAS_JAVAFX_MODULES) {
>> 970:         List<String> modsWithNative = [ 'javafx.graphics', 'javafx.media', 'javafx.web' ]
> 
> very minor: maybe one entry per line?

I'd prefer not to at this point.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1518#discussion_r1702279337

From kcr at openjdk.org  Fri Aug  2 20:15:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 2 Aug 2024 20:15:39 GMT
Subject: Integrated: 8337281: build.gradle assumes all modules are named
 "javafx.$project"
In-Reply-To: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
References: <bdGFuBzwTkNdXjLggn5--icrXR83_VxlXyOt09tbc3k=.936f043d-8075-4506-ae47-4a4eacb24787@github.com>
Message-ID: <5bu-XqMLuInu-43K81ffoGWHUD-DMmQPlRNZ8tF7aOY=.d09e07b7-1516-4c82-a635-c8cf31f90b3b@github.com>

On Fri, 26 Jul 2024 17:04:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR fixes a bad assumption in a few places in `build.gradle`, which assumes that the module name can be derived from the name of the gradle project name by prepending `"javafx."` to the name rather than using the `moduleName` property of the project. In many of these places, the logic replaces dots with dashes in the name, but it does so by prefixing the project name with `"javafx-"` rather than doing a string replacement. This means that a module with more than one dot will only have the first one replaced.
> 
> I discovered this while working on the following two RFEs, both of which hit this bug:
> 
> [JDK-8309381](https://bugs.openjdk.org/browse/JDK-8309381): Support JavaFX incubator modules
> [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280): Include jdk.jsobject module with JavaFX
> 
> Both of them need this bug to be fixed, so I am separating it out into its own issue.
> 
> ### Notes to reviewers
> 
> Most of the problematic logic is in the maven publication method, which is only enabled via `gradle -PMAVEN_PUBLISH=true` (in the absence of any other params, that won't actually try to publish anything, so is safe to use for testing). I left in some print statements for the purpose of testing, that I will remove with the next commit.
> 
> I tested this with the following branch, which is a preliminary prototype of adding jdk.jsobject to the build with the fix from _this_ PR applied: [test-module-name-jsobject](https://github.com/kevinrushforth/jfx/tree/test-module-name-jsobject).

This pull request has now been integrated.

Changeset: 0fa50cbb
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0fa50cbbd9878ca7ec0e1bfcc5567bf52e3b8db2
Stats:     19 lines in 1 file changed: 13 ins; 0 del; 6 mod

8337281: build.gradle assumes all modules are named "javafx.$project"

Reviewed-by: angorya, arapte

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

PR: https://git.openjdk.org/jfx/pull/1518

From almatvee at openjdk.org  Fri Aug  2 20:43:38 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 2 Aug 2024 20:43:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <ceLh90FhWpwXivGhurs_wJ1Cg7iypQaBbfCIOGAD09Y=.021217b1-5668-482c-9d3e-d563623011b2@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <y40xxblLjEzMM23YTxa_gOYdLaiDxZ2JB-jsok4Pr18=.52056664-7127-46ce-aad5-d5bccc6228e7@github.com>
 <XRpJwzM8GnlQaP4jznySrNFm3Ozde9CEaSdezJbW-No=.5f105cba-315e-4e83-bfc8-49e5aa0d61fd@github.com>
 <6SjJ-Qg4h5drluEF-x1lttkjCW-9iv3d_TZBkAGJN0Y=.93f76c56-5c1c-4138-8150-3a700d882fc7@github.com>
 <QlGvOWTsZFj1Cm_RhNQtprYx2B3KbvC2Mk3zSTH6Nw4=.1b91282d-e720-479f-90de-8783bc05be5a@github.com>
 <ceLh90FhWpwXivGhurs_wJ1Cg7iypQaBbfCIOGAD09Y=.021217b1-5668-482c-9d3e-d563623011b2@github.com>
Message-ID: <ttu3TmPCOTxHGd6wbvvzGdU4ldx-GMzpGLsW6gNfAlY=.d46191b2-a7e2-41be-8182-8923f234a287@github.com>

On Thu, 1 Aug 2024 23:56:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > I think this issue/PR should specify it.
> 
> The main reason to mention what needs to be corrected is to help the person who will be working on JDK-8337686 many years from now ;-)

Done.

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2266118943

From jhendrikx at openjdk.org  Fri Aug  2 22:36:57 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Aug 2024 22:36:57 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
Message-ID: <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>

On Fri, 2 Aug 2024 21:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35:
> 
>> 33:  * Identifies a class that supports component-wise CSS transitions.
>> 34:  * <p>
>> 35:  * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions.
> 
> Why is the name not `ComponentInterpolatable`?

I see two uses of this interface, both in combination with `Interpolatable`.  Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not?

Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation?

It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702341296

From jhendrikx at openjdk.org  Fri Aug  2 22:36:57 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Aug 2024 22:36:57 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
Message-ID: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>

On Fri, 2 Aug 2024 01:39:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix since tag
>  - adjust table styling

I only managed to get partially through this, it's a lot of changes.  Left some comments so far.

modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 78:

> 76: 
> 77:         int index = 0;
> 78:         int numNonNullValues = 0;

It seems to me, just one of these variables is sufficient.  They both start at `0` and both are incremented at the same time.

modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 81:

> 79: 
> 80:         @SuppressWarnings("unchecked")
> 81:         T[] newValues = (T[])new Object[list.size()];

With many `null`s this array may be too big.  If that's intended, then ignore this comment.

modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 123:

> 121:             if (elements[i] != null) {
> 122:                 newValues[j++] = elements[i];
> 123:                 ++numNonNullValues;

Both `j` and `numNonNullValues` are always the same.  Could eliminate one.

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/PaintUtils.java line 102:

> 100:                 source.getEndX(), source.getEndY(),
> 101:                 source.isProportional(),
> 102:                 source.getCycleMethod(),

Should these be copied from the source?  When the gradient is solid, they could be set to constants.

modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183:

> 181:      *     <li>If the intermediate list is shallow-equal to the first list passed into the method (i.e. its
> 182:      *         elements are references to the same objects), the existing list is returned.
> 183:      *     <li>If a new list is returned, it is unmodifiable.

Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable).  Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed.

modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197:

> 195:         if (secondList.isEmpty()) {
> 196:             return firstList.isEmpty() ? firstList : secondList;
> 197:         }

This logic looks odd.  If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty).  So, this is equivalent?
Suggestion:

        if (secondList.isEmpty()) {
            return List.of();  // suggested here, as the two input lists are not guaranteed to be immutable
        }

modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 230:

> 228:      * shallow-equal to the list that is passed into this method, i.e. its elements are references
> 229:      * to the same objects. The existing list is returned in this case.
> 230:      */

Was there a performance problem here?

Allocating 8 locals should be equivalent to an array of 8 elements that never escapes (ie. JIT optimizes this). Then either JIT is smart enough to conditionally allocate a heap object and copy the array there, or you can help it by cloning that local array and letting only the clone escape.

modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 311:

> 309:                 }
> 310:             }
> 311:         }

You could write this without nesting using `switch`:


switch(listSize) {
case 8: newArray[7] = item7;  // fallthrough
case 7: newArray[6] = item6;
case 6: newArray[5] = item5;  
// etc
}

modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 330:

> 328: 
> 329:         if (secondArraySeries.length == 0) {
> 330:             return firstArraySeries.length == 0 ? firstArraySeries : secondArraySeries;

Same comment as on the other function.  I find it suspect.  Is there code relying on a **specific** array being returned?  If so then that probably should be documented.  Otherwise just immediately return `secondArraySeries`?

modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35:

> 33:  * Identifies a class that supports component-wise CSS transitions.
> 34:  * <p>
> 35:  * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions.

Why is the name not `ComponentInterpolatable`?

modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 268:

> 266:      * @since 24
> 267:      */
> 268:     public Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value) {

I know the name `convert` wasn't all that great (it probably should have been `construct`, `parse` or `deserialize`), but I think `convertBack` is not that great either.  Have you considered `toMetaData`, `revert`, `serialize` or `deconstruct`?

modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java line 117:

> 115:      *
> 116:      * @throws NullPointerException {@inheritDoc}
> 117:      * @since 23

Should this be `24`?

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

> 9018:             if (timer != null) {
> 9019:                 if (result == null) {
> 9020:                     result = new HashMap<>(5);

I think that when you specify map sizes like this, it might be worth a comment at the intent.  Did you intend to create a map that can hold 6 items before resizing?  (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor).  If you want to express the intent more clearly, use `HashMap.newHashMap(5)`.

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

> 9104: 
> 9105:         // Make a copy of the list, because completing the timers causes them to be removed
> 9106:         // from the list, which would result in a ConcurrentModificationException.

Comment is out of date

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

> 9105:         // Make a copy of the list, because completing the timers causes them to be removed
> 9106:         // from the list, which would result in a ConcurrentModificationException.
> 9107:         for (TransitionTimer timer : Map.copyOf(transitionTimers).values()) {

If you only need a copy of the values, copying the whole map is a bit overkill.  How about `List.copyOf(transitionTimers.values())` ?  Lists are also much faster than maps for this purpose.

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

PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2215813399
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701977895
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701979810
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701980936
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1701997212
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702322235
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702318609
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702330147
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702331405
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702333480
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702335141
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702351819
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702368300
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702373249
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702373633
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702374898

From mstrauss at openjdk.org  Fri Aug  2 23:50:12 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 2 Aug 2024 23:50:12 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v6]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <A_YfTWwUF-5lILgngfZ1zckvGsL5J9jXmjkOmWMYKAo=.5b4d2502-1c1e-4c2b-82fa-07dfca59d27c@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/3b8fa919..10705a32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=04-05

  Stats: 12 lines in 3 files changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sat Aug  3 00:17:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 00:17:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
Message-ID: <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>

On Fri, 2 Aug 2024 21:38:04 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/ComponentTransitionable.java line 35:
>> 
>>> 33:  * Identifies a class that supports component-wise CSS transitions.
>>> 34:  * <p>
>>> 35:  * Component-wise transitions offer more flexibility than {@link Interpolatable} transitions.
>> 
>> Why is the name not `ComponentInterpolatable`?
>
> I see two uses of this interface, both in combination with `Interpolatable`.  Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not?
> 
> Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation?
> 
> It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`).

`ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called).

It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions.

This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically).

Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415097

From mstrauss at openjdk.org  Sat Aug  3 00:17:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 00:17:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
Message-ID: <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>

On Fri, 2 Aug 2024 15:06:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 78:
> 
>> 76: 
>> 77:         int index = 0;
>> 78:         int numNonNullValues = 0;
> 
> It seems to me, just one of these variables is sufficient.  They both start at `0` and both are incremented at the same time.

Yes, I've removed one of the variables.

> modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 81:
> 
>> 79: 
>> 80:         @SuppressWarnings("unchecked")
>> 81:         T[] newValues = (T[])new Object[list.size()];
> 
> With many `null`s this array may be too big.  If that's intended, then ignore this comment.

That may be the case, but I think that's preferrable to requiring two iterations of the list (one to figure out how many non-null values it contains, the second to copy over the values). In practice, there shouldn't be any nulls in most cases, as I don't know why someone would construct a `Background` or `Border` with many nulls in there.

> modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 123:
> 
>> 121:             if (elements[i] != null) {
>> 122:                 newValues[j++] = elements[i];
>> 123:                 ++numNonNullValues;
> 
> Both `j` and `numNonNullValues` are always the same.  Could eliminate one.

You're right.

> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/PaintUtils.java line 102:
> 
>> 100:                 source.getEndX(), source.getEndY(),
>> 101:                 source.isProportional(),
>> 102:                 source.getCycleMethod(),
> 
> Should these be copied from the source?  When the gradient is solid, they could be set to constants.

We can't interpolate between relative and absolute gradients (the interpolate method lacks the context necessary to convert between the two), so we need to copy these from source instead of always choosing one or the other.

> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183:
> 
>> 181:      *     <li>If the intermediate list is shallow-equal to the first list passed into the method (i.e. its
>> 182:      *         elements are references to the same objects), the existing list is returned.
>> 183:      *     <li>If a new list is returned, it is unmodifiable.
> 
> Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable).  Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed.

In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes.

> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197:
> 
>> 195:         if (secondList.isEmpty()) {
>> 196:             return firstList.isEmpty() ? firstList : secondList;
>> 197:         }
> 
> This logic looks odd.  If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty).  So, this is equivalent?
> Suggestion:
> 
>         if (secondList.isEmpty()) {
>             return List.of();  // suggested here, as the two input lists are not guaranteed to be immutable
>         }

The point of this excercise is to preferrably return existing instances, even when they are empty. `Border` and `Background` can contain quite a lot of objects, and often only one component is changed in a transition, while all of the rest is left unchanged. We want to elide the allocation of new objects if possible during transitions, which is why most classes check whether the result of an interpolation happens to be the same instance as either the start value or the end value.

> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 268:
> 
>> 266:      * @since 24
>> 267:      */
>> 268:     public Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value) {
> 
> I know the name `convert` wasn't all that great (it probably should have been `construct`, `parse` or `deserialize`), but I think `convertBack` is not that great either.  Have you considered `toMetaData`, `revert`, `serialize` or `deconstruct`?

I considered `deconstruct` and `decompose`, but I wanted to stress that it's the inverse of `convert`.

> modules/javafx.graphics/src/main/java/javafx/geometry/Insets.java line 117:
> 
>> 115:      *
>> 116:      * @throws NullPointerException {@inheritDoc}
>> 117:      * @since 23
> 
> Should this be `24`?

Yes.

> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9107:
> 
>> 9105:         // Make a copy of the list, because completing the timers causes them to be removed
>> 9106:         // from the list, which would result in a ConcurrentModificationException.
>> 9107:         for (TransitionTimer timer : Map.copyOf(transitionTimers).values()) {
> 
> If you only need a copy of the values, copying the whole map is a bit overkill.  How about `List.copyOf(transitionTimers.values())` ?  Lists are also much faster than maps for this purpose.

Good idea.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415018
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415036
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415039
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415068
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415084
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415079
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415105
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415114
PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702415138

From kizune at openjdk.org  Sat Aug  3 00:26:36 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 3 Aug 2024 00:26:36 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/CellArrangement.java line 263:

> 261:      */
> 262:     private int binarySearch(double localY, int low, int high) {
> 263:         //System.err.println("    binarySearch off=" + off + ", high=" + high + ", low=" + low); // FIX

Looks like remnants of the debugging session. Do you still need it?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1702417057

From mstrauss at openjdk.org  Sat Aug  3 00:42:59 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 00:42:59 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v7]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <dwu_pXPGrP5blCSFiSmQud4_es3vgehSGfRh5xKfX3U=.085bf10b-72a4-4043-bfe7-39423addf9c4@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  use switch instead of nested if

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/10705a32..3d12f772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=05-06

  Stats: 63 lines in 1 file changed: 0 ins; 35 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sat Aug  3 00:50:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 00:50:52 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v8]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <naDvGvgtf89Ywo7W7A_s-SKiBCCh9IIztLStVyvEN6Q=.81c262b3-1f04-4348-9da3-6a21e66fd4c4@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  use switch instead of nested if

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/3d12f772..6667dd55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=06-07

  Stats: 64 lines in 1 file changed: 0 ins; 35 del; 29 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sat Aug  3 00:56:59 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 00:56:59 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v9]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <L7i8vevgkmOEAZsmAv5-c-SaoumXtvYFZNTsMM_kliI=.dad4792a-d36b-482b-99cb-a9c4bb5db2cc@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  fix trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/6667dd55..14e91f14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=07-08

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

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sat Aug  3 10:06:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 10:06:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
Message-ID: <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>

On Fri, 2 Aug 2024 21:22:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 230:
> 
>> 228:      * shallow-equal to the list that is passed into this method, i.e. its elements are references
>> 229:      * to the same objects. The existing list is returned in this case.
>> 230:      */
> 
> Was there a performance problem here?
> 
> Allocating 8 locals should be equivalent to an array of 8 elements that never escapes (ie. JIT optimizes this). Then either JIT is smart enough to conditionally allocate a heap object and copy the array there, or you can help it by cloning that local array and letting only the clone escape.

There's no performance problem in the sense that my test application runs slowly in any noticeble way. It's one more piece of trying to minimize the allocation of objects in the very common case where nothing has changed.

Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? With your other suggestion of using `switch`, the code looks much cleaner already.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702668699

From jhendrikx at openjdk.org  Sat Aug  3 10:10:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 3 Aug 2024 10:10:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>
Message-ID: <V_svznS8rsP8A1SG44n4ilki3j2NpSTCCOJZ_kx2G8A=.05e145bb-e021-4b9a-b08d-4bc80f6cf14e@github.com>

On Sat, 3 Aug 2024 00:14:20 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 197:
>> 
>>> 195:         if (secondList.isEmpty()) {
>>> 196:             return firstList.isEmpty() ? firstList : secondList;
>>> 197:         }
>> 
>> This logic looks odd.  If the second list is empty, we return the first list **if** it is empty (and so empty is returned), otherwise the second list (which is also empty).  So, this is equivalent?
>> Suggestion:
>> 
>>         if (secondList.isEmpty()) {
>>             return List.of();  // suggested here, as the two input lists are not guaranteed to be immutable
>>         }
>
> The point of this excercise is to preferrably return existing instances, even when they are empty. `Border` and `Background` can contain quite a lot of objects, and often only one component is changed in a transition, while all of the rest is left unchanged. We want to elide the allocation of new objects if possible during transitions, which is why most classes check whether the result of an interpolation happens to be the same instance as either the start value or the end value.

But you are checking this with `equals` I hope?  `List.of()` is a constant, it doesn't allocate anything.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702670114

From mstrauss at openjdk.org  Sat Aug  3 10:10:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 3 Aug 2024 10:10:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
Message-ID: <pL5NsF8Qw91ZoqJAXWETrgXkD38j7IGAc7iC7i2BsSs=.82df7a9d-2b83-4a4a-8f4b-2e0303628734@github.com>

On Fri, 2 Aug 2024 22:30:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9020:
> 
>> 9018:             if (timer != null) {
>> 9019:                 if (result == null) {
>> 9020:                     result = new HashMap<>(5);
> 
> I think that when you specify map sizes like this, it might be worth a comment at the intent.  Did you intend to create a map that can hold 6 items before resizing?  (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor).  If you want to express the intent more clearly, use `HashMap.newHashMap(5)`.

I feel that the default initial capacity of 16 is more than can be reasonably expected for transitions. However, I did not use any rigorous methodology to come up with the number 5. I can add a comment, though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702670457

From jhendrikx at openjdk.org  Sat Aug  3 11:49:38 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 3 Aug 2024 11:49:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
Message-ID: <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>

On Sat, 3 Aug 2024 10:04:00 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior?

If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely.

Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it).  Optimized code is harder to reason about and harder to refactor.  For example, reading your code I've been left wondering:

- Why is it significant to return a specific instance?  Are you using `==` to compare these in callers?  That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`")
- The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined).  Is this even happening in practice (are there any non-`RandomAccesss` lists used?)  Is the performance gain worth the extra complexity?  Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them?
- Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores).

Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem?  That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702717395

From mhanl at openjdk.org  Sat Aug  3 13:53:36 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 3 Aug 2024 13:53:36 GMT
Subject: RFR: 8320232: Cells duplicated when table collapsed and expanded
In-Reply-To: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
References: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
Message-ID: <e7UQiaqEeHQ93unggs4pGrz1v33NmyOWQZIapV0tQrQ=.ceed50e9-7281-4154-87fa-784c9e0ff79a@github.com>

On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing.
> 
> The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. 
> This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node).
> 
> The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells.
> So before we clear the pile (or cells), we always reset the index to -1.
> Added a bunch of tests, some pass before and after.

I agree the minor change is unrelated, but since it is that small for a test I had written in the past, I decided to keep it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1521#issuecomment-2266718230

From mhanl at openjdk.org  Sat Aug  3 13:53:36 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 3 Aug 2024 13:53:36 GMT
Subject: Integrated: 8320232: Cells duplicated when table collapsed and
 expanded
In-Reply-To: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
References: <ysaO_dRYL1HRXnhkD4sKXzvl7e415oEAMHsRVuKJXd8=.8cfd6f80-fb12-4a9e-b52c-badd4df682db@github.com>
Message-ID: <ck7nW-EYKYHUYGBI6Og8t2vAiCxy10KqaMDGmwHb9aU=.415554fe-9ae8-40c1-8742-06e66cd649a4@github.com>

On Mon, 29 Jul 2024 18:45:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where a `TableView` inside a `TitledPane` may 'duplicate' the cells. This actually has nothing to do with the `TitledPane`, but it triggered the bug easily due to its nature to change the size of his content when collapsing.
> 
> The expansion change of a `TitledPane` triggered an event where the underlying `VirtualFlow` was adding cells to the pile (for reuse) and later cleaning them all up without resetting the index to -1. 
> This led to a bug where two cells had the same index and therefore received an edit event, although just one should (and is visible, the other cell has no parent -> orphan node).
> 
> The fix is to always reset the index to -1. This was already done before, just not everywhere, for all cells.
> So before we clear the pile (or cells), we always reset the index to -1.
> Added a bunch of tests, some pass before and after.

This pull request has now been integrated.

Changeset: 28e3ccc7
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/28e3ccc7331952b4d323941c8efc97509348b1e2
Stats:     184 lines in 4 files changed: 177 ins; 0 del; 7 mod

8320232: Cells duplicated when table collapsed and expanded

Reviewed-by: angorya, kcr

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

PR: https://git.openjdk.org/jfx/pull/1521

From jhendrikx at openjdk.org  Sat Aug  3 14:11:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 3 Aug 2024 14:11:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
 <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>
Message-ID: <md7GpViTs0wM3YSfpto_OUHWon-qMrmkdRo4kgxIVQE=.8b4304ba-e2a9-41d4-9381-6017a4f3a056@github.com>

On Sat, 3 Aug 2024 11:43:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There's no performance problem in the sense that my test application runs slowly in any noticeble way. It's one more piece of trying to minimize the allocation of objects in the very common case where nothing has changed.
>> 
>> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior? With your other suggestion of using `switch`, the code looks much cleaner already.
>
>> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior?
> 
> If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely.
> 
> Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it).  Optimized code is harder to reason about and harder to refactor.  For example, reading your code I've been left wondering:
> 
> - Why is it significant to return a specific instance?  Are you using `==` to compare these in callers?  That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`")
> - The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined).  Is this even happening in practice (are there any non-`RandomAccesss` lists used?)  Is the performance gain worth the extra complexity?  Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them?
> - Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores).
> 
> Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem?  That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance.

Sorry if this came across as a bit negative, it's not intended in that way.  I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702784473

From jhendrikx at openjdk.org  Sat Aug  3 14:23:38 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 3 Aug 2024 14:23:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <_VXULhjdYS0V_KY3m0CHZrfVAevz1mkKmpniLOSxUfA=.a9670e8c-1297-4e43-a0c3-bcb12ae077b7@github.com>
Message-ID: <pp4G0eW6fwvd3VWW3zXaYriI9ZU7PBPGi-IH2eUUgJY=.ff87c6c8-3eac-45da-b8e2-165915e35d4c@github.com>

On Fri, 2 Aug 2024 01:32:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 331:
>> 
>>> 329: 
>>> 330:         for (int i = 0, max = strokes.size(); i < max; i++) {
>>> 331:             final BorderStroke stroke = strokes.get(i);
>> 
>> just curious: do we really need `final` keyword for local variables after java8?
>
> I don't use it, but I didn't change the existing code here.

> just curious: do we really need `final` keyword for local variables after java8?

It's superfluous, and only useful if you are not initializing it immediately and you still want to force a single assignment.  If you always immediately initialize locals (either using a method call or through a ternary (`?:`)) then the `final` keyword is definitely just noise.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702788647

From jhendrikx at openjdk.org  Sat Aug  3 14:48:37 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 3 Aug 2024 14:48:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
 <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>
Message-ID: <iukcqTCybe6aduw57wDFI3Zq0wHYLyHpg78oK_nh3ro=.46fe19ac-84bf-4d0f-91eb-7fb6cbdc4ef1@github.com>

On Sat, 3 Aug 2024 00:14:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I see two uses of this interface, both in combination with `Interpolatable`.  Should this just extend `Interpolatable`, or are there cases to be expected where this marker is present but `Interpolatable` is not?
>> 
>> Also, have you considered adding a default method to `Interpolatable` to indicate it supports component wise interpolation?
>> 
>> It looks modelled after `RandomAccess`, but the reasons for that being a marker interface are not similar to this situation (it is a marker interface so it can also mark the old collections, like `Vector`).
>
> `ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called).
> 
> It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions.
> 
> This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically).
> 
> Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`).

I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`.  I think noting this information closer to the source would therefore be a good idea.

>From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter).

For both interpolation cases (`Interpotable` and `ComponentTransitionable`) you are getting the CSS meta data.  You can externalize that part.  When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result).  You can either:

- put the marker on `StyleConverter`
- have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable).
- have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..)

The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1702797888

From kcr at openjdk.org  Sat Aug  3 16:10:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 3 Aug 2024 16:10:38 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
Message-ID: <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>

On Thu, 1 Aug 2024 19:51:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: floating point precision in test, ensure unsigned int handling in Robot

The code changes all look good. Everything looks good on macOS. I finished all my testing, including testing with the metal pipeline.

The only thing needed is a timeout value on one of the tests to avoid hanging on Linux when running with a Wayland display server. I'll approve once you make that change.

tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218:

> 216:     // colors but they might both be working in the wrong space. We use an
> 217:     // AWT Robot to verify that they are working in sRGB.
> 218:     @Test

This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend:


    @Test(timeout = 15000)

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

PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2217065570
PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1702793337

From mfox at openjdk.org  Sat Aug  3 16:30:08 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 3 Aug 2024 16:30:08 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v6]
In-Reply-To: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
Message-ID: <xxaZYpOW-P-H0PpamoI71SI3csPzQ3M6xicMdJgwcmo=.a462117e-0104-46cb-92fe-4347e1db32d7@github.com>

> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
> 
> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
> 
> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
> 
> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
> 
> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Added timeout to test due to potential hang when using XWayland

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1473/files
  - new: https://git.openjdk.org/jfx/pull/1473/files/2dad883c..92b9c562

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=04-05

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

PR: https://git.openjdk.org/jfx/pull/1473

From kcr at openjdk.org  Sat Aug  3 16:35:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 3 Aug 2024 16:35:37 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v6]
In-Reply-To: <xxaZYpOW-P-H0PpamoI71SI3csPzQ3M6xicMdJgwcmo=.a462117e-0104-46cb-92fe-4347e1db32d7@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <xxaZYpOW-P-H0PpamoI71SI3csPzQ3M6xicMdJgwcmo=.a462117e-0104-46cb-92fe-4347e1db32d7@github.com>
Message-ID: <PZY0EIvgh2SLwk1z-2Yrg-5JvRm53WO_CGjPiwfua10=.1fcb2071-7dd6-4b49-9136-eea871830a32@github.com>

On Sat, 3 Aug 2024 16:30:08 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added timeout to test due to potential hang when using XWayland

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2217103583

From philip.race at oracle.com  Sat Aug  3 21:41:44 2024
From: philip.race at oracle.com (Philip Race)
Date: Sat, 3 Aug 2024 14:41:44 -0700
Subject: Font hinting on Linux
In-Reply-To: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>
References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>
Message-ID: <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com>

There's not many knobs available. Hinting is not enabled - and that's 
commonly the case on modern plartforms.
LCD is your best option for readibility of static text, which is why it 
is the default for UI Controls,
It should reduce the pixel grid fitting uneveness you highlight but 
doesn't eliminate it.
Note : this presumes that the freetype on your system enables LCD .. if 
it doesn't there's nothing FX can do about that.

-phil.


On 8/2/24 10:43 AM, quizynox at gmail.com wrote:
> Hello,
>
> Sorry for asking here, but I seem to have tried everything I could 
> find on SO/Reddit/JBS etc. Could someone please share what font 
> settings I should be using to get decent font hinting on Linux? Please 
> see the screenshot.
>
> https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view
>
> I'm not very picky, but the font I see is just not suitable for 
> presenting app to customers. I've tried enabling and disabling hinting 
> and autohinting, using different hinting styles, changing the font 
> smoothing type and prism.lcdtext etc. Unfortunately no matter what I 
> do, the font hinting is always bad.
>
> Fedora, KDE, all latest versions.
>


From mstrauss at openjdk.org  Sun Aug  4 14:25:22 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 14:25:22 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v10]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <5Y2cOCDIkHehbJwQY37ZrNosMUeNzKNVz9EQpkj-vj4=.5f041280-38cb-468b-8007-031f5ac7b114@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  move interpolation helpers to separate file

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/14e91f14..4257d2f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=08-09

  Stats: 891 lines in 21 files changed: 415 ins; 408 del; 68 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 14:33:18 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 14:33:18 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v11]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <suC0Tqm_8yOjupHaHJXRNGwHie12yOfBCHfvablWU8o=.1b37e505-3e95-41f6-a8f2-804de97e1789@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  added comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/4257d2f6..843713bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=09-10

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 14:54:36 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 14:54:36 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <md7GpViTs0wM3YSfpto_OUHWon-qMrmkdRo4kgxIVQE=.8b4304ba-e2a9-41d4-9381-6017a4f3a056@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
 <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>
 <md7GpViTs0wM3YSfpto_OUHWon-qMrmkdRo4kgxIVQE=.8b4304ba-e2a9-41d4-9381-6017a4f3a056@github.com>
Message-ID: <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com>

On Sat, 3 Aug 2024 14:09:19 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> Do you think it is preferrable to appeal to JIT magic instead of explicitly coding the behavior?
>> 
>> If the code leads to less questions and is more readable for it, and there is no reason to optimize in the first place (ie. you didn't see a problem), then yes, definitely.
>> 
>> Premature optimization only leads to questions by reviewers and future maintainers (they will wonder why the code was optimized, but probably assume there was a good reason for it).  Optimized code is harder to reason about and harder to refactor.  For example, reading your code I've been left wondering:
>> 
>> - Why is it significant to return a specific instance?  Are you using `==` to compare these in callers?  That's very counter to the nature of Java, and so deserves at a minimum a justification ("performance") and a warning ("careful, callers use `==`")
>> - The extra code paths for `RandomAccess` or not, in an attempt to avoid an iterator allocation (which may not even happen when inlined).  Is this even happening in practice (are there any non-`RandomAccesss` lists used?)  Is the performance gain worth the extra complexity?  Is it worth not having these functions inline into callers, as larger functions mean JIT won't inline them?
>> - Avoiding allocating small arrays; was this a performance problem that would justify writing a function that is now too large to inline? You're trading potential JIT inlining for an almost free heap allocation (Java allocation's are the equivalent of a pointer increment + background GC activity on likely **idling** CPU cores).
>> 
>> Would it not have been much better to write the code as simple as possible first, get it passed review well understood by everyone, then maybe, possibly get back to it later with an optimizing PR if there is a performance problem?  That last bit is entirely optional and may never happen if it turns out these few transition allocations are but a drop in the bucket of the overall CSS performance.
>
> Sorry if this came across as a bit negative, it's not intended in that way.  I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify.

I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance.

Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area.

The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance.

Let's look at the `Border.interpolate()` implementation:

@Override
public Border interpolate(Border endValue, double t) {
    Objects.requireNonNull(endValue, "endValue cannot be null");
    if (t <= 0) return this;
    if (t >= 1) return endValue;

    // interpolateListsPairwise() is implemented such that it returns existing list instances
    // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result
    // is shallow-equal to either of the input arguments. This allows us to very quickly detect
    // if we can return 'this' or 'endValue' without allocating a new Border instance.
    List<BorderImage> newImages = images == endValue.images ?
        images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t);

    List<BorderStroke> newStrokes = strokes == endValue.strokes ?
        strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t);

    if (images == newImages && strokes == newStrokes) {
        return this;
    }

    if (endValue.images == newImages && endValue.strokes == newStrokes) {
        return endValue;
    }

    return new Border(newStrokes, newImages);
}


`interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interpolation basically free. The alternative to this would be to either pointlessly call `equals()` on a large object graph again and again, or to always return a new `Border` instance.

This optimization scheme works precisely because all types that are involved make sure to return existing instances when the result is known to be interchangable with an existing instance. This is also the reason why your other suggestion of returning `List.of()` instead of an existing empty list wouldn't work.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703242183

From mstrauss at openjdk.org  Sun Aug  4 15:09:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 15:09:16 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v12]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <W4Xqnjt3ipRKQ4f92aNHKMzaUdUMhgp3M_OXZ_J2GRc=.d8be0fa8-ed1c-43fd-bb13-d89e5d590749@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  move tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/843713bf..0def5d1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=10-11

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 15:35:13 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 15:35:13 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v13]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <T-Qrnc6c_ewi2uSmPpySaYam2NHR9h1fcxgrY-zt6Cw=.5147276b-594b-4f10-8189-58f994db29f8@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  remove ComponentTransitionable

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/0def5d1a..34372675

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=11-12

  Stats: 87 lines in 8 files changed: 11 ins; 59 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 15:35:13 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 15:35:13 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <iukcqTCybe6aduw57wDFI3Zq0wHYLyHpg78oK_nh3ro=.46fe19ac-84bf-4d0f-91eb-7fb6cbdc4ef1@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
 <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>
 <iukcqTCybe6aduw57wDFI3Zq0wHYLyHpg78oK_nh3ro=.46fe19ac-84bf-4d0f-91eb-7fb6cbdc4ef1@github.com>
Message-ID: <FpaKubL3RneMHcv5J7_eEywtF0lbxsmeqrU1DyYib84=.99ac8830-7370-47cd-9df0-1c6c4f406e2d@github.com>

On Sat, 3 Aug 2024 14:45:50 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> `ComponentTransitionable` is kind of orthogonal to `Interpolatable`. It tells us to first decompose the object, and then transition each component separately. `Border` and `Background` implement both interfaces, but `Interpolatable` is not used for CSS transitions (i.e. `Border.interpolate()` is not called).
>> 
>> It doesn't make much sense to add a default method to `Interpolatable` to indicate component-wise transitions, because we can't use the `interpolate()` method for component-wise transitions.
>> 
>> This should be thought of as two paths: we either use `Interpolatable`, or we use the decompose-reconstruct route (which is only available to CSS, but not programmatically).
>> 
>> Now, the name might also be `ComponentInterpolatable`, but this suggests a close proximity to `Interpolatable` (being in the `javafx.animation` package, having a programmatic API, etc). However, `ComponentTransitionable` only works for objects that expose their components to CSS (which is why it is located in `javafx.css` and not `javafx.animation`).
>
> I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`.  I think noting this information closer to the source would therefore be a good idea.
> 
> From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter).
> 
> For both interpolation cases (`Interpolatable` and `ComponentTransitionable`) you are getting the CSS meta data.  You can externalize that part.  When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result).  You can either:
> 
> - put the marker on `StyleConverter`
> - have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable).
> - have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..)
> 
> The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched.

I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703262056

From mstrauss at openjdk.org  Sun Aug  4 16:03:52 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 16:03:52 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v14]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <5jZChobMyF-s5WEUnhFtOdmC36ng_JzZN84eAmTLeMY=.9ea6ae36-686c-4c3c-8c6d-470246b2aa44@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  add tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/34372675..b545617f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=12-13

  Stats: 110 lines in 1 file changed: 89 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 18:58:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 18:58:14 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v15]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <xbKSQrVMHq-ilR4Pp7Dh1pNW_iMWwEqtPSBBfHDVNJ8=.71127aee-1bd0-4abf-ade8-2e5600299f4e@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  add test for stop lists

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/b545617f..a2d0d6c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=13-14

  Stats: 28 lines in 2 files changed: 21 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 18:58:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 18:58:14 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <EBE_fVki3WNGo_ADHM4hq-hQzPMc8cfTDn1R5XFaxzg=.7f547146-8c8f-4d4b-a453-03f532b1bad1@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <EBE_fVki3WNGo_ADHM4hq-hQzPMc8cfTDn1R5XFaxzg=.7f547146-8c8f-4d4b-a453-03f532b1bad1@github.com>
Message-ID: <2ZHL3FmFygI4CKpYQFzNXIVubhO7ERuGJw5FyXvoHws=.524505a5-b580-4ef3-93a5-ea4981b2f0ca@github.com>

On Fri, 2 Aug 2024 16:02:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java line 264:
> 
>> 262:                 new Stop(1, color2)),
>> 263:             res);
>> 264:         }
> 
> Do you think any other combinations should be added, for completeness sake?
> 
> For example, let's consider two lists with 2 points each.  We might want to test scenarios:
> 
> 
> --
>      --
> 
> --|
>   |--
> 
> ---
>  ---
> 
> ----|
>  ---|
> 
> ------
>   --
> 
>   |-----
>   |--
> 
>   |---|
>   |---|
> 
>     |--
>   --|
> 
>      ---
> --
> 
> 
> and also have the two lists swapped maybe?
> 
> what do you think?

I've added another test, which gives us 100% coverage for all code paths. I would consider this complete.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703348960

From mstrauss at openjdk.org  Sun Aug  4 19:08:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 19:08:14 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v16]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <hIuKwyZ2oHRW_KtTbX0DopvXz5_Ywn_tDWIPD40zf5w=.e0d8e9bf-a0c2-46e5-915c-9a0ea3200c65@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  use HashMap.newHashMap()

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/a2d0d6c1..d7f21872

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=14-15

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Sun Aug  4 19:08:15 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 19:08:15 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <pL5NsF8Qw91ZoqJAXWETrgXkD38j7IGAc7iC7i2BsSs=.82df7a9d-2b83-4a4a-8f4b-2e0303628734@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <pL5NsF8Qw91ZoqJAXWETrgXkD38j7IGAc7iC7i2BsSs=.82df7a9d-2b83-4a4a-8f4b-2e0303628734@github.com>
Message-ID: <eDiyRgTuX1KDZbT9S9-8mxCFkDWNqv9SbV_Z95S4XhM=.58a26510-953b-4df2-be81-38babf16f582@github.com>

On Sat, 3 Aug 2024 10:08:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9020:
>> 
>>> 9018:             if (timer != null) {
>>> 9019:                 if (result == null) {
>>> 9020:                     result = new HashMap<>(5);
>> 
>> I think that when you specify map sizes like this, it might be worth a comment at the intent.  Did you intend to create a map that can hold 6 items before resizing?  (5 becomes 8, which is sufficient for 6 mappings with a 75% load factor).  If you want to express the intent more clearly, use `HashMap.newHashMap(5)`.
>
> I feel that the default initial capacity of 16 is more than can be reasonably expected for transitions. However, I did not use any rigorous methodology to come up with the number 5. I can add a comment, though.

I've added a comment and switched to `HashMap.newHashMap` as you suggested.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703353352

From swong at fcsllc.us  Sun Aug  4 20:37:24 2024
From: swong at fcsllc.us (Shing Wong)
Date: Sun, 4 Aug 2024 15:37:24 -0500
Subject: javafx.com is down. Can't find fxml schema.
Message-ID: <bfaae1de-2229-4770-9cc9-58adf37b914e@fcsllc.us>

Hi,

Before I posted this message, I already searched the list and Google. I 
didn't find anything about javafx.com being down. As a result, my old 
fxml code with xmlns pointed to javafx.com/fxml are having problems. 
Does anybody know what the deal is with javafx.com being down, and where 
can I find a copy of the schema for fxml?

-- 
Shing Wong
TEL: (504)913-6502


From jhendrikx at openjdk.org  Sun Aug  4 22:54:36 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 22:54:36 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
 <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>
 <md7GpViTs0wM3YSfpto_OUHWon-qMrmkdRo4kgxIVQE=.8b4304ba-e2a9-41d4-9381-6017a4f3a056@github.com>
 <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com>
Message-ID: <YN_sykybUW9op0FBjnYlEP7shgVVU5Qu-8EwpFWuzGY=.69a87535-35d7-4743-8823-b412415fe9fc@github.com>

On Sun, 4 Aug 2024 14:51:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Sorry if this came across as a bit negative, it's not intended in that way.  I just think optimizing too early has far more drawbacks than it has benefits. In part this is also a reflection on a lot of FX code; some code is clearly optimized from a C/C++ developer perspective which not only translates poorly to Java, but also makes the code "too dangerous" to modify.
>
> I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance.
> 
> Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area.
> 
> The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance.
> 
> Let's look at the `Border.interpolate()` implementation:
> 
> @Override
> public Border interpolate(Border endValue, double t) {
>     Objects.requireNonNull(endValue, "endValue cannot be null");
>     if (t <= 0) return this;
>     if (t >= 1) return endValue;
> 
>     // interpolateListsPairwise() is implemented such that it returns existing list instances
>     // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result
>     // is shallow-equal to either of the input arguments. This allows us to very quickly detect
>     // if we can return 'this' or 'endValue' without allocating a new Border instance.
>     List<BorderImage> newImages = images == endValue.images ?
>         images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t);
> 
>     List<BorderStroke> newStrokes = strokes == endValue.strokes ?
>         strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t);
> 
>     if (images == newImages && strokes == newStrokes) {
>         return this;
>     }
> 
>     if (endValue.images == newImages && endValue.strokes == newStrokes) {
>         return endValue;
>     }
> 
>     return new Border(newStrokes, newImages);
> }
> 
> 
> `interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interpolation basically free. The alternative to this would be to either pointle...

I think you said that you didn't actually test this, so we don't know if this will perform better. It's based on an assumption of what Java will do, and on assumptions what is "bad" and what is "good".  Without having tested this, you are optimizing blind.  I would be entirely satisfied if you had said "I tested this with a few thousand transitions, the allocation turned out to be a hot spot, so I optimized it which is the reason this code looks a bit out of the ordinary".

I also would have liked a comment explaining any pitfalls introduced by the optimization; the use of `==` by callers is unusual, and a crucial piece of information when I see code like:

        if (secondList.isEmpty()) {
            return firstList.isEmpty() ? firstList : secondList;
        }

It would deserve at least an explanation that you're specifically returning one of the passed in arguments so callers can do reference equality checks.

So you may have been wasting your time, and perhaps future maintainer time as well, making code less flexible, and harder to understand, maybe containing new bugs and edge cases for no real reason.

Java's JIT is very finicky.  For example, an earlier comment asked if the first `if` case is the most common one.  The assumption being that this will improve performance.  However, you can't make that assumption at all (I've done tests that show it's almost impossible to predict which "if order" will be faster on the JVM); re-arranging a function or "unrolling" it can have large negative consequences if that means the JIT will no longer inline your function.

Now, I will give you that this **probably** will be faster, but I'm making an assumption here... I really can't be sure.  That still leaves some explanatory comments that I think you should add with the assumptions that were made for this optimization.

>  If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance.

No, when hunting for performance problems, it will be readily apparent what total process is taking up all the time, and how often parts of it are being called and how much time they take in total.  Put a profiler on it, and see where the actual time is being spent on a case with a lot of transitions if you want to optimize it.

What optimization generally does is it that it makes code harder to understand (almost unavoidable when optimizing), the code will make more assumptions (which is where performance is gained), and will often require more debugging time and dealing with edge cases (more complex code has more bugs and edge cases, requiring more tests).  

When applied randomly to a code base (ie. without profiling) it only makes things harder for no tangible benefits, and closes off easy improvements later (undoing optimizations for a better alternative has been the topic of several of my PR's).  So if you're going to make something more complicated, and harder to refactor and extend later (which can have far greater pay-offs), then I'm saying there should be a good reason for it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703410399

From jhendrikx at openjdk.org  Sun Aug  4 22:58:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 22:58:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v16]
In-Reply-To: <hIuKwyZ2oHRW_KtTbX0DopvXz5_Ywn_tDWIPD40zf5w=.e0d8e9bf-a0c2-46e5-915c-9a0ea3200c65@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <hIuKwyZ2oHRW_KtTbX0DopvXz5_Ywn_tDWIPD40zf5w=.e0d8e9bf-a0c2-46e5-915c-9a0ea3200c65@github.com>
Message-ID: <K3agm_LqPE1WE0nFlOHhfESpc0rR8jsNkiI_Xe4rASc=.99f7b7e8-7d17-459f-944b-efb83d71d1ae@github.com>

On Sun, 4 Aug 2024 19:08:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use HashMap.newHashMap()

This is still a large PR, and I do want to help reviewing it, I will do my best to look it over further this week.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2267859957

From jhendrikx at openjdk.org  Sun Aug  4 22:58:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 22:58:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <FpaKubL3RneMHcv5J7_eEywtF0lbxsmeqrU1DyYib84=.99ac8830-7370-47cd-9df0-1c6c4f406e2d@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
 <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>
 <iukcqTCybe6aduw57wDFI3Zq0wHYLyHpg78oK_nh3ro=.46fe19ac-84bf-4d0f-91eb-7fb6cbdc4ef1@github.com>
 <FpaKubL3RneMHcv5J7_eEywtF0lbxsmeqrU1DyYib84=.99ac8830-7370-47cd-9df0-1c6c4f406e2d@github.com>
Message-ID: <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com>

On Sun, 4 Aug 2024 15:32:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I've taken a closer look, and I have the feeling that `ComponentTransitionable` is more of an indicator that the corresponding `StyleConverter` has implemented `convertBack`.  I think noting this information closer to the source would therefore be a good idea.
>> 
>> From what I can see, `applyComponentTransition` already falls back to calling `set(T)` if there is anything out of the ordinary (like missing CSS meta data or a missing StyleConverter).
>> 
>> For both interpolation cases (`Interpolatable` and `ComponentTransitionable`) you are getting the CSS meta data.  You can externalize that part.  When you have the meta data, you can get the `StyleConverter` and check if it supports deconstruction (instead of having a marker on the final result).  You can either:
>> 
>> - put the marker on `StyleConverter`
>> - have `convertBack` return an `Optional` or `null` if unsupported (there are already several `null` checks for missing CSS meta data or the missing converter, one more here seems not unreasonable).
>> - have a method on `StyleConverter` that indicates its capabilities (true/false, `SUPPORTS_DECONSTRUCTION`, etc..)
>> 
>> The advantage of this IMHO is that it keeps CSS concerns (component transitionable) in the CSS realm (with StyleConverter), while leaving simple classes that are just value holders (Border, Background) untouched.
>
> I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely.

Thanks, I think having this with the StyleConverter makes more sense.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703410832

From jhendrikx at openjdk.org  Sun Aug  4 23:04:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 23:04:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>
Message-ID: <I8xfoCkSBrm23ckhn4fkHuZTPCsnLpZ7QSYorOVZj5I=.62a50eab-c0b1-4e1b-a940-bb22d14126b3@github.com>

On Sat, 3 Aug 2024 00:14:23 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 183:
>> 
>>> 181:      *     <li>If the intermediate list is shallow-equal to the first list passed into the method (i.e. its
>>> 182:      *         elements are references to the same objects), the existing list is returned.
>>> 183:      *     <li>If a new list is returned, it is unmodifiable.
>> 
>> Well, it's documented, but I'd rather see this return an unmodifiable list in all cases (and not one of the input lists if it was determined to be modifiable).  Perhaps ensure this is compatible with `List.copyOf` so that copies are only made when needed.
>
> In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes.

Alright, I get how it works now, and that there is a lot of reference equality checking going on by callers.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703411678

From jhendrikx at openjdk.org  Sun Aug  4 23:12:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 23:12:39 GMT
Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v7]
In-Reply-To: <WjI-y2pzPjP4uif7TzXPgQJ_0cLHWLMyapJcOX3SGCE=.d0104711-e20e-4f7d-80cc-755972213805@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
 <GkzV4vOtlBoBh3iFSidiHk6jC6-Q-CadSCwk76XJOHU=.fa02059e-84c5-4442-89cd-f05d83d57de9@github.com>
 <WjI-y2pzPjP4uif7TzXPgQJ_0cLHWLMyapJcOX3SGCE=.d0104711-e20e-4f7d-80cc-755972213805@github.com>
Message-ID: <pn_B-l3YeS6ygrIqDwm0C3zLl0Ih3Ft3ZUilm3_Gxvs=.b2f0239e-466c-4741-bbab-e69aa92eb67c@github.com>

On Fri, 2 Aug 2024 17:51:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> re-tested on macOS, works as expected.
> 
> also tested in the Monkey Tester with the CSS provided in the ticket (errors appear in stderr as expected), and after the offending CSS is removed (gets back to normal).

Thanks for the extensive testing :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2267882804

From jhendrikx at openjdk.org  Sun Aug  4 23:12:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Aug 2024 23:12:39 GMT
Subject: Integrated: 8336389: Infinite loop occurs while resolving lookups
In-Reply-To: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
References: <k5dObhSC0cNLP7op58ZMxjtJPbAQT8Yzt4mKNZJSoUE=.ebab3fc6-07cb-45e4-beaf-f6ac660cfcef@github.com>
Message-ID: <fkq3OoqINZCD7s3S_YVjuMtbKkUAzCJJs9Jnszfa5n8=.92decf25-4117-4354-888c-0fee22fd7c34@github.com>

On Mon, 15 Jul 2024 13:21:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fixes an infinite loop that can occur while resolving lookups.
> 
> There were 2 bugs:
> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates
> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far
> 
> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code).

This pull request has now been integrated.

Changeset: f7ad5cdc
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f7ad5cdccb03162dc19fffb8eed570d4fbef490c
Stats:     171 lines in 2 files changed: 158 ins; 9 del; 4 mod

8336389: Infinite loop occurs while resolving lookups

Reviewed-by: angorya, kcr

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

PR: https://git.openjdk.org/jfx/pull/1505

From john.hendrikx at gmail.com  Sun Aug  4 23:30:16 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 5 Aug 2024 01:30:16 +0200
Subject: Detecting threading problems faster
Message-ID: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>

Hi list,

I know of quite some bugs and users that have been bitten by the 
threading model used by JavaFX.? Basically, anything directly or 
indirectly linked to an active Scene must be accessed on the FX thread.? 
However, as FX also allows manipulating nodes and properties before 
they're displayed, there can be no "hard" check everywhere to ensure we 
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a 
Platform.runLater wrapper was forgotten usually results in programs 
operating mostly flawlessly, but then fail in mysterious and random and 
hard to reproduce ways.? The blame is often put on FX as the resulting 
exceptions will almost never show the user code which was the actual 
culprit.? It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these 
bugs originating from user code much earlier, similar to the 
`ConcurrentModificationException` the collection classes do when 
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part 
of an active scene without too much of an performance impact, possibly 
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance 
(`getBean`).? This is an object, but we could check here if this 
instance implements an interface:

 ???? if (getBean() instanceof MayBePartOfSceneGraph x) {
 ?????????? if (x.isPartOfActiveScene() && !isOnFxThread()) {
 ??????????????? throw new IllegalStateException("Property must only be 
used from the FX Application Thread");
 ?????????? }
 ???? }

This check could be done on every set of the property, and potentially 
on every get as well.? It should be relatively cheap, but will expose 
problematic code patterns at a much earlier stage.? There's a chance 
that this will "break" some programs that seemed to be behaving 
correctly as well, so we may want to put it behind a switch until such 
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes, 
we can think of good names if this moves forward.


From mstrauss at openjdk.org  Sun Aug  4 23:56:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 4 Aug 2024 23:56:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <I8xfoCkSBrm23ckhn4fkHuZTPCsnLpZ7QSYorOVZj5I=.62a50eab-c0b1-4e1b-a940-bb22d14126b3@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <QpKI2QNworqMEEap6utvmCXMEwXtgSvlZx_6vXFmEQg=.4585c555-190a-425d-be10-9dda7fafdf47@github.com>
 <I8xfoCkSBrm23ckhn4fkHuZTPCsnLpZ7QSYorOVZj5I=.62a50eab-c0b1-4e1b-a940-bb22d14126b3@github.com>
Message-ID: <eXofyd8T-PouLnC3U0aesuRYPXHxjVH-5qsY_jOdQog=.1a5c5d50-d7d1-49ce-9e9b-f3a152faba60@github.com>

On Sun, 4 Aug 2024 23:01:48 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> In practice, any list that is passed into this method is already unmodifiable. This isn't a general-purpose method, it's tailored towards its usage for `Border` and `Background` interpolation, and the optimization scheme that is used in these classes.
>
> Alright, I get how it works now, and that there is a lot of reference equality checking going on by callers.

Let me explain how I got here in the first place. My observation is that `Background` and `Border` graphs can be quite large, and they are deeply immutable. But often, only tiny parts of it change during a transition. So my question was: wouldn't it be nice if we could re-use the unmodified parts of the graph, instead of copying it entirely, potentially tens of thousands of times per second?

The `Interpolatable` contract gives us permission to return an existing instance (and thereby reusing unmodified parts of the graph), so that's good. An initial implementation might look like this (note: this is not the implementation of this PR):


public Border interpolate(Border endValue, double t) {
    Objects.requireNonNull(endValue, "endValue cannot be null");

1:  if (t <= 0 || equals(endValue)) {
        return this;
    }

    if (t >= 1) {
        return endValue;
    }

    List<BorderImage> newImages =
        InterpolationUtils.interpolateListsPairwise(images, endValue.images, t);

    List<BorderStroke> newStrokes =
        InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t);

2:  if (this.images.equals(newImages) && this.strokes.equals(newStrokes)) {
        return this;
    }

3:  if (endValue.images.equals(newImages) && endValue.strokes.equals(newStrokes)) {
        return endValue;
    }

    return new Border(newStrokes, newImages);
}


I've marked three important lines with `1:` to `3:`. These equality comparisons traverse through the object graph many times, and unnecessarily so: each of the sub-objects' `interpolate` method will do the same thing, comparing the same objects recursively again.

So instead of doing a "root to leaf" equality comparison (i.e. starting at `Border` and comparing upwards), I figured that a "leaf to root" comparison would be much simpler in terms of the raw amount of computation required. This reduces a complete sub-graph traversal to a simple identity comparison (but requires cooperating `interpolate()` implementations).

I didn't benchmark whether the time spent on naively copying the entire object graph, or doing the "root to leaf" equality comparison amounts to a significant share of computation, or when it starts becoming a problem (is it hundreds or tens of thousands of transitions?). But I do think that the approach is sound.

At this time, I am not inclined to change the implementation, but to improve the code documentation to make it easier to understand what's going on.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1703420442

From quizynox at gmail.com  Mon Aug  5 03:40:46 2024
From: quizynox at gmail.com (quizynox)
Date: Mon, 5 Aug 2024 07:40:46 +0400
Subject: Detecting threading problems faster
In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
Message-ID: <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>

Hello,

Wouldn't it be better to implement this check in assert to avoid any impact
in production?

??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com>:

> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model used by JavaFX.  Basically, anything directly or
> indirectly linked to an active Scene must be accessed on the FX thread.
> However, as FX also allows manipulating nodes and properties before
> they're displayed, there can be no "hard" check everywhere to ensure we
> are on the FX thread (specifically, in properties).
>
> Now, I think this situation is annoying, as a simple mistake where a
> Platform.runLater wrapper was forgotten usually results in programs
> operating mostly flawlessly, but then fail in mysterious and random and
> hard to reproduce ways.  The blame is often put on FX as the resulting
> exceptions will almost never show the user code which was the actual
> culprit.  It can result in FX being perceived as unstable or buggy.
>
> So I've been thinking if there isn't something we can do to detect these
> bugs originating from user code much earlier, similar to the
> `ConcurrentModificationException` the collection classes do when
> accessed in nested or concurrent contexts.
>
> I think it may be possible to have properties check whether they're part
> of an active scene without too much of an performance impact, possibly
> even behind a switch. It would work like this:
>
> Properties involved with Nodes will have an associated bean instance
> (`getBean`).  This is an object, but we could check here if this
> instance implements an interface:
>
>       if (getBean() instanceof MayBePartOfSceneGraph x) {
>             if (x.isPartOfActiveScene() && !isOnFxThread()) {
>                  throw new IllegalStateException("Property must only be
> used from the FX Application Thread");
>             }
>       }
>
> This check could be done on every set of the property, and potentially
> on every get as well.  It should be relatively cheap, but will expose
> problematic code patterns at a much earlier stage.  There's a chance
> that this will "break" some programs that seemed to be behaving
> correctly as well, so we may want to put it behind a switch until such
> programs (or libraries) can be fixed.
>
> What do you all think?
>
> --John
>
> (*) Names of methods/interfaces are only used for illustration purposes,
> we can think of good names if this moves forward.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/a9389d0f/attachment-0001.htm>

From quizynox at gmail.com  Mon Aug  5 04:09:53 2024
From: quizynox at gmail.com (quizynox)
Date: Mon, 5 Aug 2024 08:09:53 +0400
Subject: Font hinting on Linux
In-Reply-To: <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com>
References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>
 <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com>
Message-ID: <CAASO9vSXnKcxpV79J+8iJKafikJenGZUiEL4Fx2wscax=E_q0g@mail.gmail.com>

Hello,

Thanks for the answer. I've found a couple of very long but very
informative threads that have given me some pointers.

Poor quality font rendering
https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html

The crisp fonts saga
https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html

In my case there were two problems:

- I had SceneAntialiasing enabled, which seems to prevent
-fx-smoothing-type=lcd from working
- I forgot that -fx-smoothing-type is only enabled for .text nodes, but not
for all Text nodes by default

I also assumed that Linux fontconfig settings would have some effect on
JavaFX font rendering, but judging from tests this isn't the case. Perhaps
the only thing that matters is freetype compilation flags. I've found that
Fedora enabled ClearType font rendering some time ago (
https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font).

As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation
Sans or Montserrat it may look quite close to acceptable.

??, 4 ???. 2024??. ? 01:41, Philip Race <philip.race at oracle.com>:

> There's not many knobs available. Hinting is not enabled - and that's
> commonly the case on modern plartforms.
> LCD is your best option for readibility of static text, which is why it
> is the default for UI Controls,
> It should reduce the pixel grid fitting uneveness you highlight but
> doesn't eliminate it.
> Note : this presumes that the freetype on your system enables LCD .. if
> it doesn't there's nothing FX can do about that.
>
> -phil.
>
>
> On 8/2/24 10:43 AM, quizynox at gmail.com wrote:
> > Hello,
> >
> > Sorry for asking here, but I seem to have tried everything I could
> > find on SO/Reddit/JBS etc. Could someone please share what font
> > settings I should be using to get decent font hinting on Linux? Please
> > see the screenshot.
> >
> > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view
> >
> > I'm not very picky, but the font I see is just not suitable for
> > presenting app to customers. I've tried enabling and disabling hinting
> > and autohinting, using different hinting styles, changing the font
> > smoothing type and prism.lcdtext etc. Unfortunately no matter what I
> > do, the font hinting is always bad.
> >
> > Fedora, KDE, all latest versions.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/0ce4ad08/attachment.htm>

From kevin.rushforth at oracle.com  Mon Aug  5 14:59:23 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 5 Aug 2024 07:59:23 -0700
Subject: Detecting threading problems faster
In-Reply-To: <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
Message-ID: <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>

> Wouldn't it be better to implement this check in assert to avoid any 
> impact in production?

No. Using an assert in a case like this is an anti-pattern. A call to 
assert in a library such as JavaFX is only appropriate for checking an 
invariant in internal logic. If we are going to go down this route of 
doing a thread check when mutating properties of "live" nodes, we will 
throw the same IllegalStateException that is currently thrown by some 
methods on Stage and Scene.

As for the proposal itself, adding this check is an interesting idea. We 
considered doing this back in the JDK 7 (JavaFX 2) time frame, but 
decided not to pursue it then. I think the idea is worth further 
discussion. I would limit any thread checking to setting the property. 
It would be too restrictive (and largely unnecessary) to prevent reading 
a property from the application thread.

The things to consider would be:

1. What is the performance hit of doing this check on the setting of 
every property?
2. What is the effect on bound properties?
3. How intrusive is it in the code?
4. Should we add a property to enable / disable the thread check, 
possibly a three- or four-valued property (allow|warn|debug?|deny), as 
was recently done in JEP 471 for sun.misc.Unsafe memory access methods. 
If so, what should the default be?

My quick take is that if this can be done in a minimally intrusive 
manner with low overhead, we should consider pursing this. As for 4, my 
preference would be to add a three- or four-valued system property to 
control the check, with "warn" as the default initially, changing the 
default to "disallow" in a subsequent version. This would, of course, 
require a lot of testing.

-- Kevin


On 8/4/2024 8:40 PM, quizynox wrote:
> Hello,
>
> Wouldn't it be better to implement this check in assert to avoid any 
> impact in production?
>
> ??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com>:
>
>     Hi list,
>
>     I know of quite some bugs and users that have been bitten by the
>     threading model used by JavaFX.? Basically, anything directly or
>     indirectly linked to an active Scene must be accessed on the FX
>     thread.
>     However, as FX also allows manipulating nodes and properties before
>     they're displayed, there can be no "hard" check everywhere to
>     ensure we
>     are on the FX thread (specifically, in properties).
>
>     Now, I think this situation is annoying, as a simple mistake where a
>     Platform.runLater wrapper was forgotten usually results in programs
>     operating mostly flawlessly, but then fail in mysterious and
>     random and
>     hard to reproduce ways.? The blame is often put on FX as the
>     resulting
>     exceptions will almost never show the user code which was the actual
>     culprit.? It can result in FX being perceived as unstable or buggy.
>
>     So I've been thinking if there isn't something we can do to detect
>     these
>     bugs originating from user code much earlier, similar to the
>     `ConcurrentModificationException` the collection classes do when
>     accessed in nested or concurrent contexts.
>
>     I think it may be possible to have properties check whether
>     they're part
>     of an active scene without too much of an performance impact,
>     possibly
>     even behind a switch. It would work like this:
>
>     Properties involved with Nodes will have an associated bean instance
>     (`getBean`).? This is an object, but we could check here if this
>     instance implements an interface:
>
>     ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
>     ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) {
>     ???????????????? throw new IllegalStateException("Property must
>     only be
>     used from the FX Application Thread");
>     ??????????? }
>     ????? }
>
>     This check could be done on every set of the property, and
>     potentially
>     on every get as well.? It should be relatively cheap, but will expose
>     problematic code patterns at a much earlier stage.? There's a chance
>     that this will "break" some programs that seemed to be behaving
>     correctly as well, so we may want to put it behind a switch until
>     such
>     programs (or libraries) can be fixed.
>
>     What do you all think?
>
>     --John
>
>     (*) Names of methods/interfaces are only used for illustration
>     purposes,
>     we can think of good names if this moves forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/3edf26bf/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Aug  5 15:01:25 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 5 Aug 2024 15:01:25 +0000
Subject: Detecting threading problems faster
In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
Message-ID: <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>

John:

Can you cite a bug or give an example of such a problem?

During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe.  It is possible that I use the system trivially and not to the full extent.  Both swing and javafx are single threaded by design.  Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Sunday, August 4, 2024 at 16:30
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Detecting threading problems faster
Hi list,

I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX.  Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displayed, there can be no "hard" check everywhere to ensure we
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a
Platform.runLater wrapper was forgotten usually results in programs
operating mostly flawlessly, but then fail in mysterious and random and
hard to reproduce ways.  The blame is often put on FX as the resulting
exceptions will almost never show the user code which was the actual
culprit.  It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these
bugs originating from user code much earlier, similar to the
`ConcurrentModificationException` the collection classes do when
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part
of an active scene without too much of an performance impact, possibly
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance
(`getBean`).  This is an object, but we could check here if this
instance implements an interface:

      if (getBean() instanceof MayBePartOfSceneGraph x) {
            if (x.isPartOfActiveScene() && !isOnFxThread()) {
                 throw new IllegalStateException("Property must only be
used from the FX Application Thread");
            }
      }

This check could be done on every set of the property, and potentially
on every get as well.  It should be relatively cheap, but will expose
problematic code patterns at a much earlier stage.  There's a chance
that this will "break" some programs that seemed to be behaving
correctly as well, so we may want to put it behind a switch until such
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes,
we can think of good names if this moves forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/5baf719c/attachment.htm>

From angorya at openjdk.org  Mon Aug  5 15:05:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 15:05:40 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v6]
In-Reply-To: <xxaZYpOW-P-H0PpamoI71SI3csPzQ3M6xicMdJgwcmo=.a462117e-0104-46cb-92fe-4347e1db32d7@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <xxaZYpOW-P-H0PpamoI71SI3csPzQ3M6xicMdJgwcmo=.a462117e-0104-46cb-92fe-4347e1db32d7@github.com>
Message-ID: <TmpzvfSveu3xJk76Ju2phRhEvNdI_MzQvlbGVWp_YHI=.c57c173f-c3fd-4625-b78f-ff7b0808f7f0@github.com>

On Sat, 3 Aug 2024 16:30:08 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
>> 
>> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
>> 
>> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
>> 
>> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
>> 
>> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added timeout to test due to potential hang when using XWayland

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1473#pullrequestreview-2219233586

From angorya at openjdk.org  Mon Aug  5 15:05:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 15:05:41 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
Message-ID: <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>

On Sat, 3 Aug 2024 14:33:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback: floating point precision in test, ensure unsigned int handling in Robot
>
> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218:
> 
>> 216:     // colors but they might both be working in the wrong space. We use an
>> 217:     // AWT Robot to verify that they are working in sRGB.
>> 218:     @Test
> 
> This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend:
> 
> 
>     @Test(timeout = 15000)

Maybe there is a way to skip the test on Wayland until we find a proper solution?
Asking for completeness sake - simply adding a timeout works too.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704255339

From angorya at openjdk.org  Mon Aug  5 15:05:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 15:05:41 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
Message-ID: <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>

On Mon, 5 Aug 2024 14:59:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 218:
>> 
>>> 216:     // colors but they might both be working in the wrong space. We use an
>>> 217:     // AWT Robot to verify that they are working in sRGB.
>>> 218:     @Test
>> 
>> This test needs a timeout value to avoid hanging the test job on Linux with Wayland. See [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). I recommend:
>> 
>> 
>>     @Test(timeout = 15000)
>
> Maybe there is a way to skip the test on Wayland until we find a proper solution?
> Asking for completeness sake - simply adding a timeout works too.

Q: is this the only test that needs explicit timeout?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704258754

From thiago.sayao at gmail.com  Mon Aug  5 15:17:05 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 5 Aug 2024 12:17:05 -0300
Subject: Detecting threading problems faster
In-Reply-To: <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
Message-ID: <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>

Hi,

Interesting idea. We have this problem specially when Junior developers
touch the code.

The other way around would be nice too - if some I/O task executes on the
FX thread.

This can make the OS think the application hanged and offer to kill it,
since it won't respond to "pings". And I/O tasks processing time may vary
between installations. Also causes "white screens" since it blocks painting.

-- Thiago.

Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth <
kevin.rushforth at oracle.com> escreveu:

> Wouldn't it be better to implement this check in assert to avoid any
> impact in production?
>
>
> No. Using an assert in a case like this is an anti-pattern. A call to
> assert in a library such as JavaFX is only appropriate for checking an
> invariant in internal logic. If we are going to go down this route of doing
> a thread check when mutating properties of "live" nodes, we will throw the
> same IllegalStateException that is currently thrown by some methods on
> Stage and Scene.
>
> As for the proposal itself, adding this check is an interesting idea. We
> considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided
> not to pursue it then. I think the idea is worth further discussion. I
> would limit any thread checking to setting the property. It would be too
> restrictive (and largely unnecessary) to prevent reading a property from
> the application thread.
>
> The things to consider would be:
>
> 1. What is the performance hit of doing this check on the setting of every
> property?
> 2. What is the effect on bound properties?
> 3. How intrusive is it in the code?
> 4. Should we add a property to enable / disable the thread check, possibly
> a three- or four-valued property (allow|warn|debug?|deny), as was recently
> done in JEP 471 for sun.misc.Unsafe memory access methods. If so, what
> should the default be?
>
> My quick take is that if this can be done in a minimally intrusive manner
> with low overhead, we should consider pursing this. As for 4, my preference
> would be to add a three- or four-valued system property to control the
> check, with "warn" as the default initially, changing the default to
> "disallow" in a subsequent version. This would, of course, require a lot of
> testing.
>
> -- Kevin
>
>
> On 8/4/2024 8:40 PM, quizynox wrote:
>
> Hello,
>
> Wouldn't it be better to implement this check in assert to avoid any
> impact in production?
>
> ??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com>:
>
>> Hi list,
>>
>> I know of quite some bugs and users that have been bitten by the
>> threading model used by JavaFX.  Basically, anything directly or
>> indirectly linked to an active Scene must be accessed on the FX thread.
>> However, as FX also allows manipulating nodes and properties before
>> they're displayed, there can be no "hard" check everywhere to ensure we
>> are on the FX thread (specifically, in properties).
>>
>> Now, I think this situation is annoying, as a simple mistake where a
>> Platform.runLater wrapper was forgotten usually results in programs
>> operating mostly flawlessly, but then fail in mysterious and random and
>> hard to reproduce ways.  The blame is often put on FX as the resulting
>> exceptions will almost never show the user code which was the actual
>> culprit.  It can result in FX being perceived as unstable or buggy.
>>
>> So I've been thinking if there isn't something we can do to detect these
>> bugs originating from user code much earlier, similar to the
>> `ConcurrentModificationException` the collection classes do when
>> accessed in nested or concurrent contexts.
>>
>> I think it may be possible to have properties check whether they're part
>> of an active scene without too much of an performance impact, possibly
>> even behind a switch. It would work like this:
>>
>> Properties involved with Nodes will have an associated bean instance
>> (`getBean`).  This is an object, but we could check here if this
>> instance implements an interface:
>>
>>       if (getBean() instanceof MayBePartOfSceneGraph x) {
>>             if (x.isPartOfActiveScene() && !isOnFxThread()) {
>>                  throw new IllegalStateException("Property must only be
>> used from the FX Application Thread");
>>             }
>>       }
>>
>> This check could be done on every set of the property, and potentially
>> on every get as well.  It should be relatively cheap, but will expose
>> problematic code patterns at a much earlier stage.  There's a chance
>> that this will "break" some programs that seemed to be behaving
>> correctly as well, so we may want to put it behind a switch until such
>> programs (or libraries) can be fixed.
>>
>> What do you all think?
>>
>> --John
>>
>> (*) Names of methods/interfaces are only used for illustration purposes,
>> we can think of good names if this moves forward.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/6de3aa2a/attachment-0001.htm>

From martin at martinfox.com  Mon Aug  5 15:32:43 2024
From: martin at martinfox.com (Martin Fox)
Date: Mon, 5 Aug 2024 08:32:43 -0700
Subject: Font hinting on Linux
In-Reply-To: <CAASO9vSXnKcxpV79J+8iJKafikJenGZUiEL4Fx2wscax=E_q0g@mail.gmail.com>
References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>
 <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com>
 <CAASO9vSXnKcxpV79J+8iJKafikJenGZUiEL4Fx2wscax=E_q0g@mail.gmail.com>
Message-ID: <E7C2719C-3B8C-4CCB-9082-6DD8AB08AB33@martinfox.com>

I don?t see how hinting issues can cause this degree of character misplacement. This looks more like, say, a glyph cache bug.

I had no problem reproducing this with the software pipeline. When I force the GPU I get much better results (prism.forceGPU=true). In both cases the text is a little on the fuzzy side but the es2 pipeline is placing the glyphs correctly.

> On Aug 4, 2024, at 9:09?PM, quizynox <quizynox at gmail.com> wrote:
> 
> Hello,
> 
> Thanks for the answer. I've found a couple of very long but very informative threads that have given me some pointers.
> 
> Poor quality font rendering
> https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html
> 
> The crisp fonts saga
> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html
> 
> In my case there were two problems:
> 
> - I had SceneAntialiasing enabled, which seems to prevent -fx-smoothing-type=lcd from working
> - I forgot that -fx-smoothing-type is only enabled for .text nodes, but not for all Text nodes by default
> 
> I also assumed that Linux fontconfig settings would have some effect on JavaFX font rendering, but judging from tests this isn't the case. Perhaps the only thing that matters is freetype compilation flags. I've found that Fedora enabled ClearType font rendering some time ago (https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font).
> 
> As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation Sans or Montserrat it may look quite close to acceptable.
> 
> ??, 4 ???. 2024??. ? 01:41, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>:
>> There's not many knobs available. Hinting is not enabled - and that's 
>> commonly the case on modern plartforms.
>> LCD is your best option for readibility of static text, which is why it 
>> is the default for UI Controls,
>> It should reduce the pixel grid fitting uneveness you highlight but 
>> doesn't eliminate it.
>> Note : this presumes that the freetype on your system enables LCD .. if 
>> it doesn't there's nothing FX can do about that.
>> 
>> -phil.
>> 
>> 
>> On 8/2/24 10:43 AM, quizynox at gmail.com <mailto:quizynox at gmail.com> wrote:
>> > Hello,
>> >
>> > Sorry for asking here, but I seem to have tried everything I could 
>> > find on SO/Reddit/JBS etc. Could someone please share what font 
>> > settings I should be using to get decent font hinting on Linux? Please 
>> > see the screenshot.
>> >
>> > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view
>> >
>> > I'm not very picky, but the font I see is just not suitable for 
>> > presenting app to customers. I've tried enabling and disabling hinting 
>> > and autohinting, using different hinting styles, changing the font 
>> > smoothing type and prism.lcdtext etc. Unfortunately no matter what I 
>> > do, the font hinting is always bad.
>> >
>> > Fedora, KDE, all latest versions.
>> >
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/8922c930/attachment.htm>

From michaelstrau2 at gmail.com  Mon Aug  5 15:35:01 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 5 Aug 2024 17:35:01 +0200
Subject: Detecting threading problems faster
In-Reply-To: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
Message-ID: <CAJEpuXR5=MzbXTGw6qPfgModf_s6NOfED53wowjWD9XgrdTfDw@mail.gmail.com>

Hi John,

this seems to be a very similar idea to what I've proposed a year ago:
https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/041925.html

I think the potential performance impact needs to be carefully considered.

From thiago.sayao at gmail.com  Mon Aug  5 15:36:32 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 5 Aug 2024 12:36:32 -0300
Subject: Detecting threading problems faster
In-Reply-To: <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAAP_wunWkD_pA1drLeuKEodV-7zoE6uH9h4wDTPkR1aGE6U4UQ@mail.gmail.com>

It seems Task<> has thread checks, it would even correct the thread on
updateMessage().

So, it seems to be a problem if Task<> is not used?



Em seg., 5 de ago. de 2024 ?s 12:01, Andy Goryachev <
andy.goryachev at oracle.com> escreveu:

> John:
>
>
>
> Can you cite a bug or give an example of such a problem?
>
>
>
> During all my time of actively using javafx (since about 2015) I have
> never encountered an issue with threading you describe.  It is possible
> that I use the system trivially and not to the full extent.  Both swing and
> javafx are single threaded by design.  Yes, there might be occasions when
> one can use multiple threads and it is sort of allowed, but doing so may
> lead to unpleasant issues down the road, so the question is why would you
> want to do that?
>
>
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Sunday, August 4, 2024 at 16:30
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Detecting threading problems faster
>
> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model used by JavaFX.  Basically, anything directly or
> indirectly linked to an active Scene must be accessed on the FX thread.
> However, as FX also allows manipulating nodes and properties before
> they're displayed, there can be no "hard" check everywhere to ensure we
> are on the FX thread (specifically, in properties).
>
> Now, I think this situation is annoying, as a simple mistake where a
> Platform.runLater wrapper was forgotten usually results in programs
> operating mostly flawlessly, but then fail in mysterious and random and
> hard to reproduce ways.  The blame is often put on FX as the resulting
> exceptions will almost never show the user code which was the actual
> culprit.  It can result in FX being perceived as unstable or buggy.
>
> So I've been thinking if there isn't something we can do to detect these
> bugs originating from user code much earlier, similar to the
> `ConcurrentModificationException` the collection classes do when
> accessed in nested or concurrent contexts.
>
> I think it may be possible to have properties check whether they're part
> of an active scene without too much of an performance impact, possibly
> even behind a switch. It would work like this:
>
> Properties involved with Nodes will have an associated bean instance
> (`getBean`).  This is an object, but we could check here if this
> instance implements an interface:
>
>       if (getBean() instanceof MayBePartOfSceneGraph x) {
>             if (x.isPartOfActiveScene() && !isOnFxThread()) {
>                  throw new IllegalStateException("Property must only be
> used from the FX Application Thread");
>             }
>       }
>
> This check could be done on every set of the property, and potentially
> on every get as well.  It should be relatively cheap, but will expose
> problematic code patterns at a much earlier stage.  There's a chance
> that this will "break" some programs that seemed to be behaving
> correctly as well, so we may want to put it behind a switch until such
> programs (or libraries) can be fixed.
>
> What do you all think?
>
> --John
>
> (*) Names of methods/interfaces are only used for illustration purposes,
> we can think of good names if this moves forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240805/18e3dbdc/attachment-0001.htm>

From mfox at openjdk.org  Mon Aug  5 15:46:36 2024
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 5 Aug 2024 15:46:36 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
Message-ID: <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>

On Mon, 5 Aug 2024 15:02:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Maybe there is a way to skip the test on Wayland until we find a proper solution?
>> Asking for completeness sake - simply adding a timeout works too.
>
> Q: is this the only test that needs explicit timeout?

I don't see any way to query whether we're running under Wayland or not. That would be nice to have.

This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704317349

From mfox at openjdk.org  Mon Aug  5 15:46:37 2024
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 5 Aug 2024 15:46:37 GMT
Subject: Integrated: 8325445: [macOS] Colors are not displayed in sRGB color
 space
In-Reply-To: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
Message-ID: <wGc5rSr4PGUPe0CJUjXrmPLDdi61mEi4QHyePIzrzKk=.d32f2a2c-5118-435b-898b-fe5610717630@github.com>

On Fri, 7 Jun 2024 18:29:00 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty).
> 
> In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB.
> 
> Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results.
> 
> I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases.
> 
> I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut.

This pull request has now been integrated.

Changeset: 19d09e6c
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/19d09e6c2e15683de1c69d0e841f32e337da2031
Stats:     300 lines in 8 files changed: 289 ins; 2 del; 9 mod

8325445: [macOS] Colors are not displayed in sRGB color space

Reviewed-by: angorya, kcr

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

PR: https://git.openjdk.org/jfx/pull/1473

From lkostyra at openjdk.org  Mon Aug  5 16:05:47 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 5 Aug 2024 16:05:47 GMT
Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs
Message-ID: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>

In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.

This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.

Both D3D and ES2 Prism backends were updated to properly handle these changes.

NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.

I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

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

Commit messages:
 - Provide Shader name in ShaderFactory.createShader

Changes: https://git.openjdk.org/jfx/pull/1530/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336624
  Stats: 15 lines in 6 files changed: 5 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1530.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1530/head:pull/1530

PR: https://git.openjdk.org/jfx/pull/1530

From lkostyra at openjdk.org  Mon Aug  5 16:05:47 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 5 Aug 2024 16:05:47 GMT
Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs
In-Reply-To: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
References: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
Message-ID: <3bc6rRtMGIdtvMvgzUDLf5BG47hJeQcWspAwkgmeHjg=.a8d8c1fd-7c99-41a0-b821-740c02e54542@github.com>

On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.
> 
> This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.
> 
> Both D3D and ES2 Prism backends were updated to properly handle these changes.
> 
> NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.
> 
> I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

@arapte Please take a look at this and confirm if those changes will be good for Metal

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

PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2269416642

From kcr at openjdk.org  Mon Aug  5 16:13:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Aug 2024 16:13:40 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
 <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
Message-ID: <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>

On Mon, 5 Aug 2024 15:43:03 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Q: is this the only test that needs explicit timeout?
>
> I don't see any way to query whether we're running under Wayland or not. That would be nice to have.
> 
> This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac.

@alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704352887

From angorya at openjdk.org  Mon Aug  5 16:19:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 16:19:40 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
 <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
 <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>
Message-ID: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com>

On Mon, 5 Aug 2024 16:10:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I don't see any way to query whether we're running under Wayland or not. That would be nice to have.
>> 
>> This is the only test that uses the AWT Robot on Linux. The window background test also uses the AWT Robot but only runs on Mac.
>
> @alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`).

maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first?  what do you think?

edit: never mind, this PR is already integrated.  aren't we supposed to wait 24 hrs before integrating?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704358262

From angorya at openjdk.org  Mon Aug  5 16:25:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 16:25:37 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <1P12hjtrcnoWBrPFdRhiSHXWYOju06wOBrZQqwJv_Ls=.0dfb0f2e-a804-4678-9061-065a66b4bd62@github.com>
Message-ID: <MHvTK3aVzXfa3O_1U-vKXXyu7_azq1wCb3k3o519WIY=.55349113-1797-4b45-8dba-a62633eb22c3@github.com>

On Sat, 3 Aug 2024 00:24:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/CellArrangement.java line 263:
> 
>> 261:      */
>> 262:     private int binarySearch(double localY, int low, int high) {
>> 263:         //System.err.println("    binarySearch off=" + off + ", high=" + high + ", low=" + low); // FIX
> 
> Looks like remnants of the debugging session. Do you still need it?

yes, indeed it is (to be cleaned up later).
I would encourage the reviewers to focus on the public API rather than the implementation at this stage.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1704366454

From kcr at openjdk.org  Mon Aug  5 16:34:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Aug 2024 16:34:40 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
 <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
 <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>
 <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com>
Message-ID: <DLLdJhgGuh5XRr2c61TEb9Eb2pMTTfn30h73j7qqCVs=.c3dcc8f2-2338-428f-ac33-f7b9eaf880c8@github.com>

On Mon, 5 Aug 2024 16:15:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> @alexeysemenyukoracle added an [`isOnWayland`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java#L194) method to `SwingNodeBase.java`. I'll file a new testbug to skip tests that use AWT Robot on Wayland pending the fix for [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468). As part of that, we can move `isOnWayland` to [`Util.java`](https://github.com/openjdk/jfx/blob/jfx23/tests/system/src/test/java/test/util/Util.java) (and fix it to first check `PlatformUtil::isLinux`).
>
> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first?  what do you think?
> 
> edit: never mind, this PR is already integrated.  aren't we supposed to wait 24 hrs before integrating?

I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704375807

From kcr at openjdk.org  Mon Aug  5 17:09:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Aug 2024 17:09:36 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <DLLdJhgGuh5XRr2c61TEb9Eb2pMTTfn30h73j7qqCVs=.c3dcc8f2-2338-428f-ac33-f7b9eaf880c8@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
 <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
 <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>
 <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com>
 <DLLdJhgGuh5XRr2c61TEb9Eb2pMTTfn30h73j7qqCVs=.c3dcc8f2-2338-428f-ac33-f7b9eaf880c8@github.com>
Message-ID: <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com>

On Mon, 5 Aug 2024 16:31:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first?  what do you think?
>> 
>> edit: never mind, this PR is already integrated.  aren't we supposed to wait 24 hrs before integrating?
>
> I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this.

> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think?

Not as part of this PR, no.

> edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating?

That's 24 hours after "rfr".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704408716

From angorya at openjdk.org  Mon Aug  5 17:09:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 5 Aug 2024 17:09:36 GMT
Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space
 [v5]
In-Reply-To: <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com>
References: <n8MrTZ8MJipV1HsBCil3fJjLi57nXPEDnUc7LHsDWA4=.23532120-44b6-48f2-91ef-67afdeca63ea@github.com>
 <aoTV_vuv8LA6zmfIPJF6Fmbium4LYBqDfR7MZYcraLs=.82bf60d2-199e-43e9-9967-a7a8265661c2@github.com>
 <Ltwhc8AfcpgnsNX0eajWdl1DlukrBV7WFrqND9ob9wE=.5f78f7a6-87a0-4508-810e-fc5a104e484c@github.com>
 <NT3bnzJEHMOku4r83scSNBKK-i5rJ70P9DlgtYZK4IQ=.47541d20-fde6-42ed-957a-28e06ff143ef@github.com>
 <FJKogKr7WU3JPRDe3_f6XGLTlyXKOphCaHPRILW4JBo=.b8b78aee-7899-44cb-a925-bbcb8a67490d@github.com>
 <jygI7tq_ZzcxTAXK8pHdZpLy-Hc5IKeNwUmyixgl-jI=.d4d9fe83-aae3-4d09-90da-914b7055dd90@github.com>
 <zq94wn97s1YmC803FxcTYpOVhgNWK3Ww-DcwYHMMLj8=.687f4d4b-3dd3-47f1-9916-c59ba0844e63@github.com>
 <0_8_TWj2oL8f75bsLyToxgLXlVoGhsDJle9Os1V180U=.3c5f4f2e-7e74-418d-ab15-355c7e4f5579@github.com>
 <DLLdJhgGuh5XRr2c61TEb9Eb2pMTTfn30h73j7qqCVs=.c3dcc8f2-2338-428f-ac33-f7b9eaf880c8@github.com>
 <_8JOo4dxr1WdFWmFyUMWhB_Z45JRfkJn2aD6vIWsaZ4=.fe72d96b-04ee-4d26-adce-88afd7f45457@github.com>
Message-ID: <vKC-9JAFKumYoXKsDzSU007YQ704CttjhQGyztuP12g=.3e564ba1-6bd4-4348-b265-3c7644c25f04@github.com>

On Mon, 5 Aug 2024 17:04:33 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I filed https://bugs.openjdk.org/browse/JDK-8337827 to track this.
>
>> maybe we ought to fast track an isolated addition of `isOnWayland()` and integrate that first? what do you think?
> 
> Not as part of this PR, no.
> 
>> edit: never mind, this PR is already integrated. aren't we supposed to wait 24 hrs before integrating?
> 
> That's 24 hours after "rfr".

it's all good then.  thanks for filing [JDK-8337827](https://bugs.openjdk.org/browse/JDK-8337827)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1473#discussion_r1704410859

From arapte at openjdk.org  Tue Aug  6 05:18:41 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 6 Aug 2024 05:18:41 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
Message-ID: <Hgc7nsnZWBTjwtZOUQiIaRHb-wSIkHzYs16NbWWCeLw=.29fc1c82-42e7-496f-9ca4-cfb06a6dc839@github.com>

On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation of the protocol.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested.

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1507#pullrequestreview-2220296759

From hmeda at openjdk.org  Tue Aug  6 08:08:09 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 6 Aug 2024 08:08:09 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
Message-ID: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>

> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Remove deprecated file

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1527/files
  - new: https://git.openjdk.org/jfx/pull/1527/files/92dd8395..650d1d20

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1527&range=00-01

  Stats: 190 lines in 1 file changed: 0 ins; 190 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1527.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1527/head:pull/1527

PR: https://git.openjdk.org/jfx/pull/1527

From arapte at openjdk.org  Tue Aug  6 08:36:38 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 6 Aug 2024 08:36:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <N-i7t5nxmuuC8C46jpphpuR0Apmcf6m_Stc7aoT-hFc=.efbd735f-f51d-4e72-b793-a3673f846bfc@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2220641216

From duke at openjdk.org  Tue Aug  6 09:16:38 2024
From: duke at openjdk.org (Clearvision92)
Date: Tue, 6 Aug 2024 09:16:38 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <GqFlLc5mduncW4X4OP6TJYBtzyylV3aPJa-eHFKMeHA=.0e1d1ef2-5b4a-4082-9b2b-274fdb8949d8@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

Help me download

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

PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2220748425

From kcr at openjdk.org  Tue Aug  6 12:13:42 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Aug 2024 12:13:42 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <D2KRWmtARKnlMNhJ7PWNg_ei7_yEzi91YuLTf0ydtII=.1f435b7d-663c-42bc-94bd-01ac7b88d785@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2221123181

From lkostyra at openjdk.org  Tue Aug  6 12:55:43 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 6 Aug 2024 12:55:43 GMT
Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening
 another stage [v5]
In-Reply-To: <hR4Ln92HtY1mnO82wcOcCRmtYoFxfRJ1ri6M1Ia0bAI=.156f4e86-cdd4-4c77-aa44-97dcdeab931f@github.com>
References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com>
 <hR4Ln92HtY1mnO82wcOcCRmtYoFxfRJ1ri6M1Ia0bAI=.156f4e86-cdd4-4c77-aa44-97dcdeab931f@github.com>
Message-ID: <6ykhx2Ylax-_y78REsCQby8emph_X3Oe6SroyWCXutc=.886defbc-0d80-4c83-9e19-b985afc13b72@github.com>

On Mon, 29 Jul 2024 14:29:17 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified).
>> 
>> It's not specific to DEBIAN, it depends on the window manager (kwin is affected).
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert idea file
>  - Fix only the original bug

LGTM. I confirmed it works on latest Ubuntu 23.04 with KDE Plasma. Gnome behavior is unchanged (correct and KDE matches Gnome behavior).

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1460#pullrequestreview-2221218851

From tsayao at openjdk.org  Tue Aug  6 13:05:40 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 Aug 2024 13:05:40 GMT
Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening
 another stage [v5]
In-Reply-To: <hR4Ln92HtY1mnO82wcOcCRmtYoFxfRJ1ri6M1Ia0bAI=.156f4e86-cdd4-4c77-aa44-97dcdeab931f@github.com>
References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com>
 <hR4Ln92HtY1mnO82wcOcCRmtYoFxfRJ1ri6M1Ia0bAI=.156f4e86-cdd4-4c77-aa44-97dcdeab931f@github.com>
Message-ID: <OjH1vC3Mo4kOROSuzqyCSFYcK-j4GqBGzV2cFUCYpos=.1df09835-7b4f-4a63-8b32-6b187f7f834c@github.com>

On Mon, 29 Jul 2024 14:29:17 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified).
>> 
>> It's not specific to DEBIAN, it depends on the window manager (kwin is affected).
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert idea file
>  - Fix only the original bug

Is it ok to integrate? I got the e-mail saying so, but not really sure.

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

PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2271241922

From kcr at openjdk.org  Tue Aug  6 13:08:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Aug 2024 13:08:41 GMT
Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening
 another stage [v5]
In-Reply-To: <OjH1vC3Mo4kOROSuzqyCSFYcK-j4GqBGzV2cFUCYpos=.1df09835-7b4f-4a63-8b32-6b187f7f834c@github.com>
References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com>
 <hR4Ln92HtY1mnO82wcOcCRmtYoFxfRJ1ri6M1Ia0bAI=.156f4e86-cdd4-4c77-aa44-97dcdeab931f@github.com>
 <OjH1vC3Mo4kOROSuzqyCSFYcK-j4GqBGzV2cFUCYpos=.1df09835-7b4f-4a63-8b32-6b187f7f834c@github.com>
Message-ID: <mAaDZbc5UXvTpeW11xSMJ8rwuYDASmCFvoJkhrWjt5I=.b4d3b42a-4125-48ad-a8ac-065a7040b084@github.com>

On Tue, 6 Aug 2024 13:03:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Is it ok to integrate? I got the e-mail saying so, but not really sure.

Yes. There are two approving reviews, and no outstanding comments or questions.

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

PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2271248232

From tsayao at openjdk.org  Tue Aug  6 13:11:40 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 6 Aug 2024 13:11:40 GMT
Subject: Integrated: 8332222: Linux Debian: Maximized stage shrinks when
 opening another stage
In-Reply-To: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com>
References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com>
Message-ID: <hAjwehpYFJEqpyXziFw-4flZ87gG8DzXQMxY-hr8T2I=.222a649c-01ff-42de-8195-0dae52db7a14@github.com>

On Wed, 22 May 2024 21:28:47 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified).
> 
> It's not specific to DEBIAN, it depends on the window manager (kwin is affected).

This pull request has now been integrated.

Changeset: 304704da
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/304704da06365b9878b1b556c5dc35fb618ae584
Stats:     23 lines in 1 file changed: 15 ins; 8 del; 0 mod

8332222: Linux Debian: Maximized stage shrinks when opening another stage

Reviewed-by: jpereda, lkostyra

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

PR: https://git.openjdk.org/jfx/pull/1460

From aghaisas at openjdk.org  Tue Aug  6 14:05:40 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 6 Aug 2024 14:05:40 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <ZR8RixR5hnWDdbcjY1Ny8u9Iv9tVTChAIMg8XLcPCvA=.faaa419b-7dce-46f2-a9d2-5cafa6b513bf@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 451:

> 449:       <li><a href="#incubator-modules">Incubator Modules</a>
> 450:         <ul>
> 451:           <li>jfx.incubator.scene.control.rich

module name typo : rich -> richtext

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 454:

> 452:             <ul>
> 453:               <li><a href="#codearea">CodeArea</a></li>
> 454:               <li><a href="#richtextarea">RichTextArea</a></li>

The order of these 2 items should be reversed to match order present in the description.

modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 6391:

> 6389:       <tbody>
> 6390:         <tr>
> 6391:           <td>jfx.incubator.scene.control.rich</td>

module name typo : rich -> richtext

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705394006
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705396243
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705394317

From angorya at openjdk.org  Tue Aug  6 14:28:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 14:28:42 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <ZR8RixR5hnWDdbcjY1Ny8u9Iv9tVTChAIMg8XLcPCvA=.faaa419b-7dce-46f2-a9d2-5cafa6b513bf@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <ZR8RixR5hnWDdbcjY1Ny8u9Iv9tVTChAIMg8XLcPCvA=.faaa419b-7dce-46f2-a9d2-5cafa6b513bf@github.com>
Message-ID: <qu7b7gjKmvrW1SeKhcK8-S8EOctGJDhwV4IFQEIMorw=.0081ca64-6f49-4526-973a-817f825d0b33@github.com>

On Tue, 6 Aug 2024 11:47:23 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 454:
> 
>> 452:             <ul>
>> 453:               <li><a href="#codearea">CodeArea</a></li>
>> 454:               <li><a href="#richtextarea">RichTextArea</a></li>
> 
> The order of these 2 items should be reversed to match order present in the description.

I think the general convention is to list the classes in alphabetical order.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1705639393

From angorya at openjdk.org  Tue Aug  6 15:05:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 15:05:38 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
Message-ID: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com>

On Thu, 1 Aug 2024 22:41:05 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Initial implementation of the protocol.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested.

I don't see crashes, but I noticed a few things when testing with the Monkey Tester:

1. on the AreaChart page, I was unable to see the a11y focus rectangle around the elements of the chart, even though I can hear what sounded like announcements for various elements on the chart.  This behavior differed from e.g. BarChart where I could navigate with a11y focus using the TAB key.  What's more interesting, this behavior appears to be the same regardless of the 'focus traversable' enabled property
2. On the BarChart (and on other chart pages) I could not place a11y focus on any of the chart  elements using the mouse; but the TAB key worked.  Why is that?
3. HtmlEditor: the focus rectangle is fixed at the small area in the top left corner, regardless of the text entered (see the screenshot)

![Screenshot 2024-08-06 at 07 44 42](https://github.com/user-attachments/assets/b2ed255a-f13a-4f6e-89ee-113cd75cbd51)

4. In the WebView page, enter the https://github.com address and press enter.  I see the following output in stderr (which is absent with VoiceOver off):

Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applicatio
 n Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX
  Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thr
 ead "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Excep
 tion in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" state:SCHEDULED
state:RUNNING

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

PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271514079

From kcr at openjdk.org  Tue Aug  6 15:44:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Aug 2024 15:44:37 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
 <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com>
Message-ID: <aiXugd1DUEfTkgwzssjo5SNjXR8wxAPKJOGUU2B4iEU=.84f5e670-b0b6-4729-8a2b-0bcdea091fb8@github.com>

On Tue, 6 Aug 2024 15:02:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing methods that supposed to generate attributed strings. String attributes are not available for the static text elements and cause exceptions to be thrown when requested.
>
> I don't see crashes, but I noticed a few things when testing with the Monkey Tester:
> 
> 1. on the AreaChart page, I was unable to see the a11y focus rectangle around the elements of the chart, even though I can hear what sounded like announcements for various elements on the chart.  This behavior differed from e.g. BarChart where I could navigate with a11y focus using the TAB key.  What's more interesting, this behavior appears to be the same regardless of the 'focus traversable' enabled property
> 2. On the BarChart (and on other chart pages) I could not place a11y focus on any of the chart  elements using the mouse; but the TAB key worked.  Why is that?
> 3. HtmlEditor: the focus rectangle is fixed at the small area in the top left corner, regardless of the text entered (see the screenshot)
> 
> ![Screenshot 2024-08-06 at 07 44 42](https://github.com/user-attachments/assets/b2ed255a-f13a-4f6e-89ee-113cd75cbd51)
> 
> 4. In the WebView page, enter the https://github.com address and press enter.  I see the following output in stderr (which is absent with VoiceOver off):
> 
> Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applicat
 ion Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Application Thread" Exception in thread "JavaFX Applica...

@andy-goryachev-oracle  Can you run the same tests with mainline (i.e., without the fix from this PR)? Those problems that only occur with this patch should be addressed as part of this PR. Problems that occur both with and without this patch should be tracked separately.

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

PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271597988

From angorya at openjdk.org  Tue Aug  6 17:19:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 17:19:36 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <aiXugd1DUEfTkgwzssjo5SNjXR8wxAPKJOGUU2B4iEU=.84f5e670-b0b6-4729-8a2b-0bcdea091fb8@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
 <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com>
 <aiXugd1DUEfTkgwzssjo5SNjXR8wxAPKJOGUU2B4iEU=.84f5e670-b0b6-4729-8a2b-0bcdea091fb8@github.com>
Message-ID: <bE40Pyuzo0RS4cfB-xcU2HtpBDc0FgMsSTLWUEOADnU=.3eb99a7d-398c-49d9-bd06-95bd2160d073@github.com>

On Tue, 6 Aug 2024 15:41:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Can you run the same tests with mainline

Items 1-3 can be seen with mainline, so these might be (new) issues.

Item 4 seems to have been introduced by this PR - don't see the issue with the master branch.  Also, notice that we don't get a stack trace but a bunch of concatenated messages.

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

PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2271771014

From angorya at openjdk.org  Tue Aug  6 17:26:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 17:26:36 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <2e-mbpiyZ2dmyifwGUHVXg-jPVc9VdfVoMOyGkmEyzU=.a940a439-77df-415f-ba23-26825e7dbbcf@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

not yet a review.
noticed an issue on macOS.  to reproduce, open a clip from the ticket, hit "play" and then drag the position slider someplace else.
in the master branch, I see these in stderr:

2024-08-06 10:19:04.010 java[52568:1934744] CMTimeMakeWithSeconds(159.122 seconds, timescale 1): warning: error of -0.122 introduced due to very low timescale
2024-08-06 10:19:09.380 java[52568:1934744] CMTimeMakeWithSeconds(287.769 seconds, timescale 1): warning: error of -0.769 introduced due to very low timescale


with this change, I see an exception in com.sun.media.jfxmediaimpl.NativeMediaPlayer:1530 because VideoResolution is being constructed with width=0 and height=0

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271782737

From angorya at openjdk.org  Tue Aug  6 17:42:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 17:42:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <b554awiATUo8A-IDU-47r-WzyZJ2QnGi9f_tab2nXc0=.6e26cf6c-3aeb-408b-ad2b-9cba629a0c90@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

on my windows 11, I hear the audio but see no video (with this PR).  am I missing any codecs?

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271806495

From kcr at openjdk.org  Tue Aug  6 17:42:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Aug 2024 17:42:39 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <gYRHipzHIB1s3Ddzep7pKM_vOrApExTezocnCMdyXkI=.a1470c0a-e218-4b5b-879d-fc16131ae539@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

Anything seen on macOS is unrelated to this PR. This PR only modifies Windows-specific platform code.

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271807845

From kcr at openjdk.org  Tue Aug  6 17:42:39 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Aug 2024 17:42:39 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <b554awiATUo8A-IDU-47r-WzyZJ2QnGi9f_tab2nXc0=.6e26cf6c-3aeb-408b-ad2b-9cba629a0c90@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
 <b554awiATUo8A-IDU-47r-WzyZJ2QnGi9f_tab2nXc0=.6e26cf6c-3aeb-408b-ad2b-9cba629a0c90@github.com>
Message-ID: <E_pA72QFNstaEX9ZvwAIdUTz85CfgJ08UXr_YN6dYFc=.7a4091cb-a138-4508-9c55-aea80ddc38cf@github.com>

On Tue, 6 Aug 2024 17:37:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> on my windows 11, I hear the audio but see no video (with this PR). am I missing any codecs?

It should show the video as well. The expected behavior is that the video is shown with incorrect colors without this fix and shown with correct colors with the fix. I wouldn't expect any specific codec needed, but @sashamatveev can confirm.

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271811937

From angorya at openjdk.org  Tue Aug  6 18:39:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 18:39:37 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <YN_sykybUW9op0FBjnYlEP7shgVVU5Qu-8EwpFWuzGY=.69a87535-35d7-4743-8823-b412415fe9fc@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <gDpZcDR7doJT2LbhlmzqpyhEuJdM4mHwVT2nkkDtxbg=.fec9000a-a6b1-4a31-9b37-daac1c8b6e2d@github.com>
 <SoTgIRRZyYapmiyG5fNOCgXDMFMLK5xsVnbqflpt66M=.ccb262d2-e60f-4ee0-8d88-0b53fa9fb29f@github.com>
 <md7GpViTs0wM3YSfpto_OUHWon-qMrmkdRo4kgxIVQE=.8b4304ba-e2a9-41d4-9381-6017a4f3a056@github.com>
 <5Vtbo2utJHinPg43AcIgKx5S9uMa5uEbH1HOenBKhYQ=.b271d85b-fda9-421a-8d8f-076ffc2ceddc@github.com>
 <YN_sykybUW9op0FBjnYlEP7shgVVU5Qu-8EwpFWuzGY=.69a87535-35d7-4743-8823-b412415fe9fc@github.com>
Message-ID: <WJyZ1KXBAQsN2FaOrc6bkToj7XTTW1Ucy2OosRa3Ip4=.8cd35f3c-dc0c-441d-bfdf-a22042a3ed58@github.com>

On Sun, 4 Aug 2024 22:51:33 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I don't understand this argument at all. Why would it be reasonable to _only_ build a more efficient architecture _if_ there's such a huge problem with the "naive" alternative that this alone would be readily apparent? If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance.
>> 
>> Here's the thing: this code could reasonably be executed tens of thousands of times per second. Think of a complex user interface that changes its visual state for many nodes at once. What you seem to perceive as a micro-optimization is actually a part of an architecture that involves many types in the `Background` and `Border` area.
>> 
>> The basic idea is: if I can rely on `interpolate()` returning existing instances (either the start value or the end value) if nothing has changed, then the "parent object's" interpolate method can use an identity comparison (which is basically for free) to choose whether to return itself (or the end value), or return a new instance.
>> 
>> Let's look at the `Border.interpolate()` implementation:
>> 
>> @Override
>> public Border interpolate(Border endValue, double t) {
>>     Objects.requireNonNull(endValue, "endValue cannot be null");
>>     if (t <= 0) return this;
>>     if (t >= 1) return endValue;
>> 
>>     // interpolateListsPairwise() is implemented such that it returns existing list instances
>>     // (i.e. the 'this.images' or 'endValue.images' arguments) as an indication that the result
>>     // is shallow-equal to either of the input arguments. This allows us to very quickly detect
>>     // if we can return 'this' or 'endValue' without allocating a new Border instance.
>>     List<BorderImage> newImages = images == endValue.images ?
>>         images : InterpolationUtils.interpolateListsPairwise(images, endValue.images, t);
>> 
>>     List<BorderStroke> newStrokes = strokes == endValue.strokes ?
>>         strokes : InterpolationUtils.interpolateListsPairwise(strokes, endValue.strokes, t);
>> 
>>     if (images == newImages && strokes == newStrokes) {
>>         return this;
>>     }
>> 
>>     if (endValue.images == newImages && endValue.strokes == newStrokes) {
>>         return endValue;
>>     }
>> 
>>     return new Border(newStrokes, newImages);
>> }
>> 
>> 
>> `interpolateListsPairwise()` _already knows_ whether both lists are equal, which makes the `return this` and `return endValue` branches after the interp...
>
> I think you said that you didn't actually test this, so we don't know if this will perform better. It's based on an assumption of what Java will do, and on assumptions what is "bad" and what is "good".  Without having tested this, you are optimizing blind.  I would be entirely satisfied if you had said "I tested this with a few thousand transitions, the allocation turned out to be a hot spot, so I optimized it which is the reason this code looks a bit out of the ordinary".
> 
> I also would have liked a comment explaining any pitfalls introduced by the optimization; the use of `==` by callers is unusual, and a crucial piece of information when I see code like:
> 
>         if (secondList.isEmpty()) {
>             return firstList.isEmpty() ? firstList : secondList;
>         }
> 
> It would deserve at least an explanation that you're specifically returning one of the passed in arguments so callers can do reference equality checks.
> 
> Java's JIT is very finicky.  For example, an earlier comment asked if the first `if` case is the most common one.  The assumption being that this will improve performance.  However, you can't make that assumption at all (I've done tests that show it's almost impossible to predict which "if order" will be faster on the JVM); re-arranging a function or "unrolling" it can have large negative consequences if that means the JIT will no longer inline your function.
> 
> Now, I will give you that this **probably** will be faster, but I'm making an assumption here... I really can't be sure.  That still leaves some explanatory comments that I think you should add with the assumptions that were made for this optimization.
> 
>>  If taken to the extreme, this line of thinking leads to death by a thousand papercuts, no single issue big enough that it's a problem all by itself, but taken together it amounts to sluggish performance.
> 
> No, when hunting for performance problems, it will be readily apparent what total process is taking up all the time, and how often parts of it are being called and how much time they take in total.  Put a profiler on it, and see where the actual time is being spent on a case with a lot of transitions if you want to optimize it.  Even the JVM itself does this, not bothering to even compile code that isn't executed at least a certain amount of times, or not bothering to further optimize code after compilation if that code isn't in a hot path.
> 
> What optimization generally does is it that it makes code harder to understand (almost unavoid...

I think what is being done in this PR is fine, even though your arguments @hjohn are perfectly valid.  One feature that I think has value is the fact that this design tries to limit new allocations, and I think it's a good thing.

One interesting point you bring up is that we have no good performance test for CSS.  What would represent a good performance test?  Create a thousand of labels and measure the time it takes to update?  Does it matter if it's a label or something else?  And do we have a reliable way to measure?  What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1705961254

From angorya at openjdk.org  Tue Aug  6 18:39:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 18:39:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
Message-ID: <Gaj62MUiD6dxoRnk74-qY2LpXBN3nKQUrGavTKOe9Tc=.4773593e-7462-4eca-9cd6-c21431b66817@github.com>

On Fri, 2 Aug 2024 21:24:21 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix since tag
>>  - adjust table styling
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line 311:
> 
>> 309:                 }
>> 310:             }
>> 311:         }
> 
> You could write this without nesting using `switch`:
> 
> 
> switch(listSize) {
> case 8: newArray[7] = item7;  // fallthrough
> case 7: newArray[6] = item6;
> case 6: newArray[5] = item5;  
> // etc
> }

+1

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1705962174

From angorya at openjdk.org  Tue Aug  6 19:17:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 19:17:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v16]
In-Reply-To: <hIuKwyZ2oHRW_KtTbX0DopvXz5_Ywn_tDWIPD40zf5w=.e0d8e9bf-a0c2-46e5-915c-9a0ea3200c65@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <hIuKwyZ2oHRW_KtTbX0DopvXz5_Ywn_tDWIPD40zf5w=.e0d8e9bf-a0c2-46e5-915c-9a0ea3200c65@github.com>
Message-ID: <iHAQih9O80vvGjULUbbiM_5RItGALLVUn_K4Af0_6jQ=.e16e124d-bf35-4a03-81cb-2e75235cfd18@github.com>

On Sun, 4 Aug 2024 19:08:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use HashMap.newHashMap()

The code does not build in Eclipse.  Could you please replace modules/graphics/.classpath with this:


<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" path="src/main/java"/>
	<classpathentry kind="src" path="build/gensrc/jsl-prism"/>
	<classpathentry kind="src" path="build/gensrc/jsl-decora"/>
	<classpathentry kind="src" path="build/hlsl/Decora"/>
	<classpathentry kind="src" path="build/hlsl/Prism"/>
	<classpathentry kind="src" output="testbin" path="src/shims/java">
		<attributes>
			<attribute name="test" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="testbin" path="src/test/java">
		<attributes>
			<attribute name="test" value="true"/>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" path="src/main/resources">
		<attributes>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="testbin" path="src/test/resources">
		<attributes>
			<attribute name="test" value="true"/>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/base">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="javafx.base/com.sun.javafx.property=javafx.graphics:javafx.base/test.javafx.collections=javafx.graphics:javafx.base/test.util.memory=javafx.graphics:javafx.base/test.util=javafx.graphics"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/5">
		<attributes>
			<attribute name="test" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="java.base/sun.security.util=javafx.graphics"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="output" path="bin"/>
</classpath>


(that simply adds a missing dependency `:javafx.base/test.util=javafx.graphics` )

And also merge the latest master in please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2271972593

From angorya at openjdk.org  Tue Aug  6 19:26:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 19:26:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <SWb3n8zTRSuRnu2SbQdehmYIfZpwmLraFXCCibeDHgw=.1bbc59f5-52a4-418f-9809-02dfd0405f6a@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

rebuilt the code with `rm -rf ./build; /bin/sh gradlew -PCOMPILE_MEDIA=true -PBUILD_TOOLS_DOWNLOAD_SCRIPT=../build-tools.gradle clean sdk apps javadoc` command.

Still see no video (but I can hear audio).  What gives?

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

PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271988770

From angorya at openjdk.org  Tue Aug  6 19:35:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 19:35:38 GMT
Subject: RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <8lGkSwC0O10F4b8u330sNfWuz-oatuBqMOXog8V9Id4=.bbb3e2f9-7b52-4adb-9644-1358c9c7f17e@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

the code changes look ok to me.  can't test bc codec, but two other people have tested.

Apparently, one needs to pay Microsoft $0.99 for HEVC codecs
https://apps.microsoft.com/detail/9nmzlz57r3t7?hl=en-US&gl=US

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1525#pullrequestreview-2222087199
PR Comment: https://git.openjdk.org/jfx/pull/1525#issuecomment-2271999812

From mstrauss at openjdk.org  Tue Aug  6 20:04:21 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 Aug 2024 20:04:21 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v17]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <N1QCgAUSUYzxgVvoSqloPOpo-rPPUQFwm_Rvlcl_Vu4=.53867629-e45b-4a8a-8ba8-d9c63fe68295@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

Michael Strau? has updated the pull request 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. The pull request contains 38 additional commits since the last revision:

 - Merge branch 'refs/heads/master' into feature/interpolatable
 - add export
 - use HashMap.newHashMap()
 - add test for stop lists
 - add tests
 - remove ComponentTransitionable
 - move tests
 - added comments
 - move interpolation helpers to separate file
 - fix trailing whitespace
 - ... and 28 more: https://git.openjdk.org/jfx/compare/1c065481...eb9700a8

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/d7f21872..eb9700a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=15-16

  Stats: 352910 lines in 7432 files changed: 186542 ins; 107958 del; 58410 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From almatvee at openjdk.org  Tue Aug  6 20:46:49 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 Aug 2024 20:46:49 GMT
Subject: Integrated: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
In-Reply-To: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
References: <6ao-JqF8agzXd9BF18q3uNRrq383ls0n8W7WQukHkgk=.bf33fc79-ac02-405f-b422-1b90f3111ec1@github.com>
Message-ID: <6Z-4pKojjTAG52B3fhzW7fNCzq0MZi81JQCN4gZUpJQ=.4e9163f5-ac7d-483e-985a-6a6790f5f28b@github.com>

On Wed, 31 Jul 2024 03:45:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - For some reason H.265 decoder on Windows accepts proposed media format without error, but does not actually change output format.
> - For 8-bit we proposed IYUV, but decoder outputs NV12. For 10-bit we proposed NV12, but decoder outputs P010. As result colors where not correct during rendering.
> - To detect such condition we will propose media format and then read it back to determine actual decoder output format.
> - Added color conversion for P010 format, which was missing. P010 conversion is done in two stages (P010->NV12->IYUV), since color converter does not support direct conversion from P010 to IYUV.
> - Note: Color conversion from P010->NV12->IYUV and NV12->IYUV is temporary solution and will be disabled/removed once JDK-8337686 is implemented. JDK-8337686 will add native support for P010 and NV12 to Graphics.
> - Added debug trace for formats. Disabled by default.

This pull request has now been integrated.

Changeset: 635a09c7
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/635a09c7855351eac8001b60e240c826db3a6bff
Stats:     628 lines in 2 files changed: 467 ins; 61 del; 100 mod

8336277: Colors are incorrect when playing H.265/HEVC on Windows 11

Reviewed-by: kcr, arapte, angorya

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

PR: https://git.openjdk.org/jfx/pull/1525

From almatvee at openjdk.org  Tue Aug  6 20:56:52 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 Aug 2024 20:56:52 GMT
Subject: [jfx23u] RFR: 8336277: Colors are incorrect when playing H.265/HEVC on
 Windows 11
Message-ID: <UhKvsGC9ATlzI_ZBDem0QvfGSrHuv42FZlFwhQhRnhA=.18c6f129-6eee-4cde-a4a4-d8085cfcd1cf@github.com>

- Clean backport of JDK-8336277.

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

Commit messages:
 - Backport 635a09c7855351eac8001b60e240c826db3a6bff

Changes: https://git.openjdk.org/jfx23u/pull/7/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=7&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336277
  Stats: 628 lines in 2 files changed: 467 ins; 61 del; 100 mod
  Patch: https://git.openjdk.org/jfx23u/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/7/head:pull/7

PR: https://git.openjdk.org/jfx23u/pull/7

From almatvee at openjdk.org  Tue Aug  6 22:10:37 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 Aug 2024 22:10:37 GMT
Subject: [jfx23u] Integrated: 8336277: Colors are incorrect when playing
 H.265/HEVC on Windows 11
In-Reply-To: <UhKvsGC9ATlzI_ZBDem0QvfGSrHuv42FZlFwhQhRnhA=.18c6f129-6eee-4cde-a4a4-d8085cfcd1cf@github.com>
References: <UhKvsGC9ATlzI_ZBDem0QvfGSrHuv42FZlFwhQhRnhA=.18c6f129-6eee-4cde-a4a4-d8085cfcd1cf@github.com>
Message-ID: <FzWXYlb15erSTE_krS_2I5FU0uvU_wxZe7cGaMJU1_0=.e0bd00e7-1357-44f7-b5e2-ac078c28d2ce@github.com>

On Tue, 6 Aug 2024 20:52:26 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Clean backport of JDK-8336277.

This pull request has now been integrated.

Changeset: d0c5cd42
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/d0c5cd42d46be7773e5872dca0ceb442354755dd
Stats:     628 lines in 2 files changed: 467 ins; 61 del; 100 mod

8336277: Colors are incorrect when playing H.265/HEVC on Windows 11

Backport-of: 635a09c7855351eac8001b60e240c826db3a6bff

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

PR: https://git.openjdk.org/jfx23u/pull/7

From angorya at openjdk.org  Tue Aug  6 22:46:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Aug 2024 22:46:43 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v4]
In-Reply-To: <vjTuzZX-CeoCwH4qtObvlQzh4DrUXdRbwBcE6fJl-6o=.48122c41-9313-4e66-b3ee-88a75be8265a@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <Y8slBnOWK3BbOpZyJcofAeCrj7o5jsvR3GIK8IYZoO0=.e4dbc28a-ae48-4f72-8e17-d691c7b01ba1@github.com>
 <MxNh0K_YQ4Ye76MYk1ZgP_qkX7HyyH9rdrS365y6rvk=.a031afde-ae91-4f3f-b7cb-98ec3278345c@github.com>
 <fJDMxLrNNEc_6weB12baAraoyxQ1ZNCuYa8Afjn-bwE=.0b0f8822-a5bf-49a0-a4da-04e913cae3aa@github.com>
 <Q6UPOvGyoGWe_YoN1mRnwC5QoS8yFXwqtHbz9JZa3iQ=.dd2c2f9c-94d6-4439-8c89-6b787faa220f@github.com>
 <vjTuzZX-CeoCwH4qtObvlQzh4DrUXdRbwBcE6fJl-6o=.48122c41-9313-4e66-b3ee-88a75be8265a@github.com>
Message-ID: <TEZPxCWPJpcM2XYj99FFAnTLHg3hTScKsRreqpO-nIY=.9e22807d-4023-49db-a52b-d75af19d7fe3@github.com>

On Tue, 9 Jul 2024 17:58:30 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> it looks to me readBinary should be static, and writeBinary an instance method - this is a normal pattern.  the asymmetry is dictated by the fact that we don't have an instance when reading, so typically read() methods read the stream and create an instance at the last moment with the specific constructor.  unless, of course, the design allows for mutation and the fields can be set().
>> 
>> Alternatively, readBinary() could be moved to another class (helper? reader?) to avoid making this an API change.
>> 
>> what do you think?
>
> I can see if I can externalize this or if that would run into issues.  Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API.
> 
> In other words, this could wait and be done separately or never.

what is the resolution, @hjohn ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1706186666

From mstrauss at openjdk.org  Tue Aug  6 23:47:13 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 Aug 2024 23:47:13 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  replace StyleConverter.SupportsDeconstruction interface with annotation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/eb9700a8..61d595fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=16-17

  Stats: 23 lines in 4 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Tue Aug  6 23:49:40 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 6 Aug 2024 23:49:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v3]
In-Reply-To: <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <aRF0sliUszemKo8cUEtBpP1tTbcoXD6VPfrWS5qSDiM=.5eb70255-0092-461b-bce6-2cef3f28e2a2@github.com>
 <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com>
 <ZaV6aqs4_G0sasvDbBPAiwW0f8lM7xCJvYBkhxLhcSU=.250b714f-4425-4bde-aa85-f45e01f0b2db@github.com>
 <rWEjZRdb-72ZlRhWG-HFEaZZN5r9faeHfqP7t5Hy6dQ=.b3784680-d1d3-489a-bdaa-f25d63e4acba@github.com>
 <iukcqTCybe6aduw57wDFI3Zq0wHYLyHpg78oK_nh3ro=.46fe19ac-84bf-4d0f-91eb-7fb6cbdc4ef1@github.com>
 <FpaKubL3RneMHcv5J7_eEywtF0lbxsmeqrU1DyYib84=.99ac8830-7370-47cd-9df0-1c6c4f406e2d@github.com>
 <0vyp4GYEi2g96MOznMJFipCmWUqF6xGccSY-vXrt-BQ=.ad55b0fe-0226-4683-b045-f4e69333725a@github.com>
Message-ID: <t51tSkk0dmcPO9qzGQneglQln_TJDC0yUaq3h5rkYVo=.bcb54381-5a66-471e-8920-46f28b34c28c@github.com>

On Sun, 4 Aug 2024 22:55:22 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I don't quite like returning any particular value from `convertBack` as a signal for "this style converter doesn't support deconstruction", so I've made it more explicit with the marker interface `StyleConverter.SupportsDeconstruction`. This removes the marker interface `ComponentTransitionable` entirely.
>
> Thanks, I think having this with the StyleConverter makes more sense.

I've replaced the marker interface with an annotation, since it seems to be more of a meta-statement about the type.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1706220057

From almatvee at openjdk.org  Wed Aug  7 00:30:50 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 7 Aug 2024 00:30:50 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6
Message-ID: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>

- libFFI updated to 3.4.6.
- No additional changes are done.
- Tested on Windows, macOS and Linux with all supported formats.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8336938
 - 8336938: Update libFFI to 3.4.6

Changes: https://git.openjdk.org/jfx/pull/1531/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336938
  Stats: 1055 lines in 26 files changed: 388 ins; 373 del; 294 mod
  Patch: https://git.openjdk.org/jfx/pull/1531.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1531/head:pull/1531

PR: https://git.openjdk.org/jfx/pull/1531

From jhendrikx at openjdk.org  Wed Aug  7 01:10:25 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 01:10:25 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v5]
In-Reply-To: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
Message-ID: <MtQGEIIBNo1m275nrs3zM-sHed7ZEDoMslRqfv-jjXA=.9275db3e-59c5-48a5-ad3d-4bb7c27c6abc@github.com>

> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
> 
> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
> 
> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
> 
> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
> 
> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
> - No need anymore for the `SimpleSelectorShim`

John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:

 - Make match fields private by moving match creation logic
 - Move binary CSS serialization code to internal class

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1333/files
  - new: https://git.openjdk.org/jfx/pull/1333/files/4702972d..efe1beea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=03-04

  Stats: 390 lines in 6 files changed: 221 ins; 156 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1333.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333

PR: https://git.openjdk.org/jfx/pull/1333

From jhendrikx at openjdk.org  Wed Aug  7 01:38:55 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 01:38:55 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v6]
In-Reply-To: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
Message-ID: <ngSp1t-Hbu5zZIl4mREipAe5rnsd4g3e6ghYUOvAklY=.5cee59b2-71c9-4e67-9e55-fb342e94fe70@github.com>

> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
> 
> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
> 
> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
> 
> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
> 
> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
> - No need anymore for the `SimpleSelectorShim`

John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Improve error message
 - Merge remote-tracking branch 'origin/master' into feature/selectors-to-private-api-standalone
 - Make match fields private by moving match creation logic
 - Move binary CSS serialization code to internal class
 - Fix review comments
 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/selectors-to-private-api-standalone
 - Add since tags
 - Move SimpleSelector and CompoundSelector to private classes

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

Changes: https://git.openjdk.org/jfx/pull/1333/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=05
  Stats: 1830 lines in 14 files changed: 907 ins; 887 del; 36 mod
  Patch: https://git.openjdk.org/jfx/pull/1333.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333

PR: https://git.openjdk.org/jfx/pull/1333

From jhendrikx at openjdk.org  Wed Aug  7 02:13:12 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 02:13:12 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
Message-ID: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>

> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
> 
> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
> 
> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
> 
> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
> 
> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
> - No need anymore for the `SimpleSelectorShim`

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1333/files
  - new: https://git.openjdk.org/jfx/pull/1333/files/7d77e43e..39c94408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=05-06

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

PR: https://git.openjdk.org/jfx/pull/1333

From jhendrikx at openjdk.org  Wed Aug  7 02:13:12 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 02:13:12 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <TEZPxCWPJpcM2XYj99FFAnTLHg3hTScKsRreqpO-nIY=.9e22807d-4023-49db-a52b-d75af19d7fe3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <Y8slBnOWK3BbOpZyJcofAeCrj7o5jsvR3GIK8IYZoO0=.e4dbc28a-ae48-4f72-8e17-d691c7b01ba1@github.com>
 <MxNh0K_YQ4Ye76MYk1ZgP_qkX7HyyH9rdrS365y6rvk=.a031afde-ae91-4f3f-b7cb-98ec3278345c@github.com>
 <fJDMxLrNNEc_6weB12baAraoyxQ1ZNCuYa8Afjn-bwE=.0b0f8822-a5bf-49a0-a4da-04e913cae3aa@github.com>
 <Q6UPOvGyoGWe_YoN1mRnwC5QoS8yFXwqtHbz9JZa3iQ=.dd2c2f9c-94d6-4439-8c89-6b787faa220f@github.com>
 <vjTuzZX-CeoCwH4qtObvlQzh4DrUXdRbwBcE6fJl-6o=.48122c41-9313-4e66-b3ee-88a75be8265a@github.com>
 <TEZPxCWPJpcM2XYj99FFAnTLHg3hTScKsRreqpO-nIY=.9e22807d-4023-49db-a52b-d75af19d7fe3@github.com>
Message-ID: <jYx2jR7DS-KW5u-t203Hyv3op7G36Q8jqDl-gZcwPKM=.49417bd3-d2d1-4cf5-b20e-33f19eb6939e@github.com>

On Tue, 6 Aug 2024 22:43:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I can see if I can externalize this or if that would run into issues.  Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API.
>> 
>> In other words, this could wait and be done separately or never.
>
> what is the resolution, @hjohn ?

- I've moved the serialization logic to `BinarySerializer` and removed the two methods from `Selector`.  `writeBinary` was `protected` but couldn't be accessed before anyway as it was impossible to subclass `Selector` (as it had a package private constructor)
- I've moved most of the code to create a `Match` to the `Match` class so the relevant fields can now be `private`. 

Let me know if this is an improvement.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1706292988

From duke at openjdk.org  Wed Aug  7 05:36:46 2024
From: duke at openjdk.org (robbiezl)
Date: Wed, 7 Aug 2024 05:36:46 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <CirqrHud73MtfxfzS715FRW7xabcQbwhz47Ui68w0zg=.c7f8bedb-905e-43e5-b001-dc3f34d2fc43@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

I tested it in the following two Linux environments, and the Chinese input looks fine.

Env1:

????:LinxOS 6.0.99 EL20.03-SP3 20240531 \n \l
???Linux version 4.19.90-2206.2.0.0154.vlx15.v99_2003.x86_64 (root at runner-sdczntp1-project-3842-concurrent-0) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 29 10:22:41 CST 2024

Env2:
????:[dist]
name = KylinSec-Server-PG
milestone = V3-240605-1330
arch = x86_64
dist_id = KylinSec-Server-PG-V3-240605-1330-x86_64
[os]
installtype = graphical-server-environment
???Linux version 4.19.90-2405.3.0.0276.kb1.ky3_4.x86_64 (mockbuild at localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Thu May 23 16:22:59 CST 2024

> @Glavo did you get any feedback?
> 
> I can provide a build with this PR included, if that's getting on the way.

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2272653202

From arapte at openjdk.org  Wed Aug  7 14:44:39 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 7 Aug 2024 14:44:39 GMT
Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs
In-Reply-To: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
References: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
Message-ID: <Y4GDHz7BRzhjwvhXk-6eFpNluf3OzoVD1-KzPtOg6xY=.f1bfba83-9046-4e31-81f7-80fb28587af3@github.com>

On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.
> 
> This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.
> 
> Both D3D and ES2 Prism backends were updated to properly handle these changes.
> 
> NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.
> 
> I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

Marked as reviewed by arapte (Reviewer).

The change looks good.
D3D and ES2 pipeline work as expected after a clean build.
It seems good for Metal pipeline too. Merge requires a few minor expected changes(similar to D3D/ES2 in this PR + another).

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

PR Review: https://git.openjdk.org/jfx/pull/1530#pullrequestreview-2225412705
PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2273642280

From angorya at openjdk.org  Wed Aug  7 14:53:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 14:53:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
Message-ID: <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>

On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace StyleConverter.SupportsDeconstruction interface with annotation

modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 108:

> 106:     public @interface SupportsReconstruction {}
> 107: 
> 108:     final boolean supportsReconstruction;

would it be easier just to pass a boolean to the constructor?
we are changing the public API anyway...

also: since the boolean is package protected, should we have a (short) javadoc for it?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707173763

From mstrauss at openjdk.org  Wed Aug  7 15:23:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 15:23:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
Message-ID: <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>

On Wed, 7 Aug 2024 14:50:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> would it be easier just to pass a boolean to the constructor? we are changing the public API anyway...

Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707218233

From angorya at openjdk.org  Wed Aug  7 15:23:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 15:23:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
Message-ID: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>

On Wed, 7 Aug 2024 15:08:30 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 108:
>> 
>>> 106:     public @interface SupportsReconstruction {}
>>> 107: 
>>> 108:     final boolean supportsReconstruction;
>> 
>> would it be easier just to pass a boolean to the constructor?
>> we are changing the public API anyway...
>> 
>> also: since the boolean is package protected, should we have a (short) javadoc for it?
>
>> would it be easier just to pass a boolean to the constructor? we are changing the public API anyway...
> 
> Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer?

I just think it's much simpler than an annotation...

Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707228516

From jhendrikx at openjdk.org  Wed Aug  7 15:23:43 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 15:23:43 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
Message-ID: <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>

On Wed, 7 Aug 2024 15:12:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> would it be easier just to pass a boolean to the constructor? we are changing the public API anyway...
>> 
>> Usually boolean parameters are not a good API choice, but I have no strong opinion on this one. What do you prefer?
>
> I just think it's much simpler than an annotation...
> 
> Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance.

But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707250058

From mstrauss at openjdk.org  Wed Aug  7 15:37:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 15:37:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
Message-ID: <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>

On Wed, 7 Aug 2024 15:21:18 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I just think it's much simpler than an annotation...
>> 
>> Or it could be a public instance method `boolean isSupportReconstruction()` for the child classes to override, saving N (1? 8?) bytes per instance.
>
> But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here.

Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options:
1. Boolean parameter / Feature enum passed to constructor
2. Instance method `isSupportReconstruction()`
3. Annotation
4. Empty marker interface
5. Interface with the `convertBack` method
6. Subclassing

I lean slightly towards the annotation, but I'm generally okay with either option.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707281230

From angorya at openjdk.org  Wed Aug  7 16:06:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 16:06:43 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
Message-ID: <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>

On Wed, 7 Aug 2024 15:34:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> But the annotation costs no bytes per instance, if that even matters, as I thought these were singletons so it looks like we're quite into micro-optimization territory here.
>
> Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options:
> 1. Boolean parameter / Feature enum passed to constructor
> 2. Instance method `isSupportReconstruction()`
> 3. Annotation
> 4. Empty marker interface
> 5. Interface with the `convertBack` method
> 6. Subclassing
> 
> I lean slightly towards the annotation, but I'm generally okay with either option.

I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?".  since there is a boolean, why not pass it directly?

it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity".

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707345002

From quizynox at gmail.com  Wed Aug  7 16:20:35 2024
From: quizynox at gmail.com (quizynox at gmail.com)
Date: Wed, 7 Aug 2024 20:20:35 +0400
Subject: Linux memory leak?
Message-ID: <b12e3781-39f3-4def-b017-413cf5d17495@gmail.com>

Hello,

Through developing JavaFX apps on Linux (X11, KDE) I always see the 
pattern when process (native?) memory doesn't get released back to the OS.

1. when app starts, the Java process consumes a relatively small amount 
of RAM (I track this via top or DE system monitor), usually around 120Mb.
2. if you do any manipulation with Stage (like resize it several times, 
or open the context menu several times) the memory process usage goes up 
to 130Mb.
3. then comes GC, which collects some _heap_ memory and returns it back 
to the OS depending on JVM settings, let say -5Mb
4. I repeat step 2, and JVM process process usage goes up again, +10Mb
5. again GC collects some _heap_ memory and uncommits it back to OS, -5Mb

I have profiled the application with JDK 21 / JavaFX 21 and the 
following settings:
-Xms32m
-Xmx64m
-XX:+UseZGC
-XX:+ZUncommit
-XX:ZUncommitDelay=30

Heap is not a problem, it's always ~20-30MB.
Metaspace is not a problem either, it's always around 2-4MB.

It looks like native (stack, thread?) memory leaks, so never returned to 
the OS. I've never seen JavaFX app process memory usage return (not even 
close) to the same value it started with. RAM usage increases gradually 
and can be 1.5, 2, 3 times the initial value. Yet the heap usage never 
rises above the -Xms value.

I run the same application (it's basically an empty stage) on Windows 
and see no such behavior. Process memory usage returns back to initial 
value almost immediately. Also, on Windows the JVM is freeing memory 
even without using ZGC.

How should I profile this? Any hints?


From angorya at openjdk.org  Wed Aug  7 16:23:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 16:23:45 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
Message-ID: <X3C4qAVxH4eBJB0duXyglUFUitbJq5XqvTNmYCO0LgY=.6c4df602-9c5b-4e78-ab42-2a870f24a732@github.com>

On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace StyleConverter.SupportsDeconstruction interface with annotation

This transition does not interpolate linearly.  Should it?


.button {
}

.button:hover {
  -fx-font-size:200%;
  transition: 
    -fx-font-size 2s linear;
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273849547

From mstrauss at openjdk.org  Wed Aug  7 16:46:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 16:46:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <X3C4qAVxH4eBJB0duXyglUFUitbJq5XqvTNmYCO0LgY=.6c4df602-9c5b-4e78-ab42-2a870f24a732@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <X3C4qAVxH4eBJB0duXyglUFUitbJq5XqvTNmYCO0LgY=.6c4df602-9c5b-4e78-ab42-2a870f24a732@github.com>
Message-ID: <kKIHaj-Qwckz8d6EfrbEd3tMAX54DEFuorCq56fFXA8=.d2739a9c-cc02-44d6-a03c-d04b68508a33@github.com>

On Wed, 7 Aug 2024 16:21:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This transition does not interpolate linearly. Should it?
> 
> ```
> .button {
> }
> 
> .button:hover {
>   -fx-font-size:200%;
>   transition: 
>     -fx-font-size 2s linear;
> }
> ```

`Font` is not `Interpolatable`, and its style converter does not support reconstruction. Thus it falls back to discrete interpolation. I'll file a new ticket to track this enhancement.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273888259

From thiago.sayao at gmail.com  Wed Aug  7 16:57:32 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 7 Aug 2024 13:57:32 -0300
Subject: Linux memory leak?
In-Reply-To: <b12e3781-39f3-4def-b017-413cf5d17495@gmail.com>
References: <b12e3781-39f3-4def-b017-413cf5d17495@gmail.com>
Message-ID: <CAAP_wunU7qgGa27UQagzAo3V=+1LrmtuXhjiiTqwS_xh=KaMrQ@mail.gmail.com>

Hi,

There are some tips in this post (I've never tried them). GTK related
environment variables generally work.
https://stackoverflow.com/questions/16659781/memory-leaks-in-gtk-hello-world-program

valgrind and java:
https://stackoverflow.com/questions/9216815/valgrind-and-java


-- Thiago


Em qua., 7 de ago. de 2024 ?s 13:20, <quizynox at gmail.com> escreveu:

> Hello,
>
> Through developing JavaFX apps on Linux (X11, KDE) I always see the
> pattern when process (native?) memory doesn't get released back to the OS.
>
> 1. when app starts, the Java process consumes a relatively small amount
> of RAM (I track this via top or DE system monitor), usually around 120Mb.
> 2. if you do any manipulation with Stage (like resize it several times,
> or open the context menu several times) the memory process usage goes up
> to 130Mb.
> 3. then comes GC, which collects some _heap_ memory and returns it back
> to the OS depending on JVM settings, let say -5Mb
> 4. I repeat step 2, and JVM process process usage goes up again, +10Mb
> 5. again GC collects some _heap_ memory and uncommits it back to OS, -5Mb
>
> I have profiled the application with JDK 21 / JavaFX 21 and the
> following settings:
> -Xms32m
> -Xmx64m
> -XX:+UseZGC
> -XX:+ZUncommit
> -XX:ZUncommitDelay=30
>
> Heap is not a problem, it's always ~20-30MB.
> Metaspace is not a problem either, it's always around 2-4MB.
>
> It looks like native (stack, thread?) memory leaks, so never returned to
> the OS. I've never seen JavaFX app process memory usage return (not even
> close) to the same value it started with. RAM usage increases gradually
> and can be 1.5, 2, 3 times the initial value. Yet the heap usage never
> rises above the -Xms value.
>
> I run the same application (it's basically an empty stage) on Windows
> and see no such behavior. Process memory usage returns back to initial
> value almost immediately. Also, on Windows the JVM is freeing memory
> even without using ZGC.
>
> How should I profile this? Any hints?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/bf1e0344/attachment.htm>

From angorya at openjdk.org  Wed Aug  7 17:44:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 17:44:45 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
Message-ID: <cYTBqGjOj_tyg6ONkeFgGgB9Mt08PnF-Ah6X2JNUiQs=.e9a8fd6f-a6ed-4fd0-807d-4ee22847547e@github.com>

On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace StyleConverter.SupportsDeconstruction interface with annotation

I could not find in cssref.html any reference to which properties are interpolatable, and which components of interpolatable and which support reconstruction.  I think we need to update the spec with this information.

For example, the following does not interpolate, is it because I am doing something wrong or the border radius is not interpolatable?


.button {
 -fx-border-radius: 100;
}

.button:hover {
 -fx-border-radius: 1;
  transition: 
   -fx-border-radius 2s linear;
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2273997052

From angorya at openjdk.org  Wed Aug  7 17:49:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 17:49:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
Message-ID: <aAhllDEuS1IJrVOhWUx1y-HBle7cmotkJvQJZhLPE28=.e5a01223-c57f-414e-8970-d8d1b30a8c2b@github.com>

On Tue, 6 Aug 2024 23:47:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace StyleConverter.SupportsDeconstruction interface with annotation

Somewhat tangential question: perhaps this enhancement needs a JEP (or a JEP-formatted doc) for future reference.  The github infrastructure may one day disappear but I think these kinds of documents should be preserved.

Even more tangential question is where to put these docs?  For example, I think a good place might be in /doc-files somewhere, makes the review process easier.  We've been creating these docs in private repos which I think is not a good place for the final product (i.e. when the feature is integrated).

What do you think?  (I will also post this question in the mailing list).

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274004355

From quizynox at gmail.com  Wed Aug  7 17:54:49 2024
From: quizynox at gmail.com (mkpaz)
Date: Wed, 7 Aug 2024 21:54:49 +0400
Subject: Linux memory leak?
In-Reply-To: <CAAP_wunU7qgGa27UQagzAo3V=+1LrmtuXhjiiTqwS_xh=KaMrQ@mail.gmail.com>
References: <b12e3781-39f3-4def-b017-413cf5d17495@gmail.com>
 <CAAP_wunU7qgGa27UQagzAo3V=+1LrmtuXhjiiTqwS_xh=KaMrQ@mail.gmail.com>
Message-ID: <6deba86d-21ac-487c-85b8-2c4cf497e7cd@gmail.com>

I tried using jemalloc, but the generated output (attachment) looks 
useless to me.

https://gist.github.com/thomasdarimont/79b3cef01e5786210309

On 07/08/2024 20.57, Thiago Milczarek Say?o wrote:
> Hi,
>
> There are some tips in this post (I've?never tried them). GTK related 
> environment variables generally work.
> https://stackoverflow.com/questions/16659781/memory-leaks-in-gtk-hello-world-program
>
> valgrind and java:
> https://stackoverflow.com/questions/9216815/valgrind-and-java
>
>
> -- Thiago
>
>
> Em qua., 7 de ago. de 2024 ?s 13:20, <quizynox at gmail.com> escreveu:
>
>     Hello,
>
>     Through developing JavaFX apps on Linux (X11, KDE) I always see the
>     pattern when process (native?) memory doesn't get released back to
>     the OS.
>
>     1. when app starts, the Java process consumes a relatively small
>     amount
>     of RAM (I track this via top or DE system monitor), usually around
>     120Mb.
>     2. if you do any manipulation with Stage (like resize it several
>     times,
>     or open the context menu several times) the memory process usage
>     goes up
>     to 130Mb.
>     3. then comes GC, which collects some _heap_ memory and returns it
>     back
>     to the OS depending on JVM settings, let say -5Mb
>     4. I repeat step 2, and JVM process process usage goes up again, +10Mb
>     5. again GC collects some _heap_ memory and uncommits it back to
>     OS, -5Mb
>
>     I have profiled the application with JDK 21 / JavaFX 21 and the
>     following settings:
>     -Xms32m
>     -Xmx64m
>     -XX:+UseZGC
>     -XX:+ZUncommit
>     -XX:ZUncommitDelay=30
>
>     Heap is not a problem, it's always ~20-30MB.
>     Metaspace is not a problem either, it's always around 2-4MB.
>
>     It looks like native (stack, thread?) memory leaks, so never
>     returned to
>     the OS. I've never seen JavaFX app process memory usage return
>     (not even
>     close) to the same value it started with. RAM usage increases
>     gradually
>     and can be 1.5, 2, 3 times the initial value. Yet the heap usage
>     never
>     rises above the -Xms value.
>
>     I run the same application (it's basically an empty stage) on Windows
>     and see no such behavior. Process memory usage returns back to
>     initial
>     value almost immediately. Also, on Windows the JVM is freeing memory
>     even without using ZGC.
>
>     How should I profile this? Any hints?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/944c6491/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: app-profiling.pdf
Type: application/pdf
Size: 16923 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/944c6491/app-profiling-0001.pdf>

From andy.goryachev at oracle.com  Wed Aug  7 17:58:43 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 Aug 2024 17:58:43 +0000
Subject: No Place for JEPs
Message-ID: <BL3PR10MB618595435024348B39CEB480E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>

Dear fellow developers:

We often create JEPs and JEP-formatted documents as we propose and develop new features.  These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth.  Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0].

I think there is a value in making these documents a part of the main repository, maybe under /doc-files.  Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed.  Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis.

What do you think?

-andy


References

[0] https://github.com/openjdk/jfx/pull/1522
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/6792e4ba/attachment.htm>

From mstrauss at openjdk.org  Wed Aug  7 18:34:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 18:34:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <cYTBqGjOj_tyg6ONkeFgGgB9Mt08PnF-Ah6X2JNUiQs=.e9a8fd6f-a6ed-4fd0-807d-4ee22847547e@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <cYTBqGjOj_tyg6ONkeFgGgB9Mt08PnF-Ah6X2JNUiQs=.e9a8fd6f-a6ed-4fd0-807d-4ee22847547e@github.com>
Message-ID: <qesDiwXCasyd5q4gNc7OA_hsKDvj4c3GC9j92Z3R_64=.16b7f4b9-e052-4609-891b-875c3c049d0d@github.com>

On Wed, 7 Aug 2024 17:42:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I could not find in `cssref.html` any reference to which properties are interpolatable, and which components of interpolatable and which support reconstruction. I think we need to update the spec with this information.
> 
> For example, the following does not interpolate, is it because I am doing something wrong or the border radius is not interpolatable?
> 
> ```
> .button {
>  -fx-border-radius: 100;
> }
> 
> .button:hover {
>  -fx-border-radius: 1;
>   transition: 
>    -fx-border-radius 2s linear;
> }
> ```

You probably don't see anything because Modena's button doesn't have a visible border. Try specifying some color to make it visible:

.button {
    -fx-border-radius: 10,
    -fx-border-color: red;
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274084408

From mstrauss at openjdk.org  Wed Aug  7 18:47:38 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 18:47:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <aAhllDEuS1IJrVOhWUx1y-HBle7cmotkJvQJZhLPE28=.e5a01223-c57f-414e-8970-d8d1b30a8c2b@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <aAhllDEuS1IJrVOhWUx1y-HBle7cmotkJvQJZhLPE28=.e5a01223-c57f-414e-8970-d8d1b30a8c2b@github.com>
Message-ID: <e-eA8V627QIeAAAqFcdArwk43HzbbzZ0Cl6Z5pZlUQ8=.72881419-9b00-4d40-a150-0dbd4aeac7f9@github.com>

On Wed, 7 Aug 2024 17:47:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Somewhat tangential question: perhaps this enhancement needs a JEP (or a JEP-formatted doc) for future reference. The github infrastructure may one day disappear but I think these kinds of documents should be preserved.
> 
> Even more tangential question is where to put these docs? For example, I think a good place might be in /doc-files somewhere, makes the review process easier. We've been creating these docs in private repos which I think is not a good place for the final product (i.e. when the feature is integrated).
> 
> What do you think? (I will also post this question in the mailing list).

Isn't this the purpose of the CSR documents?

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274118227

From john.hendrikx at gmail.com  Wed Aug  7 18:52:32 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 7 Aug 2024 20:52:32 +0200
Subject: Detecting threading problems faster
In-Reply-To: <CAJEpuXR5=MzbXTGw6qPfgModf_s6NOfED53wowjWD9XgrdTfDw@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAJEpuXR5=MzbXTGw6qPfgModf_s6NOfED53wowjWD9XgrdTfDw@mail.gmail.com>
Message-ID: <4058b4c3-94fc-4bc6-9604-c6c93e7d8c15@gmail.com>

Hey Michael,

Thanks, I totally forgotten about that post apparently, perhaps we can 
make this work.

I thought of something else as well. We seem to be assuming that 
checking the Thread is the expensive part, where it in reality is one of 
the cheapest checks that we can do.? We could always check the thread, 
and only do a further investigation if that thread is NOT the FX thread, 
perhaps something like this:

 ??? if (getBean() != null && !Thread.currentThread().equals(FXThread)) {
 ????????? // Investigate further... we're either offline (safe) or 
online (not safe)
 ????????? if (notSafe()) throw exception;
 ??? }
 ??? // proceed as normal

The above checks are both incredibly cheap.

In the case where we want to do a deeper investigation, we're either 
offline where performance will be a lot less important (graphs can be 
built by other threads), or we're online, which is the case that we want 
to warn users about.? In both cases, a somewhat reduced performance 
won't matter much, while the case when the graph is live and is called 
correctly will be perform almost unimpeded.

--John


On 05/08/2024 17:35, Michael Strau? wrote:
> Hi John,
>
> this seems to be a very similar idea to what I've proposed a year ago:
> https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/041925.html
>
> I think the potential performance impact needs to be carefully considered.

From john.hendrikx at gmail.com  Wed Aug  7 18:55:09 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 7 Aug 2024 20:55:09 +0200
Subject: Detecting threading problems faster
In-Reply-To: <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
 <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
Message-ID: <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>

For detecting long running tasks on the FX thread, there are some other 
options which you can do as a user (but perhaps we can support it 
directly within FX).? I use this kind of code to detect long running 
things on the FX thread:

/**

* Adds a slow event warning whenever an event takes more than 10 msto 
process. Note

* that time spent in nested event loops cannot be properly taken into 
account as time

* spent in nested event loops will be part of the event that triggered 
it giving false

* positives. In order for this time to be accurately reflected, the 
methods to enter

* a nested event loop in this class should be used instead of the ones 
in {@link Platform}.

*

* @paramscene a Scene to which to add the slow event warning detection, 
cannot be null

*/

publicstaticvoidaddSlowEventWarning(Scene scene) {

finalEventDispatcher eventDispatcher = scene.getEventDispatcher();

scene.setEventDispatcher(newEventDispatcher() {

privateScheduledFuture<StackTraceElement[]> future;

@Override

publicEvent dispatchEvent(Event event, EventDispatchChain tail) {

if(future!= null) {

future.cancel(false);

}

longstartTime = System.currentTimeMillis();

TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways, 
an event triggering another event, or when a nested event loop is entered

Event returnedEvent = eventDispatcher.dispatchEvent(event, tail);

longendTime = System.currentTimeMillis();

longtimeSpentInNested = TIME_TRACKER.exitNested(endTime);

if(timeSpentInNested > 10) {

longtotal = endTime - startTime;

LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested + "/"+ 
total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "): "+ event);

}

returnreturnedEvent;

}

});

}

--John

On 05/08/2024 17:17, Thiago Milczarek Say?o wrote:
> Hi,
>
> Interesting idea. We have this problem specially when Junior 
> developers touch the code.
>
> The other way around would be nice too - if some I/O task executes on 
> the FX thread.
>
> This can make the OS think the application hanged and offer to kill 
> it, since it won't respond to "pings". And I/O tasks processing time 
> may vary between installations. Also causes "white screens" since it 
> blocks painting.
>
> -- Thiago.
>
> Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth 
> <kevin.rushforth at oracle.com> escreveu:
>
>>     Wouldn't it be better to implement this check in assert to avoid
>>     any impact in production?
>
>     No. Using an assert in a case like this is an anti-pattern. A call
>     to assert in a library such as JavaFX is only appropriate for
>     checking an invariant in internal logic. If we are going to go
>     down this route of doing a thread check when mutating properties
>     of "live" nodes, we will throw the same IllegalStateException that
>     is currently thrown by some methods on Stage and Scene.
>
>     As for the proposal itself, adding this check is an interesting
>     idea. We considered doing this back in the JDK 7 (JavaFX 2) time
>     frame, but decided not to pursue it then. I think the idea is
>     worth further discussion. I would limit any thread checking to
>     setting the property. It would be too restrictive (and largely
>     unnecessary) to prevent reading a property from the application
>     thread.
>
>     The things to consider would be:
>
>     1. What is the performance hit of doing this check on the setting
>     of every property?
>     2. What is the effect on bound properties?
>     3. How intrusive is it in the code?
>     4. Should we add a property to enable / disable the thread check,
>     possibly a three- or four-valued property
>     (allow|warn|debug?|deny), as was recently done in JEP 471 for
>     sun.misc.Unsafe memory access methods. If so, what should the
>     default be?
>
>     My quick take is that if this can be done in a minimally intrusive
>     manner with low overhead, we should consider pursing this. As for
>     4, my preference would be to add a three- or four-valued system
>     property to control the check, with "warn" as the default
>     initially, changing the default to "disallow" in a subsequent
>     version. This would, of course, require a lot of testing.
>
>     -- Kevin
>
>
>     On 8/4/2024 8:40 PM, quizynox wrote:
>>     Hello,
>>
>>     Wouldn't it be better to implement this check in assert to avoid
>>     any impact in production?
>>
>>     ??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com>:
>>
>>         Hi list,
>>
>>         I know of quite some bugs and users that have been bitten by the
>>         threading model used by JavaFX.? Basically, anything directly or
>>         indirectly linked to an active Scene must be accessed on the
>>         FX thread.
>>         However, as FX also allows manipulating nodes and properties
>>         before
>>         they're displayed, there can be no "hard" check everywhere to
>>         ensure we
>>         are on the FX thread (specifically, in properties).
>>
>>         Now, I think this situation is annoying, as a simple mistake
>>         where a
>>         Platform.runLater wrapper was forgotten usually results in
>>         programs
>>         operating mostly flawlessly, but then fail in mysterious and
>>         random and
>>         hard to reproduce ways.? The blame is often put on FX as the
>>         resulting
>>         exceptions will almost never show the user code which was the
>>         actual
>>         culprit.? It can result in FX being perceived as unstable or
>>         buggy.
>>
>>         So I've been thinking if there isn't something we can do to
>>         detect these
>>         bugs originating from user code much earlier, similar to the
>>         `ConcurrentModificationException` the collection classes do when
>>         accessed in nested or concurrent contexts.
>>
>>         I think it may be possible to have properties check whether
>>         they're part
>>         of an active scene without too much of an performance impact,
>>         possibly
>>         even behind a switch. It would work like this:
>>
>>         Properties involved with Nodes will have an associated bean
>>         instance
>>         (`getBean`).? This is an object, but we could check here if this
>>         instance implements an interface:
>>
>>         ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
>>         ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) {
>>         ???????????????? throw new IllegalStateException("Property
>>         must only be
>>         used from the FX Application Thread");
>>         ??????????? }
>>         ????? }
>>
>>         This check could be done on every set of the property, and
>>         potentially
>>         on every get as well.? It should be relatively cheap, but
>>         will expose
>>         problematic code patterns at a much earlier stage. There's a
>>         chance
>>         that this will "break" some programs that seemed to be behaving
>>         correctly as well, so we may want to put it behind a switch
>>         until such
>>         programs (or libraries) can be fixed.
>>
>>         What do you all think?
>>
>>         --John
>>
>>         (*) Names of methods/interfaces are only used for
>>         illustration purposes,
>>         we can think of good names if this moves forward.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/ffd19ecf/attachment-0001.htm>

From angorya at openjdk.org  Wed Aug  7 18:58:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 18:58:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <e-eA8V627QIeAAAqFcdArwk43HzbbzZ0Cl6Z5pZlUQ8=.72881419-9b00-4d40-a150-0dbd4aeac7f9@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <aAhllDEuS1IJrVOhWUx1y-HBle7cmotkJvQJZhLPE28=.e5a01223-c57f-414e-8970-d8d1b30a8c2b@github.com>
 <e-eA8V627QIeAAAqFcdArwk43HzbbzZ0Cl6Z5pZlUQ8=.72881419-9b00-4d40-a150-0dbd4aeac7f9@github.com>
Message-ID: <RzNvobzwebdohXaNq9gfsuk3GOAKqWTNJJthUzoA6bk=.0e1bdc2c-0e0e-4761-8a39-a7e4c6e730d1@github.com>

On Wed, 7 Aug 2024 18:45:00 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Isn't this the purpose of the CSR documents?

These two are related but not the same, per https://wiki.openjdk.org/display/csr/CSR+FAQs :

Q: What is the relationship between a CSR and a JEP?
A: A JEP ([JDK Enhancement-Proposal](http://openjdk.java.net/jeps/0)) initially describes a project to update some aspect of the JDK. The exact details of the updates are usually not yet known when the JEP begins. Before a JEP is advanced to the Candidate state, it is strongly recommended the CSRs of a JEP go through at least the first phase of CSR review to Provisional state. Before a JEP is advanced to the Proposed to Target state, CSRs associated with the JEP must have advanced through to at least the CSR Provisional state. For Proposed to Target, the CSRs covering the work of a JEP may also go fully through the CSR process to the Approved state rather than the Provisional state. As the JEP matures, the updates to the JDK associated with the JEP are pushed under one or more changesets. Each changeset that involves a specification change (or sufficiently large compatibility impact) would also require CSR review, just as done for other changes to the JDK.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274142010

From john.hendrikx at gmail.com  Wed Aug  7 19:01:44 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 7 Aug 2024 21:01:44 +0200
Subject: Detecting threading problems faster
In-Reply-To: <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <e7d63cf3-b093-4581-b8ec-10c1e470bfaf@gmail.com>

Hi Andy,

Problems that occur due to modifying the scene graph (like 
adding/removing children, or changing certain properties) can be 
incredibly subtle, and almost never point out the code that is the 
actual culprit.? I suspect that the PR below is one of those for 
example, but there are likely many more.

https://github.com/openjdk/jfx/pull/1123

Issues that complain about some kind of odd bug in the FX code (like a 
NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, 
etc) could all be caused by user code doing things on the wrong thread, 
but its really hard to diagnose as the stack traces provided will never 
point out the user code that may be the culprit.? I've investigated PR 
1123 extensively, and I can't see any bugs in the FX code at all 
**assuming** it is used from a single thread...

--John

On 05/08/2024 17:01, Andy Goryachev wrote:
>
> John:
>
> Can you cite a bug or give an example of such a problem?
>
> During all my time of actively using javafx (since about 2015) I have 
> never encountered an issue with threading you describe.? It is 
> possible that I use the system trivially and not to the full extent.? 
> Both swing and javafx are single threaded by design.? Yes, there might 
> be occasions when one can use multiple threads and it is sort of 
> allowed, but doing so may lead to unpleasant issues down the road, so 
> the question is why would you want to do that?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John 
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Sunday, August 4, 2024 at 16:30
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Detecting threading problems faster
>
> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model used by JavaFX.? Basically, anything directly or
> indirectly linked to an active Scene must be accessed on the FX thread.
> However, as FX also allows manipulating nodes and properties before
> they're displayed, there can be no "hard" check everywhere to ensure we
> are on the FX thread (specifically, in properties).
>
> Now, I think this situation is annoying, as a simple mistake where a
> Platform.runLater wrapper was forgotten usually results in programs
> operating mostly flawlessly, but then fail in mysterious and random and
> hard to reproduce ways.? The blame is often put on FX as the resulting
> exceptions will almost never show the user code which was the actual
> culprit.? It can result in FX being perceived as unstable or buggy.
>
> So I've been thinking if there isn't something we can do to detect these
> bugs originating from user code much earlier, similar to the
> `ConcurrentModificationException` the collection classes do when
> accessed in nested or concurrent contexts.
>
> I think it may be possible to have properties check whether they're part
> of an active scene without too much of an performance impact, possibly
> even behind a switch. It would work like this:
>
> Properties involved with Nodes will have an associated bean instance
> (`getBean`).? This is an object, but we could check here if this
> instance implements an interface:
>
> ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
> ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) {
> ???????????????? throw new IllegalStateException("Property must only be
> used from the FX Application Thread");
> ??????????? }
> ????? }
>
> This check could be done on every set of the property, and potentially
> on every get as well.? It should be relatively cheap, but will expose
> problematic code patterns at a much earlier stage. There's a chance
> that this will "break" some programs that seemed to be behaving
> correctly as well, so we may want to put it behind a switch until such
> programs (or libraries) can be fixed.
>
> What do you all think?
>
> --John
>
> (*) Names of methods/interfaces are only used for illustration purposes,
> we can think of good names if this moves forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/59c9f2b4/attachment.htm>

From andy.goryachev at oracle.com  Wed Aug  7 19:38:33 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 Aug 2024 19:38:33 +0000
Subject: [External] : Re: Detecting threading problems faster
In-Reply-To: <e7d63cf3-b093-4581-b8ec-10c1e470bfaf@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e7d63cf3-b093-4581-b8ec-10c1e470bfaf@gmail.com>
Message-ID: <BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>

John:

Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread.

I know the discussion is about trying to detect thread misuse early on, as a way to help the application developers.  I vaguely recall the discussion we had at some point about adding the check to property invalidation code or some such, and the general consensus was that it might pose a compatibility risk or something along these lines.

Perhaps there is a place where such a check might be safely made (I don't know of any such place though)?   We did, after all, step on the path of simplification (?) for the sake of students (see https://openjdk.org/jeps/445 ).  Perhaps such a check could be hidden behind a system property so as not to break existing, if poorly written, applications.

Personally, I feel that it should be the first thing taught - always call FX from the FX application thread.

I am curious what other members of community think of this issue.

-andy




From: John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, August 7, 2024 at 12:01
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Detecting threading problems faster

Hi Andy,

Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit.  I suspect that the PR below is one of those for example, but there are likely many more.

https://github.com/openjdk/jfx/pull/1123<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1123__;!!ACWV5N9M2RV99hQ!ILqOOB9ua4tDxfAV9pGPJJiQ3oXewiSQjH2BCsaQkhpgkHEQzT8hRQt2fb9mKjYbF24ZRpQwfEiELFvn4B28lBLwxrTE$>

Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack traces provided will never point out the user code that may be the culprit.  I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread...

--John
On 05/08/2024 17:01, Andy Goryachev wrote:
John:

Can you cite a bug or give an example of such a problem?

During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe.  It is possible that I use the system trivially and not to the full extent.  Both swing and javafx are single threaded by design.  Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Sunday, August 4, 2024 at 16:30
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Detecting threading problems faster
Hi list,

I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX.  Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displayed, there can be no "hard" check everywhere to ensure we
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a
Platform.runLater wrapper was forgotten usually results in programs
operating mostly flawlessly, but then fail in mysterious and random and
hard to reproduce ways.  The blame is often put on FX as the resulting
exceptions will almost never show the user code which was the actual
culprit.  It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these
bugs originating from user code much earlier, similar to the
`ConcurrentModificationException` the collection classes do when
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part
of an active scene without too much of an performance impact, possibly
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance
(`getBean`).  This is an object, but we could check here if this
instance implements an interface:

      if (getBean() instanceof MayBePartOfSceneGraph x) {
            if (x.isPartOfActiveScene() && !isOnFxThread()) {
                 throw new IllegalStateException("Property must only be
used from the FX Application Thread");
            }
      }

This check could be done on every set of the property, and potentially
on every get as well.  It should be relatively cheap, but will expose
problematic code patterns at a much earlier stage.  There's a chance
that this will "break" some programs that seemed to be behaving
correctly as well, so we may want to put it behind a switch until such
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes,
we can think of good names if this moves forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/f8413aad/attachment-0001.htm>

From mstrauss at openjdk.org  Wed Aug  7 20:03:17 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 20:03:17 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  interpolate integers in real number space

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/61d595fd..c36c6c05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=18
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=17-18

  Stats: 67 lines in 3 files changed: 55 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Wed Aug  7 20:03:17 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 20:03:17 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v2]
In-Reply-To: <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <HT-cPKlgJJLsf2We9F_sBsLXqJPYiHJ5dotWAEGfYo0=.49faed2d-891c-4777-ad1b-50e2d19c3715@github.com>
 <_HwP01qmvurO5jBgEJ50MvRzBAC1RY1YpysWGYuZlt0=.a1c4f05e-09aa-4214-beb6-994c8162ea17@github.com>
 <9oq88dfCt9HRiDyl8zizIpvYlkDIggCzO5VwBcs9-TY=.3649f067-6a4d-4ed5-84e1-7a818cc27fdf@github.com>
Message-ID: <LvyInG4R9lzeUotLmS-bp7T8Cuf3pQVjPEhi_Qk6-fo=.7ed44789-e0cc-4981-aad2-6b516876f4ac@github.com>

On Fri, 2 Aug 2024 16:19:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 136:
>> 
>>> 134:         @Override
>>> 135:         public void onUpdate(double progress) {
>>> 136:             set(progress < 1 ? startValue + (long)((endValue - startValue) * progress) : endValue);
>> 
>> minor: should it use (long)Math.round() ?
>
> edit: I think it should.

You're right, I've updated the implementation and added tests.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707796319

From angorya at openjdk.org  Wed Aug  7 20:54:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 20:54:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
Message-ID: <yTEMUbOdGOCA8e5V7ekFJvccY8X6Xav6Lk1PuFqueqw=.4e323345-bcd8-46f1-be6e-90971e1408f6@github.com>

On Wed, 7 Aug 2024 20:03:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   interpolate integers in real number space

Regarding `cssref.html`:

1. I think it might make sense to add a section after "Transitions" talking about component transitions, maybe with examples.
2. I think we should to mention interpolation behavior next to each property name somehow.  Either mark the properties that do support it, or only those that do not support.  It is already documented in javadoc, but cssref.html is a normative document for CSS.

what do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274327067

From jhendrikx at openjdk.org  Wed Aug  7 21:01:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 21:01:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
Message-ID: <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>

On Wed, 7 Aug 2024 16:03:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Whether a style converter supports reconstruction should be a statement about the type, not a statement about the instance. For this reason, I don't prefer an instance method like `isSupportReconstruction()`. In any case, these are our options:
>> 1. Boolean parameter / Feature enum passed to constructor
>> 2. Instance method `isSupportReconstruction()`
>> 3. Annotation
>> 4. Empty marker interface
>> 5. Interface with the `convertBack` method
>> 6. Subclassing
>> 
>> I lean slightly towards the annotation, but I'm generally okay with either option.
>
> I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?".  since there is a boolean, why not pass it directly?
> 
> it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity".

Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well.

There seem to be a couple of general approaches:

1. Have a marker that can be checked from the outside
    - Annotation (checked from the outside)
        - Unusual for this kind of check
    - Marker interface
        - Seen more often, but unusual to not put the new method there
    - Subtype 
        - Bad idea, you can only inherit once
2. Introduce a new interface with the new method
    - Defines the method and serves as the marker at the same time
3. Have a method that can be called that guards a 2nd method call
    - Doesn't matter how this is fed (constructor, annotation, override)
        -  You see this more often, but it's not a great pattern (2 method calls for the price of one...)
4. Return a special value from a method that may be unsupported
    - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support
    - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix)
    - Return `null`

Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9.  Even though it may not be the prettiest solution, it has two things going for it:

- It's fast (probably the fastest of the above options, although for most by just a slim margin)
- It fits in with the existing design

So, my order of preference:
- Just return `null`
- A new interface, which includes the new method
- A marker only interface
- A supportsXYZ method (regardless of how that is approached)

I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1707899228

From john.hendrikx at gmail.com  Wed Aug  7 21:53:04 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 7 Aug 2024 23:53:04 +0200
Subject: [External] : Re: Detecting threading problems faster
In-Reply-To: <BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e7d63cf3-b093-4581-b8ec-10c1e470bfaf@gmail.com>
 <BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <ec2d39b1-cd2b-4d7e-a2ad-8a44ae9cd56c@gmail.com>


On 07/08/2024 21:38, Andy Goryachev wrote:
>
> John:
>
> Looks like the issue in PR#1123 was caused by application code 
> accessing FX from a non-FX thread.
>
That does seem likely, but it is incredibly hard to be sure.
>
> I know the discussion is about trying to detect thread misuse early 
> on, as a way to help the application developers.? I vaguely recall the 
> discussion we had at some point about adding the check to property 
> invalidation code or some such, and the general consensus was that it 
> might pose a compatibility risk or something along these lines.
>
> Perhaps there is a place where such a check might be safely made (I 
> don't know of any such place though)?? ?We did, after all, step on the 
> path of simplification (?) for the sake of students (see 
> https://openjdk.org/jeps/445 ).? Perhaps such a check could be hidden 
> behind a system property so as not to break existing, if poorly 
> written, applications.
>
I agree that we should be careful not to break anything, it is a check, 
but I also think that most developers will want this check on (but 
probably not by default initially, but definitely **after** they fixed 
any mistakes it detected to avoid recurrence). There is nothing worse 
than code that only rarely and inexplicably fails on other machines.

For me, I wouldn't hesitate for a moment to turn checks on that alert me 
of incorrect use of FX?-- I value my time, and bugs resulting from these 
threading problems can be very costly to track down. I already wrote my 
own check that scans for dead "nodes" (ie. nodes that were once part of 
a scene graph, but are no longer, but are still not being GC'd).

> Personally, I feel that it should be the first thing taught - always 
> call FX from the FX application thread.
>
Even Java collections will help you avoid threading problems by throwing 
ConcurrentModificationException.? Imagine a moment a world where this 
check did not exist, as it does cost some performance (a mod counter is 
increased on every collection modification):

- Concurrent access to things like HashMap and ArrayList would seem to 
work fine
- Sometimes randomly, an item goes missing, is overwritten or 
duplicated, or the code gets stuck in an infinite loop (these are all 
possible outcomes of concurrent collection access, as the check isn't 
perfect, so when you do see it, you must investigate thoroughly)
- The bug is reported (collection framework is buggy!)
- After analysis, culprit is that the user somewhere in their 100.000+ 
line code base is accessing a collection on different threads... sorry, 
we can't help you further.
- Except, they could help us further: ConcurrentModificationException 
was included at a slight cost of performance. It can't even be disabled 
(I'm not implying this was a later addition, the designers were just 
aware that this would lead to hard to track bugs and added this 
immediately).

The parallels with the FX threading model, and also with weak references 
are huge:

- Both "seem" to work fine, until they don't
- Failures are very random, may not occur at all on some setups (like 
the developer's), and failures can be subtle, deceiving or complete
- The bug is reported (FX doesn't even check for nulls in Scene code!)
- After analysis, culprit is (likely) that the user?somewhere in their 
100.000+ line code base is accessing the scene graph on different 
threads / forgot to maintain a hard reference... sorry, we can't help 
you further.

These kinds of mistakes are not just happening to beginners. This can 
happen when code gets rearranged, its original operating parameters long 
forgotten by you, or some future maintainer.? All it takes is a moment 
of inattention and you have a bug that you may never personally 
encounter, and when it does occur is impossible to reproduce with any 
certainty and does NOT give any indication of the cause (you see only 
symptoms).? Such bugs are the nastiest kind, and it is (IMHO) a failure 
of a framework to not help you detect these as early as possible.

--John


> I am curious what other members of community think of this issue.
>
> -andy
>
> *From: *John Hendrikx <john.hendrikx at gmail.com>
> *Date: *Wednesday, August 7, 2024 at 12:01
> *To: *Andy Goryachev <andy.goryachev at oracle.com>, 
> openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: Detecting threading problems faster
>
> Hi Andy,
>
> Problems that occur due to modifying the scene graph (like 
> adding/removing children, or changing certain properties) can be 
> incredibly subtle, and almost never point out the code that is the 
> actual culprit.? I suspect that the PR below is one of those for 
> example, but there are likely many more.
>
> https://github.com/openjdk/jfx/pull/1123 
> <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1123__;!!ACWV5N9M2RV99hQ!ILqOOB9ua4tDxfAV9pGPJJiQ3oXewiSQjH2BCsaQkhpgkHEQzT8hRQt2fb9mKjYbF24ZRpQwfEiELFvn4B28lBLwxrTE$>
>
> Issues that complain about some kind of odd bug in the FX code (like a 
> NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, 
> etc) could all be caused by user code doing things on the wrong 
> thread, but its really hard to diagnose as the stack traces provided 
> will never point out the user code that may be the culprit. I've 
> investigated PR 1123 extensively, and I can't see any bugs in the FX 
> code at all **assuming** it is used from a single thread...
>
> --John
>
> On 05/08/2024 17:01, Andy Goryachev wrote:
>
>     John:
>
>     Can you cite a bug or give an example of such a problem?
>
>     During all my time of actively using javafx (since about 2015) I
>     have never encountered an issue with threading you describe.? It
>     is possible that I use the system trivially and not to the full
>     extent. Both swing and javafx are single threaded by design.? Yes,
>     there might be occasions when one can use multiple threads and it
>     is sort of allowed, but doing so may lead to unpleasant issues
>     down the road, so the question is why would you want to do that?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx
>     <john.hendrikx at gmail.com> <mailto:john.hendrikx at gmail.com>
>     *Date: *Sunday, August 4, 2024 at 16:30
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Detecting threading problems faster
>
>     Hi list,
>
>     I know of quite some bugs and users that have been bitten by the
>     threading model used by JavaFX.? Basically, anything directly or
>     indirectly linked to an active Scene must be accessed on the FX
>     thread.
>     However, as FX also allows manipulating nodes and properties before
>     they're displayed, there can be no "hard" check everywhere to
>     ensure we
>     are on the FX thread (specifically, in properties).
>
>     Now, I think this situation is annoying, as a simple mistake where a
>     Platform.runLater wrapper was forgotten usually results in programs
>     operating mostly flawlessly, but then fail in mysterious and
>     random and
>     hard to reproduce ways.? The blame is often put on FX as the
>     resulting
>     exceptions will almost never show the user code which was the actual
>     culprit.? It can result in FX being perceived as unstable or buggy.
>
>     So I've been thinking if there isn't something we can do to detect
>     these
>     bugs originating from user code much earlier, similar to the
>     `ConcurrentModificationException` the collection classes do when
>     accessed in nested or concurrent contexts.
>
>     I think it may be possible to have properties check whether
>     they're part
>     of an active scene without too much of an performance impact,
>     possibly
>     even behind a switch. It would work like this:
>
>     Properties involved with Nodes will have an associated bean instance
>     (`getBean`).? This is an object, but we could check here if this
>     instance implements an interface:
>
>     ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
>     ??????????? if (x.isPartOfActiveScene() && !isOnFxThread()) {
>     ???????????????? throw new IllegalStateException("Property must
>     only be
>     used from the FX Application Thread");
>     ??????????? }
>     ????? }
>
>     This check could be done on every set of the property, and
>     potentially
>     on every get as well.? It should be relatively cheap, but will expose
>     problematic code patterns at a much earlier stage.? There's a chance
>     that this will "break" some programs that seemed to be behaving
>     correctly as well, so we may want to put it behind a switch until
>     such
>     programs (or libraries) can be fixed.
>
>     What do you all think?
>
>     --John
>
>     (*) Names of methods/interfaces are only used for illustration
>     purposes,
>     we can think of good names if this moves forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/f3ef4dc7/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Aug  7 22:12:59 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:12:59 +0000
Subject: [External] : Re: Detecting threading problems faster
In-Reply-To: <ec2d39b1-cd2b-4d7e-a2ad-8a44ae9cd56c@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <BL3PR10MB618510B72E0D43BFB5E09768E5BE2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e7d63cf3-b093-4581-b8ec-10c1e470bfaf@gmail.com>
 <BL3PR10MB6185925BBC662274988C48B0E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
 <ec2d39b1-cd2b-4d7e-a2ad-8a44ae9cd56c@gmail.com>
Message-ID: <BL3PR10MB6185D3FD0E004EEDF3B9DE68E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>

> > Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread.
> That does seem likely, but it is incredibly hard to be sure.
There is literally an exception logged from a non-FX thread, see here
https://github.com/openjdk/jfx/pull/1123#issuecomment-1535930576

:-)

But you do have a point in trying to save developers' time.  And, if we decide to hide the check behind a system property not enabled by default, we also avoid any risk of regression.

So the question is reduced to where we should put the check.  One such spot could be Parent.requestLayout(), since pretty much any changes to the scene graph result in a layout request.

Another possibility we can consider is to create a special convenience class for background processing, along the lines of SwingWorker.  For example, it could extend Runnable, have utility methods to runAndWait(), and launch itself in a Thread or (later) in a virtual thread.  This way the app devs can stop worrying and simply move any kind of background processing to the instances of these classes.  Just a thought.

-andy


From: John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, August 7, 2024 at 14:53
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: [External] : Re: Detecting threading problems faster

On 07/08/2024 21:38, Andy Goryachev wrote:
John:

Looks like the issue in PR#1123 was caused by application code accessing FX from a non-FX thread.
That does seem likely, but it is incredibly hard to be sure.


I know the discussion is about trying to detect thread misuse early on, as a way to help the application developers.  I vaguely recall the discussion we had at some point about adding the check to property invalidation code or some such, and the general consensus was that it might pose a compatibility risk or something along these lines.

Perhaps there is a place where such a check might be safely made (I don't know of any such place though)?   We did, after all, step on the path of simplification (?) for the sake of students (see https://openjdk.org/jeps/445 ).  Perhaps such a check could be hidden behind a system property so as not to break existing, if poorly written, applications.

I agree that we should be careful not to break anything, it is a check, but I also think that most developers will want this check on (but probably not by default initially, but definitely **after** they fixed any mistakes it detected to avoid recurrence). There is nothing worse than code that only rarely and inexplicably fails on other machines.

For me, I wouldn't hesitate for a moment to turn checks on that alert me of incorrect use of FX -- I value my time, and bugs resulting from these threading problems can be very costly to track down. I already wrote my own check that scans for dead "nodes" (ie. nodes that were once part of a scene graph, but are no longer, but are still not being GC'd).

Personally, I feel that it should be the first thing taught - always call FX from the FX application thread.
Even Java collections will help you avoid threading problems by throwing ConcurrentModificationException.  Imagine a moment a world where this check did not exist, as it does cost some performance (a mod counter is increased on every collection modification):

- Concurrent access to things like HashMap and ArrayList would seem to work fine
- Sometimes randomly, an item goes missing, is overwritten or duplicated, or the code gets stuck in an infinite loop (these are all possible outcomes of concurrent collection access, as the check isn't perfect, so when you do see it, you must investigate thoroughly)
- The bug is reported (collection framework is buggy!)
- After analysis, culprit is that the user somewhere in their 100.000+ line code base is accessing a collection on different threads... sorry, we can't help you further.
- Except, they could help us further: ConcurrentModificationException was included at a slight cost of performance. It can't even be disabled (I'm not implying this was a later addition, the designers were just aware that this would lead to hard to track bugs and added this immediately).

The parallels with the FX threading model, and also with weak references are huge:

- Both "seem" to work fine, until they don't
- Failures are very random, may not occur at all on some setups (like the developer's), and failures can be subtle, deceiving or complete
- The bug is reported (FX doesn't even check for nulls in Scene code!)
- After analysis, culprit is (likely) that the user somewhere in their 100.000+ line code base is accessing the scene graph on different threads / forgot to maintain a hard reference... sorry, we can't help you further.

These kinds of mistakes are not just happening to beginners.  This can happen when code gets rearranged, its original operating parameters long forgotten by you, or some future maintainer.  All it takes is a moment of inattention and you have a bug that you may never personally encounter, and when it does occur is impossible to reproduce with any certainty and does NOT give any indication of the cause (you see only symptoms).  Such bugs are the nastiest kind, and it is (IMHO) a failure of a framework to not help you detect these as early as possible.

--John



I am curious what other members of community think of this issue.

-andy




From: John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Wednesday, August 7, 2024 at 12:01
To: Andy Goryachev <andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com>, openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: [External] : Re: Detecting threading problems faster

Hi Andy,

Problems that occur due to modifying the scene graph (like adding/removing children, or changing certain properties) can be incredibly subtle, and almost never point out the code that is the actual culprit.  I suspect that the PR below is one of those for example, but there are likely many more.

https://github.com/openjdk/jfx/pull/1123<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1123__;!!ACWV5N9M2RV99hQ!ILqOOB9ua4tDxfAV9pGPJJiQ3oXewiSQjH2BCsaQkhpgkHEQzT8hRQt2fb9mKjYbF24ZRpQwfEiELFvn4B28lBLwxrTE$>

Issues that complain about some kind of odd bug in the FX code (like a NPE, ConcurrentModificationException, ArrayIndexOutOfBoundsException, etc) could all be caused by user code doing things on the wrong thread, but its really hard to diagnose as the stack traces provided will never point out the user code that may be the culprit.  I've investigated PR 1123 extensively, and I can't see any bugs in the FX code at all **assuming** it is used from a single thread...

--John
On 05/08/2024 17:01, Andy Goryachev wrote:
John:

Can you cite a bug or give an example of such a problem?

During all my time of actively using javafx (since about 2015) I have never encountered an issue with threading you describe.  It is possible that I use the system trivially and not to the full extent.  Both swing and javafx are single threaded by design.  Yes, there might be occasions when one can use multiple threads and it is sort of allowed, but doing so may lead to unpleasant issues down the road, so the question is why would you want to do that?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Sunday, August 4, 2024 at 16:30
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Detecting threading problems faster
Hi list,

I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX.  Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displayed, there can be no "hard" check everywhere to ensure we
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a
Platform.runLater wrapper was forgotten usually results in programs
operating mostly flawlessly, but then fail in mysterious and random and
hard to reproduce ways.  The blame is often put on FX as the resulting
exceptions will almost never show the user code which was the actual
culprit.  It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these
bugs originating from user code much earlier, similar to the
`ConcurrentModificationException` the collection classes do when
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part
of an active scene without too much of an performance impact, possibly
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance
(`getBean`).  This is an object, but we could check here if this
instance implements an interface:

      if (getBean() instanceof MayBePartOfSceneGraph x) {
            if (x.isPartOfActiveScene() && !isOnFxThread()) {
                 throw new IllegalStateException("Property must only be
used from the FX Application Thread");
            }
      }

This check could be done on every set of the property, and potentially
on every get as well.  It should be relatively cheap, but will expose
problematic code patterns at a much earlier stage.  There's a chance
that this will "break" some programs that seemed to be behaving
correctly as well, so we may want to put it behind a switch until such
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes,
we can think of good names if this moves forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240807/d3cb3fb8/attachment-0001.htm>

From angorya at openjdk.org  Wed Aug  7 22:19:44 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:19:44 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
Message-ID: <xfWqjwUmHKPV5ZvGrTBkgKO9noUkxQvB7ZHTAsbPSsc=.7f620528-7db4-491b-8199-f606cc65cf1e@github.com>

On Wed, 7 Aug 2024 20:03:17 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   interpolate integers in real number space

Just wanted to mention that so far my testing using the Monkey Tester look good - the behavior is as expected (except for interpolating colors which does not use the _right_ algorithm, but that's a different issue).

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274441851

From angorya at openjdk.org  Wed Aug  7 22:28:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:28:02 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor
 ActionEvent is consumed
Message-ID: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>

Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.

This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.

The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

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

Commit messages:
 - only if consumed
 - only when consumed
 - propagate
 - cleanup
 - simpler
 - event helper
 - copy for test
 - propagate consume action

Changes: https://git.openjdk.org/jfx/pull/1523/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337246
  Stats: 117 lines in 4 files changed: 102 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/jfx/pull/1523

From angorya at openjdk.org  Wed Aug  7 22:42:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:42:38 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
Message-ID: <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>

On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

this PR has been out for too long, could you please merge the latest master branch in?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 106:

> 104:              */
> 105: 
> 106:             is.readByte();

should we still check the value and throw an IOE if it is wrong _for security reasons_?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111:

> 109:         }
> 110: 
> 111:         int nRelationships = is.readShort();

same here: should we check for a positive value?

as a general rule, we should be validating the input as it might come from untrusted sources, right?  L79 and other places?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 126:

> 124:             else {
> 125:                 assert false : "error deserializing CompoundSelector: Combinator = " + ordinal;
> 126:                 relationships.add(Combinator.DESCENDANT);

throw an exception instead?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSelector.java line 75:

> 73:     /**
> 74:      * The relationships between the selectors
> 75:      * @return Immutable List&lt;Combinator&gt;

minor: would {@code List<Combinator>} be a better choice here, if it works?

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

PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2226298430
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708023638
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708025694
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708026625
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708029774

From jhendrikx at openjdk.org  Wed Aug  7 22:50:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 22:50:39 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
Message-ID: <O4Ump0QHUMw5gQMCgtdV-BZ0ZPRPL2FsDNStAWlwpdg=.3b2aed61-8d66-42e5-b5ab-1a4a4874c076@github.com>

On Wed, 7 Aug 2024 22:40:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> this PR has been out for too long, could you please merge the latest master branch in?

I did yesterday, or did something go wrong?

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111:
> 
>> 109:         }
>> 110: 
>> 111:         int nRelationships = is.readShort();
> 
> same here: should we check for a positive value?
> 
> as a general rule, we should be validating the input as it might come from untrusted sources, right?  L79 and other places?

I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR.  For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop.  If I add a check, it will change the behavior.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 126:
> 
>> 124:             else {
>> 125:                 assert false : "error deserializing CompoundSelector: Combinator = " + ordinal;
>> 126:                 relationships.add(Combinator.DESCENDANT);
> 
> throw an exception instead?

This is original code, just moved.  Do you want me to change it still?

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2274473668
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708049742
PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708047126

From angorya at openjdk.org  Wed Aug  7 22:50:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:50:40 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
Message-ID: <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>

On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

oops, yes, you did, my mistake.  the master progressed since then, got me confused.

I got a bunch of errors again after switching:


Description	Resource	Type	Path	Location
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3024
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3214
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3267
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3282
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3607
Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3651

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2274476433

From angorya at openjdk.org  Wed Aug  7 22:56:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 7 Aug 2024 22:56:41 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <O4Ump0QHUMw5gQMCgtdV-BZ0ZPRPL2FsDNStAWlwpdg=.3b2aed61-8d66-42e5-b5ab-1a4a4874c076@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
 <O4Ump0QHUMw5gQMCgtdV-BZ0ZPRPL2FsDNStAWlwpdg=.3b2aed61-8d66-42e5-b5ab-1a4a4874c076@github.com>
Message-ID: <CTgMWFskqRn7h5waA9N5QlFrq_sDLkWyFSR0qALMuHo=.448f317c-6699-4802-89b0-d3fe713cb52f@github.com>

On Wed, 7 Aug 2024 22:48:07 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 111:
>> 
>>> 109:         }
>>> 110: 
>>> 111:         int nRelationships = is.readShort();
>> 
>> same here: should we check for a positive value?
>> 
>> as a general rule, we should be validating the input as it might come from untrusted sources, right?  L79 and other places?
>
> I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR.  For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop.  If I add a check, it will change the behavior.

Well, we could create a separate ticket.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708057352

From jhendrikx at openjdk.org  Wed Aug  7 23:01:36 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 23:01:36 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
Message-ID: <DZYtD6xmcbHNnd9N7crWcZKwiOil2Ofe6y6eoQzkGt8=.22e0bc3a-2469-436e-8882-b1470172ef77@github.com>

On Wed, 7 Aug 2024 22:27:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 106:
> 
>> 104:              */
>> 105: 
>> 106:             is.readByte();
> 
> should we still check the value and throw an IOE if it is wrong _for security reasons_?

I'm not entirely sure what security reasons you may be referring to; we're not instantiating classes by string for example, and Java doesn't suffer from out of bounds memory accesses due to a bad interpretation of a binary format.

However, this code is a bit more lenient than the original.  The original code would deserialize this as a `CompoundSelector` but then subsequently fail with a `ClassCastException` as it assumes it will be a `SimpleSelector`. I could make it fully compatible in this regard, although it is extremely unlikely that there are any bad files out there where this would apply (as the old implementation would never load it).

Anyway, I'm fine with rejecting values that are not `TYPE_SIMPLE`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708062962

From jhendrikx at openjdk.org  Wed Aug  7 23:09:40 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 7 Aug 2024 23:09:40 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <CTgMWFskqRn7h5waA9N5QlFrq_sDLkWyFSR0qALMuHo=.448f317c-6699-4802-89b0-d3fe713cb52f@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
 <O4Ump0QHUMw5gQMCgtdV-BZ0ZPRPL2FsDNStAWlwpdg=.3b2aed61-8d66-42e5-b5ab-1a4a4874c076@github.com>
 <CTgMWFskqRn7h5waA9N5QlFrq_sDLkWyFSR0qALMuHo=.448f317c-6699-4802-89b0-d3fe713cb52f@github.com>
Message-ID: <04-gHGslUPwHc1LplzCXEUcwSi-J63hiSyZczM-D_u4=.6d502dbe-7896-486b-8915-9c97320e57de@github.com>

On Wed, 7 Aug 2024 22:54:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I considered doing more here, but as this is all just moved code, I'm hesitant to change it as part of this PR.  For example, if there is a faulty binary CSS file which has a negative value for the short, then the original code will just skip the loop.  If I add a check, it will change the behavior.
>
> Well, we could create a separate ticket.

I already cleaned it up without altering the behavior.  It probably isn't worth investing more time in.  The whole binary CSS code is AFAICS basically only used to create binary versions of the FX standard css files, like `modena.css`, by calling the main method of `Css2Bin` during the gradle build.  This probably saves some time for JavaFX startup as the binary version will load faster than the text versions (or so I hope, I didn't check if that's true).  I have doubts it is used anywhere else, so although this has creeped into a few public API's, it's practically for internal use only.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1708072735

From mstrauss at openjdk.org  Wed Aug  7 23:46:54 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 23:46:54 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v20]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <A4dvoinYO5mmPRHcXxQ2kJFEbel9KSSIE7MrZxUnNNw=.1a0c6475-9944-43c1-8118-096171279d84@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  replace reconstruction annotation with interface

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/c36c6c05..03c54965

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=18-19

  Stats: 56 lines in 6 files changed: 17 ins; 23 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Wed Aug  7 23:58:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 7 Aug 2024 23:58:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
Message-ID: <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>

On Wed, 7 Aug 2024 20:58:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I just saw a boolean variable being instantiated from an annotation and thought "why jump through the multiple hoops?".  since there is a boolean, why not pass it directly?
>> 
>> it's less about memory allocation (though I would prefer to minimize that as well, but as @hjohn pointed out the difference is just a few bytes), but more about "entities must not be multiplied beyond necessity".
>
> Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well.
> 
> There seem to be a couple of general approaches:
> 
> 1. Have a marker that can be checked from the outside
>     - Annotation (checked from the outside)
>         - Unusual for this kind of check
>     - Marker interface
>         - Seen more often, but unusual to not put the new method there
>     - Subtype 
>         - Bad idea, you can only inherit once
> 2. Introduce a new interface with the new method
>     - Defines the method and serves as the marker at the same time
> 3. Have a method that can be called that guards a 2nd method call
>     - Doesn't matter how this is fed (constructor, annotation, override)
>         -  You see this more often, but it's not a great pattern (2 method calls for the price of one...)
> 4. Return a special value from a method that may be unsupported
>     - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support
>     - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix)
>     - Return `null`
> 
> Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9.  Even though it may not be the prettiest solution, it has two things going for it:
> 
> - It's fast (probably the fastest of the above options, although for most by just a slim margin)
> - It fits in with the existing design
> 
> So, my order of preference:
> - Just return `null`
> - A new interface, which includes the new method
> - A marker only interface
> - A supportsXYZ method (regardless of how that is approached)
> 
> I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly.

Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either:
1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason.
2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition).

Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods:

public interface WithReconstructionSupport<T> {
    T convert(Map<CssMetaData<? extends Styleable, ?>, Object> values);
    Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);
}


This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1708139444

From mstrauss at openjdk.org  Thu Aug  8 00:10:59 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 Aug 2024 00:10:59 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v21]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <Ra0KeDY_VYm8-rj_FuwVsoEAH5j9lLgUlO9sonvGFgI=.3ceb6cd9-b416-4750-9ea2-3d1bf9c34675@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  add more documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/03c54965..2bc00001

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=19-20

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Thu Aug  8 01:47:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 Aug 2024 01:47:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <yTEMUbOdGOCA8e5V7ekFJvccY8X6Xav6Lk1PuFqueqw=.4e323345-bcd8-46f1-be6e-90971e1408f6@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
 <yTEMUbOdGOCA8e5V7ekFJvccY8X6Xav6Lk1PuFqueqw=.4e323345-bcd8-46f1-be6e-90971e1408f6@github.com>
Message-ID: <ueKRW89TarU2sZZOPIJ2ujmfW2RBoRycls89vzrS7zY=.9563e1b9-eb6e-4e2e-95c8-2723017937de@github.com>

On Wed, 7 Aug 2024 20:51:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Regarding `cssref.html`:
> 
> 1. I think it might make sense to add a section after "Transitions" talking about component transitions, maybe with examples.
> 2. I think we should to mention interpolation behavior next to each property name somehow.  Either mark the properties that do support it, or only those that do not support.  It is already documented in javadoc, but cssref.html is a normative document for CSS.
> 
> what do you think?

I'm not sure what to say here, and I question whether introducing the concept of component-wise transitions to users is useful at all. This is more of an implementation detail, as from the perspective of CSS (where transitions are specified), there is no such thing: the reason why you can target `-fx-border-color` with a transition is because the property type is `Paint`, which implements `Interpolatable`. The fact that `Interpolatable` types support transitions is already mentioned in `cssref.html`; elaborating on terminology that has no further use in CSS might be even more confusing for users.

There shouldn't be any need to either document support or non-support with regards to transitions, because the current language is already clear that if the property is not `Interpolatable`, there will be no transition.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2274773280

From mstrauss at openjdk.org  Thu Aug  8 02:07:35 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 Aug 2024 02:07:35 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <kALzQmbrK2JJI6KRya1pY2sOwQVqysrr6YguzKTKwdk=.fc65b226-9420-466b-a524-1bcf9fdbfe47@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

I don't think that we should introduce functionality to the event system that is only accessible to controls shipped with JavaFX, but not to third-party controls. Either this is an important feature for control authors, then it should be accessible for third-party controls as well. Or it is not important, then it shouldn't be added in the first place.

In my opinion, `javafx.controls` shouldn't be a special citizen, but just a consumer of JavaFX APIs. I know that that is not the case right now, but let's not make the situation more entrenched than it currently is.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2274800328

From mstrauss at openjdk.org  Thu Aug  8 04:00:16 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 Aug 2024 04:00:16 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  only call get() when necessary

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/2bc00001..1abd6887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=21
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=20-21

  Stats: 31 lines in 1 file changed: 6 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From lkostyra at openjdk.org  Thu Aug  8 06:29:38 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 8 Aug 2024 06:29:38 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <HlQc5j4NyGe4L2zJAYm3eSP5MTRfx8iq71qLnds5UTE=.85ac9cc9-e631-4493-a538-0146d6eebcfc@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

LGTM, fixes the problem on Ubuntu 24.04. Noticed no regressions otherwise.

I did see some new test failures on 24.04, but these don't go away after this patch. Must be some different reason for them.

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1520#pullrequestreview-2226961754

From craigraw at gmail.com  Thu Aug  8 09:19:13 2024
From: craigraw at gmail.com (Craig Raw)
Date: Thu, 8 Aug 2024 11:19:13 +0200
Subject: Update on the headless platform (sandbox)
In-Reply-To: <CABxFH2EgPYLt=HRyvfDtuAeqoobvdFd3z2kyDkqNOszTcaf+Cw@mail.gmail.com>
References: <CABxFH2EgPYLt=HRyvfDtuAeqoobvdFd3z2kyDkqNOszTcaf+Cw@mail.gmail.com>
Message-ID: <CAPR5oBP9qU56qkFf+T5zSXUtk=J5D8_xJtJQOhRVXMv7uK5AjA@mail.gmail.com>

Hi,

Is there any progress update on this? It appears (I may be wrong) to be a
low risk addition to JavaFX, but with significant benefits, particularly as
Monocle is no longer part of JavaFX builds.

Thanks,
Craig

On Thu, Apr 25, 2024 at 12:49?PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> I did some more work on the JavaFX Headless platform that is available in
> [1] and I am using it to run the systemtests. I am not yet running the
> robot-based systemtests, but there is already some robot code in the
> Headless platform.
>
> The other systemtests are going pretty well. On my linux,
>
> export _JAVA_OPTIONS="-Dglass.platform=Headless"
> sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest :systemTests:test
>
> is currently returning
> 552 tests completed, 3 failed, 24 skipped
>
> I understand why the 3 failed tests are failing, and I will move to
> robot-based tests soon.
>
> [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240808/fb8853c6/attachment.htm>

From thiago.sayao at gmail.com  Thu Aug  8 10:47:35 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 8 Aug 2024 07:47:35 -0300
Subject: Detecting threading problems faster
In-Reply-To: <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
 <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
 <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>
Message-ID: <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>

Nice! I will steal it if you don't mind.

Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx <john.hendrikx at gmail.com>
escreveu:

> For detecting long running tasks on the FX thread, there are some other
> options which you can do as a user (but perhaps we can support it directly
> within FX).  I use this kind of code to detect long running things on the
> FX thread:
>
> /**
>
> * Adds a slow event warning whenever an event takes more than 10 ms to
> process. Note
>
> * that time spent in nested event loops cannot be properly taken into
> account as time
>
> * spent in nested event loops will be part of the event that triggered it
> giving false
>
> * positives. In order for this time to be accurately reflected, the
> methods to enter
>
> * a nested event loop in this class should be used instead of the ones in {@link
> Platform}.
>
> *
>
> * @param scene a Scene to which to add the slow event warning detection,
> cannot be null
>
> */
>
> public static void addSlowEventWarning(Scene scene) {
>
> final EventDispatcher eventDispatcher = scene.getEventDispatcher();
>
> scene.setEventDispatcher(new EventDispatcher() {
>
> private ScheduledFuture<StackTraceElement[]> future;
>
> @Override
>
> public Event dispatchEvent(Event event, EventDispatchChain tail) {
>
> if(future != null) {
>
> future.cancel(false);
>
> }
>
> long startTime = System.currentTimeMillis();
>
> TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways,
> an event triggering another event, or when a nested event loop is entered
>
> Event returnedEvent = eventDispatcher.dispatchEvent(event, tail);
>
> long endTime = System.currentTimeMillis();
>
> long timeSpentInNested = TIME_TRACKER.exitNested(endTime);
>
> if(timeSpentInNested > 10) {
>
> long total = endTime - startTime;
>
> LOGGER.warning("Slow Event (self/total: " + timeSpentInNested + "/" +
> total + " ms @ level " + TIME_TRACKER.getCurrentLevel() + "): " + event);
>
> }
>
> return returnedEvent;
>
> }
>
> });
>
> }
>
> --John
>
> On 05/08/2024 17:17, Thiago Milczarek Say?o wrote:
>
> Hi,
>
> Interesting idea. We have this problem specially when Junior developers
> touch the code.
>
> The other way around would be nice too - if some I/O task executes on the
> FX thread.
>
> This can make the OS think the application hanged and offer to kill it,
> since it won't respond to "pings". And I/O tasks processing time may vary
> between installations. Also causes "white screens" since it blocks painting.
>
> -- Thiago.
>
> Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth <
> kevin.rushforth at oracle.com> escreveu:
>
>> Wouldn't it be better to implement this check in assert to avoid any
>> impact in production?
>>
>>
>> No. Using an assert in a case like this is an anti-pattern. A call to
>> assert in a library such as JavaFX is only appropriate for checking an
>> invariant in internal logic. If we are going to go down this route of doing
>> a thread check when mutating properties of "live" nodes, we will throw the
>> same IllegalStateException that is currently thrown by some methods on
>> Stage and Scene.
>>
>> As for the proposal itself, adding this check is an interesting idea. We
>> considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided
>> not to pursue it then. I think the idea is worth further discussion. I
>> would limit any thread checking to setting the property. It would be too
>> restrictive (and largely unnecessary) to prevent reading a property from
>> the application thread.
>>
>> The things to consider would be:
>>
>> 1. What is the performance hit of doing this check on the setting of
>> every property?
>> 2. What is the effect on bound properties?
>> 3. How intrusive is it in the code?
>> 4. Should we add a property to enable / disable the thread check,
>> possibly a three- or four-valued property (allow|warn|debug?|deny), as was
>> recently done in JEP 471 for sun.misc.Unsafe memory access methods. If so,
>> what should the default be?
>>
>> My quick take is that if this can be done in a minimally intrusive manner
>> with low overhead, we should consider pursing this. As for 4, my preference
>> would be to add a three- or four-valued system property to control the
>> check, with "warn" as the default initially, changing the default to
>> "disallow" in a subsequent version. This would, of course, require a lot of
>> testing.
>>
>> -- Kevin
>>
>>
>> On 8/4/2024 8:40 PM, quizynox wrote:
>>
>> Hello,
>>
>> Wouldn't it be better to implement this check in assert to avoid any
>> impact in production?
>>
>> ??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com>:
>>
>>> Hi list,
>>>
>>> I know of quite some bugs and users that have been bitten by the
>>> threading model used by JavaFX.  Basically, anything directly or
>>> indirectly linked to an active Scene must be accessed on the FX thread.
>>> However, as FX also allows manipulating nodes and properties before
>>> they're displayed, there can be no "hard" check everywhere to ensure we
>>> are on the FX thread (specifically, in properties).
>>>
>>> Now, I think this situation is annoying, as a simple mistake where a
>>> Platform.runLater wrapper was forgotten usually results in programs
>>> operating mostly flawlessly, but then fail in mysterious and random and
>>> hard to reproduce ways.  The blame is often put on FX as the resulting
>>> exceptions will almost never show the user code which was the actual
>>> culprit.  It can result in FX being perceived as unstable or buggy.
>>>
>>> So I've been thinking if there isn't something we can do to detect these
>>> bugs originating from user code much earlier, similar to the
>>> `ConcurrentModificationException` the collection classes do when
>>> accessed in nested or concurrent contexts.
>>>
>>> I think it may be possible to have properties check whether they're part
>>> of an active scene without too much of an performance impact, possibly
>>> even behind a switch. It would work like this:
>>>
>>> Properties involved with Nodes will have an associated bean instance
>>> (`getBean`).  This is an object, but we could check here if this
>>> instance implements an interface:
>>>
>>>       if (getBean() instanceof MayBePartOfSceneGraph x) {
>>>             if (x.isPartOfActiveScene() && !isOnFxThread()) {
>>>                  throw new IllegalStateException("Property must only be
>>> used from the FX Application Thread");
>>>             }
>>>       }
>>>
>>> This check could be done on every set of the property, and potentially
>>> on every get as well.  It should be relatively cheap, but will expose
>>> problematic code patterns at a much earlier stage.  There's a chance
>>> that this will "break" some programs that seemed to be behaving
>>> correctly as well, so we may want to put it behind a switch until such
>>> programs (or libraries) can be fixed.
>>>
>>> What do you all think?
>>>
>>> --John
>>>
>>> (*) Names of methods/interfaces are only used for illustration purposes,
>>> we can think of good names if this moves forward.
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240808/60acd50b/attachment-0001.htm>

From lkostyra at openjdk.org  Thu Aug  8 12:42:07 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 8 Aug 2024 12:42:07 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image
Message-ID: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>

When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.

This change fixes this mistake. Now drag image should be properly offset.

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

Commit messages:
 - GlassViewDelegate: Restore offset calculation on startDrag

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

PR: https://git.openjdk.org/jfx/pull/1532

From lkostyra at openjdk.org  Thu Aug  8 12:42:07 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 8 Aug 2024 12:42:07 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <UyaVqGlFomQovA07QiRiMEbgrWhk0FVT0-j5dqKTeqM=.f3f51d20-01fa-4b32-b447-3203ebbb1274@github.com>

On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

I have one more question to this, as I don't have the best way to test this. I'm not sure how offsets should be interpreted and if they are interpreted the right way.

At this point:
* For X offset: positive values shift image RIGHT (mouse cursor is closer to the LEFT side of drag image), negative shift LEFT (mouse cursor is closer to the RIGHT side of drag image)
* For Y offset: positive values shift image DOWN (mouse cursor is closer to the TOP of the drag image), negative values shift UP (mouse cursor is closer to the BOTTOM of the drag image)

Let me know if this behavior is desired and if it matches pre-[JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2275721478

From arapte at openjdk.org  Thu Aug  8 13:47:36 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 8 Aug 2024 13:47:36 GMT
Subject: RFR: 8336624: Improve Decora Shader loading for modern APIs
In-Reply-To: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
References: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
Message-ID: <nUE4_LH6jEqM0X3aPF4VqrB5ewHXJCLCvnpsa7zmwWo=.5cf558b6-9e33-48eb-ac15-703efe3eac95@github.com>

On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.
> 
> This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.
> 
> Both D3D and ES2 Prism backends were updated to properly handle these changes.
> 
> NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.
> 
> I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

The change seems quite straight forward, single reviewer should be sufficient.

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

PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2275873580

From lkostyra at openjdk.org  Thu Aug  8 13:51:38 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 8 Aug 2024 13:51:38 GMT
Subject: Integrated: 8336624: Improve Decora Shader loading for modern APIs
In-Reply-To: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
References: <yqSLmLKHpZ0ojE3ZqBwcaOnGIiEH9MysszWoQpXdSOM=.3ea02621-2dea-4fe5-a108-5ad880459722@github.com>
Message-ID: <oPMX3CwfISz22SokzwYTQOgznAmpmpon9RwppVKYwFA=.38050a1b-fa92-48cb-af10-f729859827ae@github.com>

On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.
> 
> This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.
> 
> Both D3D and ES2 Prism backends were updated to properly handle these changes.
> 
> NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.
> 
> I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

This pull request has now been integrated.

Changeset: abb6dfef
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/abb6dfefae840ac17893a12e4ac086140c83e451
Stats:     15 lines in 6 files changed: 5 ins; 0 del; 10 mod

8336624: Improve Decora Shader loading for modern APIs

Reviewed-by: arapte

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

PR: https://git.openjdk.org/jfx/pull/1530

From andy.goryachev at oracle.com  Thu Aug  8 14:25:48 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 8 Aug 2024 14:25:48 +0000
Subject: Detecting threading problems faster
In-Reply-To: <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
 <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
 <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>
 <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
Message-ID: <BL3PR10MB61855EC412A0AD45697491A6E5B92@BL3PR10MB6185.namprd10.prod.outlook.com>

One should probably use System.nanoTime() instead of .currentTimeMillis() ...

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Thursday, August 8, 2024 at 03:47
To: John Hendrikx <john.hendrikx at gmail.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Detecting threading problems faster
Nice! I will steal it if you don't mind.

Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>> escreveu:

For detecting long running tasks on the FX thread, there are some other options which you can do as a user (but perhaps we can support it directly within FX).  I use this kind of code to detect long running things on the FX thread:

/**

* Adds a slow event warning whenever an event takes more than 10 ms to process. Note

* that time spent in nested event loops cannot be properly taken into account as time

* spent in nested event loops will be part of the event that triggered it giving false

* positives. In order for this time to be accurately reflected, the methods to enter

* a nested event loop in this class should be used instead of the ones in {@link Platform}.

*

* @param scene a Scene to which to add the slow event warning detection, cannot be null

*/

public static void addSlowEventWarning(Scene scene) {

final EventDispatcher eventDispatcher = scene.getEventDispatcher();

scene.setEventDispatcher(new EventDispatcher() {

private ScheduledFuture<StackTraceElement[]> future;

@Override

public Event dispatchEvent(Event event, EventDispatchChain tail) {

if(future != null) {

future.cancel(false);

}

long startTime = System.currentTimeMillis();

TIME_TRACKER.enterNested(startTime); // nesting can happen in two ways, an event triggering another event, or when a nested event loop is entered

Event returnedEvent = eventDispatcher.dispatchEvent(event, tail);

long endTime = System.currentTimeMillis();

long timeSpentInNested = TIME_TRACKER.exitNested(endTime);

if(timeSpentInNested > 10) {

long total = endTime - startTime;

LOGGER.warning("Slow Event (self/total: " + timeSpentInNested + "/" + total + " ms @ level " + TIME_TRACKER.getCurrentLevel() + "): " + event);

}

return returnedEvent;

}

});

}

--John
On 05/08/2024 17:17, Thiago Milczarek Say?o wrote:
Hi,

Interesting idea. We have this problem specially when Junior developers touch the code.

The other way around would be nice too - if some I/O task executes on the FX thread.

This can make the OS think the application hanged and offer to kill it, since it won't respond to "pings". And I/O tasks processing time may vary between installations. Also causes "white screens" since it blocks painting.

-- Thiago.

Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth <kevin.rushforth at oracle.com<mailto:kevin.rushforth at oracle.com>> escreveu:
Wouldn't it be better to implement this check in assert to avoid any impact in production?

No. Using an assert in a case like this is an anti-pattern. A call to assert in a library such as JavaFX is only appropriate for checking an invariant in internal logic. If we are going to go down this route of doing a thread check when mutating properties of "live" nodes, we will throw the same IllegalStateException that is currently thrown by some methods on Stage and Scene.

As for the proposal itself, adding this check is an interesting idea. We considered doing this back in the JDK 7 (JavaFX 2) time frame, but decided not to pursue it then. I think the idea is worth further discussion. I would limit any thread checking to setting the property. It would be too restrictive (and largely unnecessary) to prevent reading a property from the application thread.

The things to consider would be:

1. What is the performance hit of doing this check on the setting of every property?
2. What is the effect on bound properties?
3. How intrusive is it in the code?
4. Should we add a property to enable / disable the thread check, possibly a three- or four-valued property (allow|warn|debug?|deny), as was recently done in JEP 471 for sun.misc.Unsafe memory access methods. If so, what should the default be?

My quick take is that if this can be done in a minimally intrusive manner with low overhead, we should consider pursing this. As for 4, my preference would be to add a three- or four-valued system property to control the check, with "warn" as the default initially, changing the default to "disallow" in a subsequent version. This would, of course, require a lot of testing.

-- Kevin

On 8/4/2024 8:40 PM, quizynox wrote:
Hello,

Wouldn't it be better to implement this check in assert to avoid any impact in production?

??, 5 ???. 2024??. ? 03:30, John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>>:
Hi list,

I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX.  Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displayed, there can be no "hard" check everywhere to ensure we
are on the FX thread (specifically, in properties).

Now, I think this situation is annoying, as a simple mistake where a
Platform.runLater wrapper was forgotten usually results in programs
operating mostly flawlessly, but then fail in mysterious and random and
hard to reproduce ways.  The blame is often put on FX as the resulting
exceptions will almost never show the user code which was the actual
culprit.  It can result in FX being perceived as unstable or buggy.

So I've been thinking if there isn't something we can do to detect these
bugs originating from user code much earlier, similar to the
`ConcurrentModificationException` the collection classes do when
accessed in nested or concurrent contexts.

I think it may be possible to have properties check whether they're part
of an active scene without too much of an performance impact, possibly
even behind a switch. It would work like this:

Properties involved with Nodes will have an associated bean instance
(`getBean`).  This is an object, but we could check here if this
instance implements an interface:

      if (getBean() instanceof MayBePartOfSceneGraph x) {
            if (x.isPartOfActiveScene() && !isOnFxThread()) {
                 throw new IllegalStateException("Property must only be
used from the FX Application Thread");
            }
      }

This check could be done on every set of the property, and potentially
on every get as well.  It should be relatively cheap, but will expose
problematic code patterns at a much earlier stage.  There's a chance
that this will "break" some programs that seemed to be behaving
correctly as well, so we may want to put it behind a switch until such
programs (or libraries) can be fixed.

What do you all think?

--John

(*) Names of methods/interfaces are only used for illustration purposes,
we can think of good names if this moves forward.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240808/3df44dc7/attachment-0001.htm>

From johan.vos at gluonhq.com  Thu Aug  8 15:37:57 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 8 Aug 2024 16:37:57 +0100
Subject: Update on the headless platform (sandbox)
In-Reply-To: <CAPR5oBP9qU56qkFf+T5zSXUtk=J5D8_xJtJQOhRVXMv7uK5AjA@mail.gmail.com>
References: <CABxFH2EgPYLt=HRyvfDtuAeqoobvdFd3z2kyDkqNOszTcaf+Cw@mail.gmail.com>
 <CAPR5oBP9qU56qkFf+T5zSXUtk=J5D8_xJtJQOhRVXMv7uK5AjA@mail.gmail.com>
Message-ID: <CABxFH2Hj=ENxU3X0p0WvqGev361Cp3StVBkUbrBNrspBg4hXpw@mail.gmail.com>

Hi Craig,

There were 3 system tests that were still failing, and once I fixed those,
I believe this is ready to be reviewed. I'm out of office until end of next
week, and I plan to resume work on that soon after that.

- Johan

On Thu, Aug 8, 2024 at 10:19?AM Craig Raw <craigraw at gmail.com> wrote:

> Hi,
>
> Is there any progress update on this? It appears (I may be wrong) to be a
> low risk addition to JavaFX, but with significant benefits, particularly as
> Monocle is no longer part of JavaFX builds.
>
> Thanks,
> Craig
>
> On Thu, Apr 25, 2024 at 12:49?PM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Hi,
>>
>> I did some more work on the JavaFX Headless platform that is available in
>> [1] and I am using it to run the systemtests. I am not yet running the
>> robot-based systemtests, but there is already some robot code in the
>> Headless platform.
>>
>> The other systemtests are going pretty well. On my linux,
>>
>> export _JAVA_OPTIONS="-Dglass.platform=Headless"
>> sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest
>> :systemTests:test
>>
>> is currently returning
>> 552 tests completed, 3 failed, 24 skipped
>>
>> I understand why the 3 failed tests are failing, and I will move to
>> robot-based tests soon.
>>
>> [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240808/7ec1507e/attachment.htm>

From angorya at openjdk.org  Thu Aug  8 15:41:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 15:41:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <ueKRW89TarU2sZZOPIJ2ujmfW2RBoRycls89vzrS7zY=.9563e1b9-eb6e-4e2e-95c8-2723017937de@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
 <yTEMUbOdGOCA8e5V7ekFJvccY8X6Xav6Lk1PuFqueqw=.4e323345-bcd8-46f1-be6e-90971e1408f6@github.com>
 <ueKRW89TarU2sZZOPIJ2ujmfW2RBoRycls89vzrS7zY=.9563e1b9-eb6e-4e2e-95c8-2723017937de@github.com>
Message-ID: <F6iLHlWmL8jPhm7SY9MQTZpRTwGIFQp4LW2FLR3nRYo=.1e844991-8288-4ab9-90f6-89bb6f219e8f@github.com>

On Thu, 8 Aug 2024 01:44:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> the current language is already clear that if the property is not `Interpolatable`, there will be no transition.

I am talking about `cssref.html` and not the code.  One should be able to see whether a property is interpolatable from reading the `cssref.html` spec without having to dig into the code.

The word "interpolatable" occurs in `cssref.html` in exactly one place.  What I think the reader should be able to do is to find out whether a property is interpolatable from reading the section about said property in `cssref.html`.

In other words, there should be info about interpolation in the property table:
![Screenshot 2024-08-08 at 08 29 32](https://github.com/user-attachments/assets/cf43ce83-0cb0-43ff-b782-18ac67af1c11)

Since probably most of the properties are "interpolatable" we can mention that the particular property does not support interpolation instead.

Another example: until [JDK-8338002](https://bugs.openjdk.org/browse/JDK-8338002) is implemented, -fx-font* interpolates discretely, which should be reflected in the css spec.

Or am I missing something?

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2276130402

From angorya at openjdk.org  Thu Aug  8 15:48:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 15:48:45 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
Message-ID: <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-UahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>

On Wed, 7 Aug 2024 23:55:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Although I'm not advocating for a specific change, I think looking at how `T convert(Map)` works when it was newly introduced in Java 9 should be taken into account as well.
>> 
>> There seem to be a couple of general approaches:
>> 
>> 1. Have a marker that can be checked from the outside
>>     - Annotation (checked from the outside)
>>         - Unusual for this kind of check
>>     - Marker interface
>>         - Seen more often, but unusual to not put the new method there
>>     - Subtype 
>>         - Bad idea, you can only inherit once
>> 2. Introduce a new interface with the new method
>>     - Defines the method and serves as the marker at the same time
>> 3. Have a method that can be called that guards a 2nd method call
>>     - Doesn't matter how this is fed (constructor, annotation, override)
>>         -  You see this more often, but it's not a great pattern (2 method calls for the price of one...)
>> 4. Return a special value from a method that may be unsupported
>>     - The most obvious (modern) candidate is to return `Optional` but is a bit unusual to indicate support/non-support
>>     - Throw `UnsupportedOperationException` -- although standard, I think it indicates a programmer mistake that should be avoided (in other words, encountering this exception in production code should result in a code fix)
>>     - Return `null`
>> 
>> Now the very last option (returning `null`) was the way this was handled when `T convert(Map)` was introduced in Java 9.  Even though it may not be the prettiest solution, it has two things going for it:
>> 
>> - It's fast (probably the fastest of the above options, although for most by just a slim margin)
>> - It fits in with the existing design
>> 
>> So, my order of preference:
>> - Just return `null`
>> - A new interface, which includes the new method
>> - A marker only interface
>> - A supportsXYZ method (regardless of how that is approached)
>> 
>> I don't think I could get behind any of the other options, because they either stick out like a sore thumb versus the existing design, limit future options or just perform too poorly.
>
> Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either:
> 1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason.
> 2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition).
> 
> Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods:
> 
> public interface WithReconstructionSupport<T> {
>     T convert(Map<CssMetaData<? extends Styleable, ?>, Object> values);
>     Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);
> }
> 
> 
> This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily.

+1 for `StyleConverter.WithReconstructionSupport`

maybe use a shorter name, like

`StyleConverter.WithReconstruction`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1709803243

From angorya at openjdk.org  Thu Aug  8 15:48:46 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 15:48:46 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
Message-ID: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com>

On Thu, 8 Aug 2024 04:00:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only call get() when necessary

modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113:

> 111:          * @return a {@code Map} of the constituent values
> 112:          */
> 113:         Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);

perhaps `convertToMap` might be better?  or something along the lines of `toInstance`/`toMap` ?   `decompose` / `reconstruct` ?  (though decompose might evoke wrong associations)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1709796311

From angorya at openjdk.org  Thu Aug  8 15:59:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 15:59:36 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <kALzQmbrK2JJI6KRya1pY2sOwQVqysrr6YguzKTKwdk=.fc65b226-9420-466b-a524-1bcf9fdbfe47@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <kALzQmbrK2JJI6KRya1pY2sOwQVqysrr6YguzKTKwdk=.fc65b226-9420-466b-a524-1bcf9fdbfe47@github.com>
Message-ID: <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com>

On Thu, 8 Aug 2024 02:04:32 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> but not to third-party controls

Does it mean you propose to make the `Event.propagateConsume()` method public?

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276162255

From mfox at openjdk.org  Thu Aug  8 15:59:36 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 8 Aug 2024 15:59:36 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276166334

From jpereda at openjdk.org  Thu Aug  8 16:04:36 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 8 Aug 2024 16:04:36 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <B3jI0euuBGk8P6xtgy46o_vDAYYYYRWiiauxAMJ58Us=.f2582bf6-285a-404e-b66f-94c8fe729b2b@github.com>

On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

I'm testing this PR, and I see that on macOS the offsets are now taken into account. 

However, comparing to Windows the behaviour is different:

- On Windows, offset 0,0 means the cursor is at the most top-left coordinates of the dragView image. Setting positive offsets in x, y goes to the right and down of the image (which goes in line with the usual JavaFX coordinate system)

- On macOS, with this PR, offset 0, 0 is at the centre of the dragView image, and positive offsets go to the opposite direction

>From the test attached to the issue, and with this PR:


WritableImage snapshot = source.snapshot(null, null);

db.setDragView(snapshot);
db.setDragViewOffsetX(0);

db.setDragViewOffsetY(0);

on Windows -> cursor at the most top-left corner of the dragView
on macOS -> cursor at the centre of the dragView.

And:

WritableImage snapshot = source.snapshot(null, null);

db.setDragView(snapshot);
db.setDragViewOffsetX(snapshot.getWidth() / 2);

db.setDragViewOffsetY(snapshot.getHeight() / 2);

on Windows -> cursor at the centre of the dragView
on macOS -> cursor at the most top-left corner of the dragView.

So I'd say macOS should do the same as Windows, and for that you could try:

-            dragPoint.x -= ([image size].width/2.0f);
-            dragPoint.y -= ([image size].height/2.0f);
+            // dragPoint.x -= ([image size].width/2.0f);
+            // dragPoint.y -= ([image size].height/2.0f);

-                dragPoint.x += offset.x;
-               dragPoint.y += offset.y;
+               dragPoint.x -= offset.x;
+               dragPoint.y -= offset.y;


Does that make sense to you?

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2276175583

From mstrauss at openjdk.org  Thu Aug  8 16:15:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 8 Aug 2024 16:15:42 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <kALzQmbrK2JJI6KRya1pY2sOwQVqysrr6YguzKTKwdk=.fc65b226-9420-466b-a524-1bcf9fdbfe47@github.com>
 <8R6B76rdIfBpIuU8MMeacMPr2BEPvB14rXEvwcknoDY=.11537e34-f9f5-4102-a960-9e3f472a886b@github.com>
Message-ID: <DyogBUBgZjWt4f_R5usG4uPPxBtx9Ri8LyAoG2pS2NE=.90e916a2-0501-4570-82f3-5bed38406f7f@github.com>

On Thu, 8 Aug 2024 15:55:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > but not to third-party controls
> 
> Does it mean you propose to make the `Event.propagateConsume()` method public?

If we agree that this is the right API, then yes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276195031

From angorya at openjdk.org  Thu Aug  8 16:26:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 16:26:37 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
Message-ID: <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>

On Thu, 8 Aug 2024 15:57:04 GMT, Martin Fox <mfox at openjdk.org> wrote:

> This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on.

a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences.  It means the developer wants to create new events and not to have the link between the events.

b) I am not convinced that returning null from a dispatcher is a good solution.  We already have an API for that: `Event.isConsumed()`.  Adding a new, parallel paradigm, in my opinion is unnecessary.

The bigger issue I see, as I mentioned earlier, is that 
1. the `Event` has the target field which is absolutely, totally unnecessary (the target already knows who the target is, it is the target) and is an anti-pattern because
2. it forces the dispatcher to create new event instances for new targets, breaking the `isConsumed` logic

I don't think we'll ever change the event dispatching mechanism and remove the target field from Event.  So the only remaining solutions are little hacks and workarounds here and there.

I don't think adding return value to the dispatcher is the right solution.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276213463

From mfox at openjdk.org  Thu Aug  8 17:04:35 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 8 Aug 2024 17:04:35 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
 <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>
Message-ID: <v-DNzm0ivtojDcTniQVQ215HwYcD3dHn9rxLyZFaUJs=.c3ee8975-58e8-4906-a4f8-0d88cd2e7193@github.com>

On Thu, 8 Aug 2024 16:23:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary.

We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already.

There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276277201

From angorya at openjdk.org  Thu Aug  8 17:21:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 17:21:36 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <v-DNzm0ivtojDcTniQVQ215HwYcD3dHn9rxLyZFaUJs=.c3ee8975-58e8-4906-a4f8-0d88cd2e7193@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
 <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>
 <v-DNzm0ivtojDcTniQVQ215HwYcD3dHn9rxLyZFaUJs=.c3ee8975-58e8-4906-a4f8-0d88cd2e7193@github.com>
Message-ID: <ffsh0XIvATM4GyCkZug1YgT84HlfaM3cJXFypLcZc9k=.2825f44a-c1fe-4dc7-a073-bf95dfdb9b83@github.com>

On Thu, 8 Aug 2024 17:01:47 GMT, Martin Fox <mfox at openjdk.org> wrote:

>>> This PR assumes that during dispatch events are copied using copyFor. But the documentation states that an EventDispatcher can do whatever it wants in `dispatchEvent`. A developer could provide a dispatcher that creates entirely new events rather than just copy existing ones and that would break this code. The only thing that?s guaranteed is that the dispatcher will return null to stop event dispatch and that's all that the solution in [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) relies on.
>> 
>> a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences.  It means the developer wants to create new events and not to have the link between the events.
>> 
>> b) I am not convinced that returning null from a dispatcher is a good solution.  We already have an API for that: `Event.isConsumed()`.  Adding a new, parallel paradigm, in my opinion is unnecessary.
>> 
>> The bigger issue I see, as I mentioned earlier, is that 
>> 1. the `Event` has the target field which is absolutely, totally unnecessary (the target already knows who the target is, it is the target) and is an anti-pattern because
>> 2. it forces the dispatcher to create new event instances for new targets, breaking the `isConsumed` logic
>> 
>> I don't think we'll ever change the event dispatching mechanism and remove the target field from Event.  So the only remaining solutions are little hacks and workarounds here and there.
>> 
>> I don't think adding return value to the dispatcher is the right solution.
>
>> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary.
> 
> We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already.
> 
> There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public.

@beldenfox :
EventUtil is not a public API.  Checking the return value of the dispatchEvent is, in my opinion, an anti-pattern.  The right pattern is this (TabPaneBehavior:85):


    public boolean canCloseTab(Tab tab) {
        Event event = new Event(tab,tab,Tab.TAB_CLOSE_REQUEST_EVENT);
        Event.fireEvent(tab, event);
        return ! event.isConsumed();
    }


Using your own argument, a dev can write a dispatcher which returns garbage from its `dispatchEvent` method, breaking the thing.  So I am still not convinced.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276304526

From martin at martinfox.com  Thu Aug  8 17:38:10 2024
From: martin at martinfox.com (Martin Fox)
Date: Thu, 8 Aug 2024 10:38:10 -0700
Subject: Font hinting on Linux
In-Reply-To: <E7C2719C-3B8C-4CCB-9082-6DD8AB08AB33@martinfox.com>
References: <5217eb3b-597d-4bca-b28d-a06fd59719aa@gmail.com>
 <3a31b6e7-a8eb-4aa7-9a2a-2079c07b8c24@oracle.com>
 <CAASO9vSXnKcxpV79J+8iJKafikJenGZUiEL4Fx2wscax=E_q0g@mail.gmail.com>
 <E7C2719C-3B8C-4CCB-9082-6DD8AB08AB33@martinfox.com>
Message-ID: <00F1B57C-BA79-4CA9-838A-1EDC8955B37E@martinfox.com>

(OK, I?m caught up now. Forget whatever I said about hinting.)

I think there is a bug here. LCD text with the software renderer produces particularly bad results. Part of the code is shifting the glyphs along the X axis to set up the LCD shader even though it?s not used with the software renderer. The software renderer is then truncating to the nearest pixel boundary. The result is that glyphs at a fractional X of 0.8333 or less move left and all others move right.

Rounding to the nearest pixel boundary produces better results (in line with grayscale text) though the only really clean results come from using LCD text with the hardware pipeline.

I ended up using the software renderer by accident; I?m running in a VM and get the software renderer unless I force the GPU.

Martin

> On Aug 5, 2024, at 8:32?AM, Martin Fox <martin at martinfox.com> wrote:
> 
> I don?t see how hinting issues can cause this degree of character misplacement. This looks more like, say, a glyph cache bug.
> 
> I had no problem reproducing this with the software pipeline. When I force the GPU I get much better results (prism.forceGPU=true). In both cases the text is a little on the fuzzy side but the es2 pipeline is placing the glyphs correctly.
> 
>> On Aug 4, 2024, at 9:09?PM, quizynox <quizynox at gmail.com> wrote:
>> 
>> Hello,
>> 
>> Thanks for the answer. I've found a couple of very long but very informative threads that have given me some pointers.
>> 
>> Poor quality font rendering
>> https://mail.openjdk.org/pipermail/openjfx-dev/2013-August/009958.html
>> 
>> The crisp fonts saga
>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044234.html
>> 
>> In my case there were two problems:
>> 
>> - I had SceneAntialiasing enabled, which seems to prevent -fx-smoothing-type=lcd from working
>> - I forgot that -fx-smoothing-type is only enabled for .text nodes, but not for all Text nodes by default
>> 
>> I also assumed that Linux fontconfig settings would have some effect on JavaFX font rendering, but judging from tests this isn't the case. Perhaps the only thing that matters is freetype compilation flags. I've found that Fedora enabled ClearType font rendering some time ago (https://www.phoronix.com/news/Fedora-ClearType-Subpixel-Font).
>> 
>> As for -fx-smooth-type=gray, with some fonts such as Open Sans, Liberation Sans or Montserrat it may look quite close to acceptable.
>> 
>> ??, 4 ???. 2024??. ? 01:41, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>>:
>>> There's not many knobs available. Hinting is not enabled - and that's 
>>> commonly the case on modern plartforms.
>>> LCD is your best option for readibility of static text, which is why it 
>>> is the default for UI Controls,
>>> It should reduce the pixel grid fitting uneveness you highlight but 
>>> doesn't eliminate it.
>>> Note : this presumes that the freetype on your system enables LCD .. if 
>>> it doesn't there's nothing FX can do about that.
>>> 
>>> -phil.
>>> 
>>> 
>>> On 8/2/24 10:43 AM, quizynox at gmail.com <mailto:quizynox at gmail.com> wrote:
>>> > Hello,
>>> >
>>> > Sorry for asking here, but I seem to have tried everything I could 
>>> > find on SO/Reddit/JBS etc. Could someone please share what font 
>>> > settings I should be using to get decent font hinting on Linux? Please 
>>> > see the screenshot.
>>> >
>>> > https://drive.google.com/file/d/1gXYXzbcq4cHmZpza20yQJHfs0pMbgiZa/view
>>> >
>>> > I'm not very picky, but the font I see is just not suitable for 
>>> > presenting app to customers. I've tried enabling and disabling hinting 
>>> > and autohinting, using different hinting styles, changing the font 
>>> > smoothing type and prism.lcdtext etc. Unfortunately no matter what I 
>>> > do, the font hinting is always bad.
>>> >
>>> > Fedora, KDE, all latest versions.
>>> >
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240808/35184bca/attachment.htm>

From angorya at openjdk.org  Thu Aug  8 17:40:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 17:40:37 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
Message-ID: <RyXIJbS9fGSU5upaXoad-FyJxjy9in8IoCQmq98VMCA=.94da2730-7e3a-4fc8-ba80-b69a28fb1cb4@github.com>

On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar.
> 
> We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.
> 
> I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

Thinking out loud for a moment: wouldn't it be better to use a kind of EventFilter specifically for the shortcuts, before the normal dispatching happens?

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2276339875

From mfox at openjdk.org  Thu Aug  8 20:20:35 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 8 Aug 2024 20:20:35 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ffsh0XIvATM4GyCkZug1YgT84HlfaM3cJXFypLcZc9k=.2825f44a-c1fe-4dc7-a073-bf95dfdb9b83@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
 <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>
 <v-DNzm0ivtojDcTniQVQ215HwYcD3dHn9rxLyZFaUJs=.c3ee8975-58e8-4906-a4f8-0d88cd2e7193@github.com>
 <ffsh0XIvATM4GyCkZug1YgT84HlfaM3cJXFypLcZc9k=.2825f44a-c1fe-4dc7-a073-bf95dfdb9b83@github.com>
Message-ID: <IHAnD0dEutmmWkG2iUJ8vAm1eZsWmQ4FX2vgmyOvPVU=.e56f57fa-5a20-46a9-af31-106bdc9019f5@github.com>

On Thu, 8 Aug 2024 17:18:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> b) I am not convinced that returning null from a dispatcher is a good solution. We already have an API for that: `Event.isConsumed()`. Adding a new, parallel paradigm, in my opinion is unnecessary.
>> 
>> We would not be adding anything. Consuming an event is how a developer communicates to one EventDispatcher that the event was dealt with. But this information is propagated through the dispatch chain by returning null from dispatchEvent. That's all in place already.
>> 
>> There's a variant of `EventUtil.fireEvent` that returns the result of dispatchEvent so a client can check for null to see if the event was consumed. And there are already places in the code where this happens. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) calls for this to be cleaned up and made public.
>
> @beldenfox :
> EventUtil is not a public API.  Checking the return value of the dispatchEvent is, in my opinion, an anti-pattern.  The right pattern is this (TabPaneBehavior:85):
> 
> 
>     public boolean canCloseTab(Tab tab) {
>         Event event = new Event(tab,tab,Tab.TAB_CLOSE_REQUEST_EVENT);
>         Event.fireEvent(tab, event);
>         return ! event.isConsumed();
>     }
> 
> 
> Using your own argument, a dev can write a dispatcher which returns garbage from its `dispatchEvent` method, breaking the thing.  So I am still not convinced.

@andy-goryachev-oracle I agree that propagating the consumed flag is clearer and would lead to less surprises. Once upon a time I also thought that I could call fireEvent and then check the event's consumed flag afterward. I had to dig around a bit to figure out that all these copies were being made. It is confusing.

For that matter you can't really infer that an event was consumed just because the dispatch chain returned null. The EventDispatcher documentation is a little hazy on this but in theory a dispatcher could return null for other reasons. It seems to be mostly a matter of convention that null indicates that an event was consumed.

With that said in this PR changing the consumed flag in one event can change the consumed state of another event and that also seems like unexpected and surprising behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276584223

From duke at openjdk.org  Thu Aug  8 20:22:06 2024
From: duke at openjdk.org (Loay Ghreeb)
Date: Thu, 8 Aug 2024 20:22:06 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
Message-ID: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>

Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order.

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

Commit messages:
 - Merge branch 'master' into SortedList
 - Merge branch 'master' into SortedList
 - Add test case
 - Fix SortedList to maintain insertion order for equal elements

Changes: https://git.openjdk.org/jfx/pull/1519/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301761
  Stats: 37 lines in 2 files changed: 28 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1519.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1519/head:pull/1519

PR: https://git.openjdk.org/jfx/pull/1519

From duke at openjdk.org  Thu Aug  8 20:22:06 2024
From: duke at openjdk.org (Loay Ghreeb)
Date: Thu, 8 Aug 2024 20:22:06 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
Message-ID: <w8m7i1H8DuC4ClJb1aYWxd4TFFBa3r1wRes8wcVFKo4=.f0017100-3a3b-409d-b32e-af5ee2258b5f@github.com>

On Sun, 28 Jul 2024 04:13:30 GMT, Loay Ghreeb <duke at openjdk.org> wrote:

> Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order.

I submitted the OCA, but it's still under review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2259685053

From angorya at openjdk.org  Thu Aug  8 20:33:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 8 Aug 2024 20:33:35 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <CmCVMlUswigA1Z3rA_kw2c1JcWVl7AySYkBCN2DI1Rk=.2464579c-4ff9-4b35-948b-4bd6271bdc46@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

Yeah, that's why I tried to hide this from the public.  I see the whole create-multiple-events idea as a _bad design_ (tm), so the proposed change is a hack^H^H^H workaround to be used internally by FX in a few specific cases (Note1).  The current PR also makes the fix localized to the specific scenario, further reducing the regression risk.

I don't think this functionality should be made public, contrary to what @mstr2 and @kleopatra say (sorry!).  I don't have any better ideas, and let's admit it, the current event dispatching paradigm will never be changed.

Note 1:

There might be more scenarios where FX needs to know whether any of the secondary events got consumed.  It's unlikely that trivial use of FX triggers the issue, but we can look through the bug list to see if we have any more mentioning `isConsumed()`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2276602986

From mstrauss at openjdk.org  Fri Aug  9 02:20:45 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 02:20:45 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v19]
In-Reply-To: <F6iLHlWmL8jPhm7SY9MQTZpRTwGIFQp4LW2FLR3nRYo=.1e844991-8288-4ab9-90f6-89bb6f219e8f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <WuOZNx-4NVn-8oxR2EE6bnoK7BBU33UoKdJatpNDNWk=.da9de1ef-81c3-46e6-9475-f85bd10c9210@github.com>
 <yTEMUbOdGOCA8e5V7ekFJvccY8X6Xav6Lk1PuFqueqw=.4e323345-bcd8-46f1-be6e-90971e1408f6@github.com>
 <ueKRW89TarU2sZZOPIJ2ujmfW2RBoRycls89vzrS7zY=.9563e1b9-eb6e-4e2e-95c8-2723017937de@github.com>
 <F6iLHlWmL8jPhm7SY9MQTZpRTwGIFQp4LW2FLR3nRYo=.1e844991-8288-4ab9-90f6-89bb6f219e8f@github.com>
Message-ID: <VDy8ji0AXP30tyGnMxsyWMUAGCpJXwm3qvzwBImpC3A=.1b2c9c9d-422d-4f45-a650-3de2701864a5@github.com>

On Thu, 8 Aug 2024 15:38:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Since probably most of the properties are "interpolatable" we can mention that the particular property does not support interpolation instead.
> 
> Another example: until [JDK-8338002](https://bugs.openjdk.org/browse/JDK-8338002) is implemented, -fx-font* interpolates discretely, which should be reflected in the css spec.
> 
> Or am I missing something?

Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2277022380

From mstrauss at openjdk.org  Fri Aug  9 02:25:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 02:25:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
 <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com>
Message-ID: <FLuoepBushZGQ6AdAcnO4TP53iJkmG4wpPyaOktSA5M=.3e4f7012-0cff-442f-936e-6348b3f50f90@github.com>

On Thu, 8 Aug 2024 15:41:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   only call get() when necessary
>
> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113:
> 
>> 111:          * @return a {@code Map} of the constituent values
>> 112:          */
>> 113:         Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);
> 
> perhaps `convertToMap` might be better?  or something along the lines of `toInstance`/`toMap` ?   `decompose` / `reconstruct` ?  (though decompose might evoke wrong associations)

`reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1710584650

From mstrauss at openjdk.org  Fri Aug  9 03:21:37 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 03:21:37 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <IHAnD0dEutmmWkG2iUJ8vAm1eZsWmQ4FX2vgmyOvPVU=.e56f57fa-5a20-46a9-af31-106bdc9019f5@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <d033ZYPZ6IRiTVI2ENi1U6HzDrwxAwJydL8y_vHw76E=.0a3939e1-9a0d-41d6-8d8a-6cf2d0bcea36@github.com>
 <AUwh8l_5kBzD2KXNqDNUjLO_13_Gozx6Y2M06siV0hY=.7472841b-9f36-4aca-aa99-a3f3bcd67e5e@github.com>
 <v-DNzm0ivtojDcTniQVQ215HwYcD3dHn9rxLyZFaUJs=.c3ee8975-58e8-4906-a4f8-0d88cd2e7193@github.com>
 <ffsh0XIvATM4GyCkZug1YgT84HlfaM3cJXFypLcZc9k=.2825f44a-c1fe-4dc7-a073-bf95dfdb9b83@github.com>
 <IHAnD0dEutmmWkG2iUJ8vAm1eZsWmQ4FX2vgmyOvPVU=.e56f57fa-5a20-46a9-af31-106bdc9019f5@github.com>
Message-ID: <JJWCA4Y3SkxZwit59Qnj_LrRunSgaWSN6x7JwlHMF4M=.80832610-2a7d-4d11-b0b4-5a8e268823ba@github.com>

On Thu, 8 Aug 2024 20:18:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

> For that matter you can't really infer that an event was consumed just because the dispatch chain returned null. The EventDispatcher documentation is a little hazy on this but in theory a dispatcher could return null for other reasons. It seems to be mostly a matter of convention that null indicates that an event was consumed.

It seems much more likely that we could clean this up by explicitly specifying this behavior.

Here's what I would do:
1. Implement [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209)
2. Specify that `dispatchEvent` must only return `null` if the event was consumed.
3. Explicitly document that `Event.isConsumed()` can only be used inside of an event handler, but not to detect whether an event was consumed at the place where the event is fired.

This would be sufficient to solve the problem at hand, and will also enable third-party controls to do the same.

Going further, I question whether we need the `isConsumed()` method at all. Consumed events shouldn't be propagated, and the current behavior is very strange to say the least (events on the same level are propagated even though they're consumed). If consumed events are not propagated, there should be no need to check whether an event was consumed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2277066533

From duke at openjdk.org  Fri Aug  9 03:30:09 2024
From: duke at openjdk.org (Loay Ghreeb)
Date: Fri, 9 Aug 2024 03:30:09 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
 [v2]
In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
Message-ID: <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>

> Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order.

Loay Ghreeb has updated the pull request 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. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into SortedList
 - Merge branch 'master' into SortedList
 - Merge branch 'master' into SortedList
 - Add test case
 - Fix SortedList to maintain insertion order for equal elements

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1519/files
  - new: https://git.openjdk.org/jfx/pull/1519/files/fa2deb48..15f1a9ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=00-01

  Stats: 643 lines in 8 files changed: 472 ins; 61 del; 110 mod
  Patch: https://git.openjdk.org/jfx/pull/1519.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1519/head:pull/1519

PR: https://git.openjdk.org/jfx/pull/1519

From lkostyra at openjdk.org  Fri Aug  9 08:13:16 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 9 Aug 2024 08:13:16 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  GlassViewDelegate: Correctly set origin and offset in dragImage
  
  - Centering to dragImage was removed - origin is now top-left of dragImage
  - Offset direction was swapped

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1532/files
  - new: https://git.openjdk.org/jfx/pull/1532/files/92c190e2..c922de84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1532.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532

PR: https://git.openjdk.org/jfx/pull/1532

From lkostyra at openjdk.org  Fri Aug  9 08:13:16 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 9 Aug 2024 08:13:16 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <Qjy2LQYoNQOcKxmUAEpyBe8_XTA24ufmMG88-09uboM=.14a696d3-741a-4836-8c58-a7b9a1755214@github.com>

On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

I did not realize that Windows/macOS behavior was matched in this regard, so I'll use Windows as reference for further testing. Thanks!

I agree offsets should be flipped (with `-=` rather than `+=`) so that is working well. I also removed the centering of the drag image, so now both shift directions and offset origin match Windows.

However, from my initial testing, it seems like macOS prefers the mouse cursor to be always within the drag image bounds. As an example, `DndTest.java` defined the Y offset equal to -30. While the drag image is initially offset correctly, macOS immediately "snaps" it back so that the mouse cursor stays within the drag image bounds. This seems to be a platform-specific behavior though (Windows keeps the offset as we define it). I'll do some more experiments and see if that can be remedied somehow, but for now I doubt it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2277396417

From jhendrikx at openjdk.org  Fri Aug  9 11:24:39 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 9 Aug 2024 11:24:39 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-UahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
Message-ID: <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>

On Thu, 8 Aug 2024 15:45:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Returning `null` seems fine from the perspective of `StyleConverter`, but it makes the calling code very awkward. Remember, we ended up here because we needed a way to detect whether an object would support component-wise transitions. If we can't detect that without invoking `convertBack`, we would need to either:
>> 1. Speculatively decompose the value without knowing whether there even are any transitions defined on the node. This is bad because most of the time, there will be no transitions; we will end up deconstructing many objects for no reason.
>> 2. _Assume_ that an object is component-transitionable, look up all potential transitions, and decompose the value; then, if we were wrong with out assumption, go back to the start and try again with another code path (`Interpolatable` or no transition).
>> 
>> Instead, what I've implemented now is a new interface `StyleConverter.WithReconstructionSupport`, which contains both methods:
>> 
>> public interface WithReconstructionSupport<T> {
>>     T convert(Map<CssMetaData<? extends Styleable, ?>, Object> values);
>>     Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);
>> }
>> 
>> 
>> This allows us to use object deconstruction and reconstruction with a single interface reference, and also allows us to detect such support very easily.
>
> +1 for `StyleConverter.WithReconstructionSupport`
> 
> maybe use a shorter name, like
> 
> `StyleConverter.WithReconstruction`

Clear, thanks MIchael.  I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also:

    if (converter instanceof Reconstructable r) { ... }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711286120

From mstrauss at openjdk.org  Fri Aug  9 13:39:43 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 13:39:43 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
Message-ID: <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>

On Fri, 9 Aug 2024 11:20:55 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> +1 for `StyleConverter.WithReconstructionSupport`
>> 
>> maybe use a shorter name, like
>> 
>> `StyleConverter.WithReconstruction`
>
> Clear, thanks MIchael.  I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also:
> 
>     if (converter instanceof Reconstructable r) { ... }

But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711480351

From michaelstrau2 at gmail.com  Fri Aug  9 14:31:04 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 9 Aug 2024 16:31:04 +0200
Subject: No Place for JEPs
In-Reply-To: <BL3PR10MB618595435024348B39CEB480E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB618595435024348B39CEB480E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXTfoDVqmSBQZLjQtxo=v8DDO84ggO=n4KxiC__xduDE7g@mail.gmail.com>

Hi Andy,

wouldn't these documents risk getting outdated when the codebase is
evolved? JEPs seem to be most relevant at the time when a feature is
proposed. I think I'd rather have documentation colocated with the
code itself, this makes it easier to keep the documentation in sync
with the actual implementation.


On Wed, Aug 7, 2024 at 8:46?PM Andy Goryachev <andy.goryachev at oracle.com> wrote:
>
> Dear fellow developers:
>
>
>
> We often create JEPs and JEP-formatted documents as we propose and develop new features.  These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth.  Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0].
>
>
>
> I think there is a value in making these documents a part of the main repository, maybe under /doc-files.  Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed.  Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
> References
>
>
>
> [0] https://github.com/openjdk/jfx/pull/1522

From angorya at openjdk.org  Fri Aug  9 14:40:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Aug 2024 14:40:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
Message-ID: <ifjXC0Wg6Bhitkeuj4oPH9EsJfbPGC9DSbZkWp53yDU=.515a1f50-d44c-40bb-91f5-9b08fb3fa05f@github.com>

On Thu, 8 Aug 2024 04:00:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only call get() when necessary

> Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR.

I am afraid I'd disagree here: I would like to see the CSS reference reflect the new changes, to be in sync with the javadoc.  I think this is still a part of the same changeset.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2278099177

From angorya at openjdk.org  Fri Aug  9 14:54:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Aug 2024 14:54:43 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <Gj6nzrhNWDWzIoaBEj0uCnmxkh5TpFwZ1qVAbwgOJZ4=.22aeb18d-627f-4e2d-9be2-8bc03eb1ca9c@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

> * Implement [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209)
> * Specify that `dispatchEvent` must only return `null` if the event was consumed.
> * Explicitly document that `Event.isConsumed()` can only be used inside of an event handler, but not to detect whether an event was consumed at the place where the event is fired.

I am afraid this makes no sense to me.  I still think the root cause of the issue(s) is the cloning of events, where the cloning code ignores the possible consumption of the secondary events.

I don't think we should redefine semantics of `Event.isConsumed()`, this method worked well in AWT/Swing and elsewhere (QT).

If anything, the code that clones an event for the purposes of changing its target needs to look at the isConsumed() flag and propagate it to the original event.  The problem is that `Event.copyFor()` is also used for other purposes as well.

Looks like we've reached an impasse (again).

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278135889

From kcr at openjdk.org  Fri Aug  9 15:05:46 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 Aug 2024 15:05:46 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <ifjXC0Wg6Bhitkeuj4oPH9EsJfbPGC9DSbZkWp53yDU=.515a1f50-d44c-40bb-91f5-9b08fb3fa05f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
 <ifjXC0Wg6Bhitkeuj4oPH9EsJfbPGC9DSbZkWp53yDU=.515a1f50-d44c-40bb-91f5-9b08fb3fa05f@github.com>
Message-ID: <-2v4p-hrGdbP3zE3Xgr9jz4owM8NFosVIdxUfCEYKZ0=.0e21a1d3-152b-4e31-9387-fda9318242f2@github.com>

On Fri, 9 Aug 2024 14:37:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Maybe we should do that as a separate ticket. Changing the documentation of properties that have nothing to do with backgrounds and borders is probably a bit out of scope for this PR.
> 
> I am afraid I'd disagree here: I would like to see the CSS reference reflect the new changes, to be in sync with the javadoc. I think this is still a part of the same changeset.

I'm a bit behind this week due to other commitments, but wanted to chime in briefly. The main question in my mind is whether (and how) this particular aspect of a property should be documented in the cssref. We don't duplicate all aspects of each styleable property in cssref. So, is the fact that a property is interpolatable important enough to CSS operation that it should be duplicated in cssref or not? I haven't had time to form an opinion, but that's the question that should be answered first.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2278160387

From angorya at openjdk.org  Fri Aug  9 15:12:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Aug 2024 15:12:39 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
Message-ID: <tpXv17g8LAN9ya5tgR34LBkSTfcF8K8Gsgs_zHgI1ok=.8da7bdd4-31eb-408f-9f16-137013935321@github.com>

On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

You are right, @hjohn , we probably should not alter the behavior in this PR.

The rest looks good.  If you decide to make the minor changes I've mentioned, I'll re-approve.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2230449949

From andy.goryachev at oracle.com  Fri Aug  9 15:28:29 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 9 Aug 2024 15:28:29 +0000
Subject: No Place for JEPs
In-Reply-To: <CAJEpuXTfoDVqmSBQZLjQtxo=v8DDO84ggO=n4KxiC__xduDE7g@mail.gmail.com>
References: <BL3PR10MB618595435024348B39CEB480E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXTfoDVqmSBQZLjQtxo=v8DDO84ggO=n4KxiC__xduDE7g@mail.gmail.com>
Message-ID: <BL3PR10MB61850070D0037F6824C85FF8E5BA2@BL3PR10MB6185.namprd10.prod.outlook.com>

Michael:

Yes, by design.  I think the JEPs still have value even after the actual changes were made.  Also, nothing prevents us from creating an index.html file that lists the JEPs in chronological order and mentions the state of the implemented features and whether and how the actual implementation differs from the JEP.

Sorry, I did not quite understand what you mean by "documentation colocated with the code" - isn't that what I am proposing?

At the same time, I wanted to consider other possibilities, such as

- wikis (same drawbacks as github PRs, even harder to review / keep track of changes / lack of co-location)
- separate doc repo (not co-located with the code)
- ??

What do you think?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Friday, August 9, 2024 at 07:31
To:
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: No Place for JEPs
Hi Andy,

wouldn't these documents risk getting outdated when the codebase is
evolved? JEPs seem to be most relevant at the time when a feature is
proposed. I think I'd rather have documentation colocated with the
code itself, this makes it easier to keep the documentation in sync
with the actual implementation.


On Wed, Aug 7, 2024 at 8:46?PM Andy Goryachev <andy.goryachev at oracle.com> wrote:
>
> Dear fellow developers:
>
>
>
> We often create JEPs and JEP-formatted documents as we propose and develop new features.  These help us during the review process and I am sure are of some benefit for application developers as they try to learn the new functionality in depth.  Presently, we've been creating these files in personal repositories, or presented as descriptions for pull requests, see for example [0].
>
>
>
> I think there is a value in making these documents a part of the main repository, maybe under /doc-files.  Doing so would help with the review process as the markdown files are both human-readable and easily diff'ed.  Also, I think it might be more convenient to keep them in the same repo as the code, as opposed to the some personal repositories or wikis.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
> References
>
>
>
> [0] https://github.com/openjdk/jfx/pull/1522
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240809/d5755b18/attachment.htm>

From angorya at openjdk.org  Fri Aug  9 15:40:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Aug 2024 15:40:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <FLuoepBushZGQ6AdAcnO4TP53iJkmG4wpPyaOktSA5M=.3e4f7012-0cff-442f-936e-6348b3f50f90@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
 <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com>
 <FLuoepBushZGQ6AdAcnO4TP53iJkmG4wpPyaOktSA5M=.3e4f7012-0cff-442f-936e-6348b3f50f90@github.com>
Message-ID: <ozPGzeRYhOf-X6CBswLnlON3FDnoevHcTgnLVf2kUzo=.459a35ca-c37d-40f8-b89d-0de71117b712@github.com>

On Fri, 9 Aug 2024 02:23:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 113:
>> 
>>> 111:          * @return a {@code Map} of the constituent values
>>> 112:          */
>>> 113:         Map<CssMetaData<? extends Styleable, ?>, Object> convertBack(T value);
>> 
>> perhaps `convertToMap` might be better?  or something along the lines of `toInstance`/`toMap` ?   `decompose` / `reconstruct` ?  (though decompose might evoke wrong associations)
>
> `reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`.

That's fine, I just think `convertBack` implies an arrow of time or a preferred spatial direction.

Maybe `toMap()`, but as long as the method is sufficiently documented, we should be fine.  Naming _is_ hard.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1711692474

From perini.davide at dpsoftware.org  Fri Aug  9 15:56:02 2024
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Fri, 9 Aug 2024 17:56:02 +0200
Subject: JEP Vector API (Incubator). A funny use case and a question.
Message-ID: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org>

Hi there,
thanks for the opportunity that you give us to write on this mailing-list.

I'm am playing with the Vector API bundled in Java 22 and wow, they are 
amazing.
I have some serious benefits using them even for simple tasks on my AMD 
Ryzen 9 7950X3D CPU that uses Zen4 architecture.

Can't wait to see how bigger the benefits will be on the upcoming 
processors that has some serious optimized AVX512 instructions (AMD Zen5 
architecture and Intel AV10 instructions).

I'll try to give you some context.
I am writing an open source software that is basically a free clone of 
the Philips Ambilight effect.

What is it?
Basically you put a LED strip behind your monitor/TV, the software 
capture the screen,
it calculates the average colors of your screen, and sends those average 
values to a microcontroller (arduino) that drives the strip and light up 
the LEDs accordingly.
This effect is also known as dynamic bias light.
More info here if you are curious:
https://github.com/sblantipodi/firefly_luciferin

Most of the computations involved are on the GPU side but some intensive 
ones are on the CPU side.

Let's go deeper on the Vector API.
GPU acquire the screen image 60 times per seconds (or even more), every 
frame is a Buffer that contains colors information for each pixel of the 
frame.
This buffer is a Java Direct IntBuffer that doesn't have a corresponding 
array inside the heap for performance reason.

Once I have this IntBuffer I need to calculate the average colors of the 
screen and this thing can be made on the fly on the IntBuffer without 
copying the IntBuffer inside an Array. This kind of copy is really 
really heavy and degrade performance.

Just a snippet that shows it without using the Vector API...

for (int y =0; y < pixelInUseY; y++) {
     for (int x =0; x < pixelInUseX; x++) {
         int offsetX = (xCoordinate + x);
         int offsetY = (yCoordinate + y);
         int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY <height) ? (offsetY *widthPlusStride) : (height *widthPlusStride));
         int rgb =rgbBuffer.get(Math.min(rgbBuffer.capacity() -1, bufferOffset));
         r += rgb >>16 &0xFF;
         g += rgb >>8 &0xFF;
         b += rgb &0xFF;
         pickNumber++;
     }
}
leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber);


Now I'm trying to use the Vector API to accelerate this computations 
even more and hey, it worked awesome.
Using AVX512 (Species512) the computations is 40%-80% faster than 
without the Vector API.

int firstLimit;
int secondLimit;
// Processing the buffer in the correct order is crucial for SIMD 
performance if (pixelInUseX < pixelInUseY) {
     firstLimit = pixelInUseX;
     secondLimit = pixelInUseY;
}else {
     firstLimit = pixelInUseY;
     secondLimit = pixelInUseX;
}
// SIMD iteration for (int x =0; x < firstLimit; x++) {
     for (int y =0; y < secondLimit; y += MainSingleton.getInstance().SPECIES.length()) {
         int offsetX;
         int offsetY;
         if (pixelInUseX < pixelInUseY) {
             offsetX = (xCoordinate + x);
             offsetY = (yCoordinate + y);
         }else {
             offsetX = (xCoordinate + y);
             offsetY = (yCoordinate + x);
         }
         int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY <height) ? (offsetY *widthPlusStride) : (height *widthPlusStride));
         // Load RGB values using SIMD int[] rgbArray =new int[MainSingleton.getInstance().SPECIES.length()];
         rgbBuffer.position(bufferOffset);
         rgbBuffer.get(rgbArray,0, Math.min(MainSingleton.getInstance().SPECIES.length(),rgbBuffer.remaining()));
         IntVector rgbVector = IntVector.fromArray(MainSingleton.getInstance().SPECIES, rgbArray,0);
         r += rgbVector.lane(0) >>16 &0xFF;
         g += rgbVector.lane(1) >>8 &0xFF;
         b += rgbVector.lane(2) &0xFF;
         pickNumber++;
     }
}
leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber);


The computation itself is at least ten times faster but at the end it's 
only 40%-80% faster because I'm not able to process the IntBuffer on the 
fly using Vector API.
As you can see in the previous snippet I need to copy part of the 
IntBuffer into an int[] array and then process it using the Vector API.
This copy alone is the thing that requires more time.

Is it possible to process a direct IntBuffer with the Vector API without 
loosing time in an array copy?

Thank you for this wonderful API.

Kind regards
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240809/e6ad8608/attachment.htm>

From perini.davide at dpsoftware.org  Fri Aug  9 15:57:49 2024
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Fri, 9 Aug 2024 17:57:49 +0200
Subject: JEP Vector API (Incubator). A funny use case and a question.
In-Reply-To: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org>
References: <3e924999-43dc-41c9-ae19-08e4249351c5@dpsoftware.org>
Message-ID: <2ea2f5ab-a2ae-4ae7-86ce-66f0c9a9e01b@dpsoftware.org>

sorry to everyone. wrong list :(

Il 09/08/2024 17:56, Davide Perini ha scritto:
> Hi there,
> thanks for the opportunity that you give us to write on this mailing-list.
>
> I'm am playing with the Vector API bundled in Java 22 and wow, they 
> are amazing.
> I have some serious benefits using them even for simple tasks on my 
> AMD Ryzen 9 7950X3D CPU that uses Zen4 architecture.
>
> Can't wait to see how bigger the benefits will be on the upcoming 
> processors that has some serious optimized AVX512 instructions (AMD 
> Zen5 architecture and Intel AV10 instructions).
>
> I'll try to give you some context.
> I am writing an open source software that is basically a free clone of 
> the Philips Ambilight effect.
>
> What is it?
> Basically you put a LED strip behind your monitor/TV, the software 
> capture the screen,
> it calculates the average colors of your screen, and sends those 
> average values to a microcontroller (arduino) that drives the strip 
> and light up the LEDs accordingly.
> This effect is also known as dynamic bias light.
> More info here if you are curious:
> https://github.com/sblantipodi/firefly_luciferin
>
> Most of the computations involved are on the GPU side but some 
> intensive ones are on the CPU side.
>
> Let's go deeper on the Vector API.
> GPU acquire the screen image 60 times per seconds (or even more), 
> every frame is a Buffer that contains colors information for each 
> pixel of the frame.
> This buffer is a Java Direct IntBuffer that doesn't have a 
> corresponding array inside the heap for performance reason.
>
> Once I have this IntBuffer I need to calculate the average colors of 
> the screen and this thing can be made on the fly on the IntBuffer 
> without copying the IntBuffer inside an Array. This kind of copy is 
> really really heavy and degrade performance.
>
> Just a snippet that shows it without using the Vector API...
> for (int y =0; y < pixelInUseY; y++) {
>      for (int x =0; x < pixelInUseX; x++) {
>          int offsetX = (xCoordinate + x);
>          int offsetY = (yCoordinate + y);
>          int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY <height) ? (offsetY *widthPlusStride) : (height *widthPlusStride));
>          int rgb =rgbBuffer.get(Math.min(rgbBuffer.capacity() -1, bufferOffset));
>          r += rgb >>16 &0xFF;
>          g += rgb >>8 &0xFF;
>          b += rgb &0xFF;
>          pickNumber++;
>      }
> }
> leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber);
>
> Now I'm trying to use the Vector API to accelerate this computations 
> even more and hey, it worked awesome.
> Using AVX512 (Species512) the computations is 40%-80% faster than 
> without the Vector API.
> int firstLimit;
> int secondLimit;
> // Processing the buffer in the correct order is crucial for SIMD 
> performance if (pixelInUseX < pixelInUseY) {
>      firstLimit = pixelInUseX;
>      secondLimit = pixelInUseY;
> }else {
>      firstLimit = pixelInUseY;
>      secondLimit = pixelInUseX;
> }
> // SIMD iteration for (int x =0; x < firstLimit; x++) {
>      for (int y =0; y < secondLimit; y += MainSingleton.getInstance().SPECIES.length()) {
>          int offsetX;
>          int offsetY;
>          if (pixelInUseX < pixelInUseY) {
>              offsetX = (xCoordinate + x);
>              offsetY = (yCoordinate + y);
>          }else {
>              offsetX = (xCoordinate + y);
>              offsetY = (yCoordinate + x);
>          }
>          int bufferOffset = (Math.min(offsetX,widthPlusStride)) + ((offsetY <height) ? (offsetY *widthPlusStride) : (height *widthPlusStride));
>          // Load RGB values using SIMD int[] rgbArray =new int[MainSingleton.getInstance().SPECIES.length()];
>          rgbBuffer.position(bufferOffset);
>          rgbBuffer.get(rgbArray,0, Math.min(MainSingleton.getInstance().SPECIES.length(),rgbBuffer.remaining()));
>          IntVector rgbVector = IntVector.fromArray(MainSingleton.getInstance().SPECIES, rgbArray,0);
>          r += rgbVector.lane(0) >>16 &0xFF;
>          g += rgbVector.lane(1) >>8 &0xFF;
>          b += rgbVector.lane(2) &0xFF;
>          pickNumber++;
>      }
> }
> leds[key -1] = ImageProcessor.correctColors(r, g, b, pickNumber);
>
> The computation itself is at least ten times faster but at the end 
> it's only 40%-80% faster because I'm not able to process the IntBuffer 
> on the fly using Vector API.
> As you can see in the previous snippet I need to copy part of the 
> IntBuffer into an int[] array and then process it using the Vector API.
> This copy alone is the thing that requires more time.
>
> Is it possible to process a direct IntBuffer with the Vector API 
> without loosing time in an array copy?
>
> Thank you for this wonderful API.
>
> Kind regards
> Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240809/6de284ae/attachment-0001.htm>

From vdyakov at openjdk.org  Fri Aug  9 16:39:40 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Fri, 9 Aug 2024 16:39:40 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <zpITw3Rg0EHlnWS6zvsatrkdP3_5_eKTiVlHLClX1g4=.a9f285ab-8676-4ef1-ab3d-745ba42dd738@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

@arapte please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2278333797

From angorya at openjdk.org  Fri Aug  9 16:41:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Aug 2024 16:41:36 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <A_dbQjVXZHIpn2WPXXdxBBmaDMpC-ZjvcNjrZ2U49BA=.13a6297c-09b0-427e-8da4-8e346926371b@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

Actually, no CSR is required if I revert the `final` keyword changes.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278336752

From mstrauss at openjdk.org  Fri Aug  9 17:00:14 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 17:00:14 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v23]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <pmF2OVWpDEZ-jDnrzyLtD55Kn8xN3wGPAc--Fy0Zfnw=.e5de60b9-3e3e-4445-ad8c-5bcc4a5eb5fa@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  non-interpolatable values should always transition discretely

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/1abd6887..abef4325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=22
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=21-22

  Stats: 174 lines in 3 files changed: 128 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Fri Aug  9 18:11:19 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 18:11:19 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v24]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <RTgsaBFpabBmnovcQc4llyfY6qFzV5OddXERCJzqhnE=.b0c41539-4b86-4d05-8d25-9ce67ba2febb@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

 - fix line separators
 - StyleableStringProperty should be transitionable

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/abef4325..a0557b8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=22-23

  Stats: 111 lines in 2 files changed: 103 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From jhendrikx at openjdk.org  Fri Aug  9 19:13:37 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 9 Aug 2024 19:13:37 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
 [v2]
In-Reply-To: <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
 <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>
Message-ID: <TyTZ06z9bvapO74_LV_QbP83rkZkkB36ns6EH76vW9U=.15196399-34c1-4f6a-818f-383aa9ddbd95@github.com>

On Fri, 9 Aug 2024 03:30:09 GMT, Loay Ghreeb <duke at openjdk.org> wrote:

>> Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order.
>
> Loay Ghreeb has updated the pull request 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. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into SortedList
>  - Merge branch 'master' into SortedList
>  - Merge branch 'master' into SortedList
>  - Add test case
>  - Fix SortedList to maintain insertion order for equal elements

The PR title "The sorting of the SortedList can become invalid" seems to imply that the sorting can become incorrect, as in the incorrect order.

This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation.

So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements.  If we do, then it should be documented, and also maintained when the list gets resorted (ie. resorts must be stable).

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

PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2278581112

From john.hendrikx at gmail.com  Fri Aug  9 19:15:05 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 9 Aug 2024 21:15:05 +0200
Subject: Detecting threading problems faster
In-Reply-To: <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
 <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
 <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>
 <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
Message-ID: <0d5bc648-a487-4052-b592-219066ffe9d8@gmail.com>

Feel free, it is also somewhere on my github.? I'm not entirely 
confident it works for all cases, but it can be tweaked. Here's the 
missing piece you may need:

/**

* Tracks time spent (in milliseconds) between calls of {@link 
#enterNested()}and {@link #exitNested()}

* excluding time spent in deeper nested levels. This allows to find the 
time spent at a certain

* nesting level without including time spent at any deeper nestings.

*/

publicclassNestedTimeTracker{

privatefinalDeque<Long> startTimes= newArrayDeque<>();

privatefinalDeque<Long> cumulativeDurations= newArrayDeque<>();

{

cumulativeDurations.add(0L); // Add root level, always present (this is 
never used, the entry is there to avoid having to check if we're at root 
level)

}

publicintgetCurrentLevel() {

returnstartTimes.size();

}

publicvoidenterNested() {

enterNested(System.currentTimeMillis());

}

publicvoidenterNested(longcurrentTimeMillis) {

startTimes.addLast(currentTimeMillis);

cumulativeDurations.add(0L);

}

publicvoidexitNested() {

exitNested(System.currentTimeMillis());

}

publiclongexitNested(longcurrentTimeMillis) {

longstartTime = startTimes.removeLast();

longtimeSpentInNested = cumulativeDurations.removeLast(); // nested 
time, not part of this level

longtotalTime = currentTimeMillis - startTime; // total time, including 
nested levels

longtimeSpentAtThisLevel = totalTime - timeSpentInNested;

// Consolidate total time spent in next higher level:

cumulativeDurations.addLast(cumulativeDurations.removeLast() + totalTime);

returntimeSpentAtThisLevel;

}

}

--John

On 08/08/2024 12:47, Thiago Milczarek Say?o wrote:
> Nice! I will steal it if you don't mind.
>
> Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx 
> <john.hendrikx at gmail.com> escreveu:
>
>     For detecting long running tasks on the FX thread, there are some
>     other options which you can do as a user (but perhaps we can
>     support it directly within FX).? I use this kind of code to detect
>     long running things on the FX thread:
>
>     /**
>
>     * Adds a slow event warning whenever an event takes more than 10
>     msto process. Note
>
>     * that time spent in nested event loops cannot be properly taken
>     into account as time
>
>     * spent in nested event loops will be part of the event that
>     triggered it giving false
>
>     * positives. In order for this time to be accurately reflected,
>     the methods to enter
>
>     * a nested event loop in this class should be used instead of the
>     ones in {@link Platform}.
>
>     *
>
>     * @paramscene a Scene to which to add the slow event warning
>     detection, cannot be null
>
>     */
>
>     publicstaticvoidaddSlowEventWarning(Scene scene) {
>
>     finalEventDispatcher eventDispatcher = scene.getEventDispatcher();
>
>     scene.setEventDispatcher(newEventDispatcher() {
>
>     privateScheduledFuture<StackTraceElement[]> future;
>
>     @Override
>
>     publicEvent dispatchEvent(Event event, EventDispatchChain tail) {
>
>     if(future!= null) {
>
>     future.cancel(false);
>
>     }
>
>     longstartTime = System.currentTimeMillis();
>
>     TIME_TRACKER.enterNested(startTime); // nesting can happen in two
>     ways, an event triggering another event, or when a nested event
>     loop is entered
>
>     Event returnedEvent = eventDispatcher.dispatchEvent(event, tail);
>
>     longendTime = System.currentTimeMillis();
>
>     longtimeSpentInNested = TIME_TRACKER.exitNested(endTime);
>
>     if(timeSpentInNested > 10) {
>
>     longtotal = endTime - startTime;
>
>     LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested +
>     "/"+ total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "):
>     "+ event);
>
>     }
>
>     returnreturnedEvent;
>
>     }
>
>     });
>
>     }
>
>     --John
>
>     On 05/08/2024 17:17, Thiago Milczarek Say?o wrote:
>>     Hi,
>>
>>     Interesting idea. We have this problem specially when Junior
>>     developers touch the code.
>>
>>     The other way around would be nice too - if some I/O task
>>     executes on the FX thread.
>>
>>     This can make the OS think the application hanged and offer to
>>     kill it, since it won't respond to "pings". And I/O tasks
>>     processing time may vary between installations. Also causes
>>     "white screens" since it blocks painting.
>>
>>     -- Thiago.
>>
>>     Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth
>>     <kevin.rushforth at oracle.com> escreveu:
>>
>>>         Wouldn't it be better to implement this check in assert to
>>>         avoid any impact in production?
>>
>>         No. Using an assert in a case like this is an anti-pattern. A
>>         call to assert in a library such as JavaFX is only
>>         appropriate for checking an invariant in internal logic. If
>>         we are going to go down this route of doing a thread check
>>         when mutating properties of "live" nodes, we will throw the
>>         same IllegalStateException that is currently thrown by some
>>         methods on Stage and Scene.
>>
>>         As for the proposal itself, adding this check is an
>>         interesting idea. We considered doing this back in the JDK 7
>>         (JavaFX 2) time frame, but decided not to pursue it then. I
>>         think the idea is worth further discussion. I would limit any
>>         thread checking to setting the property. It would be too
>>         restrictive (and largely unnecessary) to prevent reading a
>>         property from the application thread.
>>
>>         The things to consider would be:
>>
>>         1. What is the performance hit of doing this check on the
>>         setting of every property?
>>         2. What is the effect on bound properties?
>>         3. How intrusive is it in the code?
>>         4. Should we add a property to enable / disable the thread
>>         check, possibly a three- or four-valued property
>>         (allow|warn|debug?|deny), as was recently done in JEP 471 for
>>         sun.misc.Unsafe memory access methods. If so, what should the
>>         default be?
>>
>>         My quick take is that if this can be done in a minimally
>>         intrusive manner with low overhead, we should consider
>>         pursing this. As for 4, my preference would be to add a
>>         three- or four-valued system property to control the check,
>>         with "warn" as the default initially, changing the default to
>>         "disallow" in a subsequent version. This would, of course,
>>         require a lot of testing.
>>
>>         -- Kevin
>>
>>
>>         On 8/4/2024 8:40 PM, quizynox wrote:
>>>         Hello,
>>>
>>>         Wouldn't it be better to implement this check in assert to
>>>         avoid any impact in production?
>>>
>>>         ??, 5 ???. 2024??. ? 03:30, John Hendrikx
>>>         <john.hendrikx at gmail.com>:
>>>
>>>             Hi list,
>>>
>>>             I know of quite some bugs and users that have been
>>>             bitten by the
>>>             threading model used by JavaFX.? Basically, anything
>>>             directly or
>>>             indirectly linked to an active Scene must be accessed on
>>>             the FX thread.
>>>             However, as FX also allows manipulating nodes and
>>>             properties before
>>>             they're displayed, there can be no "hard" check
>>>             everywhere to ensure we
>>>             are on the FX thread (specifically, in properties).
>>>
>>>             Now, I think this situation is annoying, as a simple
>>>             mistake where a
>>>             Platform.runLater wrapper was forgotten usually results
>>>             in programs
>>>             operating mostly flawlessly, but then fail in mysterious
>>>             and random and
>>>             hard to reproduce ways.? The blame is often put on FX as
>>>             the resulting
>>>             exceptions will almost never show the user code which
>>>             was the actual
>>>             culprit.? It can result in FX being perceived as
>>>             unstable or buggy.
>>>
>>>             So I've been thinking if there isn't something we can do
>>>             to detect these
>>>             bugs originating from user code much earlier, similar to
>>>             the
>>>             `ConcurrentModificationException` the collection classes
>>>             do when
>>>             accessed in nested or concurrent contexts.
>>>
>>>             I think it may be possible to have properties check
>>>             whether they're part
>>>             of an active scene without too much of an performance
>>>             impact, possibly
>>>             even behind a switch. It would work like this:
>>>
>>>             Properties involved with Nodes will have an associated
>>>             bean instance
>>>             (`getBean`).? This is an object, but we could check here
>>>             if this
>>>             instance implements an interface:
>>>
>>>             ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
>>>             ??????????? if (x.isPartOfActiveScene() &&
>>>             !isOnFxThread()) {
>>>             ???????????????? throw new
>>>             IllegalStateException("Property must only be
>>>             used from the FX Application Thread");
>>>             ??????????? }
>>>             ????? }
>>>
>>>             This check could be done on every set of the property,
>>>             and potentially
>>>             on every get as well.? It should be relatively cheap,
>>>             but will expose
>>>             problematic code patterns at a much earlier stage.?
>>>             There's a chance
>>>             that this will "break" some programs that seemed to be
>>>             behaving
>>>             correctly as well, so we may want to put it behind a
>>>             switch until such
>>>             programs (or libraries) can be fixed.
>>>
>>>             What do you all think?
>>>
>>>             --John
>>>
>>>             (*) Names of methods/interfaces are only used for
>>>             illustration purposes,
>>>             we can think of good names if this moves forward.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240809/d2823815/attachment-0001.htm>

From john.hendrikx at gmail.com  Fri Aug  9 19:19:50 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 9 Aug 2024 21:19:50 +0200
Subject: Detecting threading problems faster
In-Reply-To: <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
References: <4724d08b-b7dd-410c-b483-3b03d260b622@gmail.com>
 <CAASO9vSabGPOVjh7dpGm=Z+SiWshWZS7fb2kb7afrsrfLAfOyA@mail.gmail.com>
 <98d2fc8c-4922-43b0-9f89-93b40f188ddd@oracle.com>
 <CAAP_wumFGfLeXc3yyt9NcVrAvbSH-MaJdK2rauYuHoiYtTFAiw@mail.gmail.com>
 <9790a3ce-1d79-414c-b5c5-9c1a5141c784@gmail.com>
 <CAAP_wu=TuDzUCLWKRM83Rr_FQPPxK4U4zmF2wFx-LyZB8YarDQ@mail.gmail.com>
Message-ID: <cde55c0e-6c69-4d8d-a39c-02340b626fc1@gmail.com>

I noticed the copy/paste I did wasn't great, you don't need the `future` 
variable or code that manipulates it (I had a different version before, 
but this works quite well for now)

--John

On 08/08/2024 12:47, Thiago Milczarek Say?o wrote:
> Nice! I will steal it if you don't mind.
>
> Em qua., 7 de ago. de 2024 ?s 15:55, John Hendrikx 
> <john.hendrikx at gmail.com> escreveu:
>
>     For detecting long running tasks on the FX thread, there are some
>     other options which you can do as a user (but perhaps we can
>     support it directly within FX).? I use this kind of code to detect
>     long running things on the FX thread:
>
>     /**
>
>     * Adds a slow event warning whenever an event takes more than 10
>     msto process. Note
>
>     * that time spent in nested event loops cannot be properly taken
>     into account as time
>
>     * spent in nested event loops will be part of the event that
>     triggered it giving false
>
>     * positives. In order for this time to be accurately reflected,
>     the methods to enter
>
>     * a nested event loop in this class should be used instead of the
>     ones in {@link Platform}.
>
>     *
>
>     * @paramscene a Scene to which to add the slow event warning
>     detection, cannot be null
>
>     */
>
>     publicstaticvoidaddSlowEventWarning(Scene scene) {
>
>     finalEventDispatcher eventDispatcher = scene.getEventDispatcher();
>
>     scene.setEventDispatcher(newEventDispatcher() {
>
>     privateScheduledFuture<StackTraceElement[]> future;
>
>     @Override
>
>     publicEvent dispatchEvent(Event event, EventDispatchChain tail) {
>
>     if(future!= null) {
>
>     future.cancel(false);
>
>     }
>
>     longstartTime = System.currentTimeMillis();
>
>     TIME_TRACKER.enterNested(startTime); // nesting can happen in two
>     ways, an event triggering another event, or when a nested event
>     loop is entered
>
>     Event returnedEvent = eventDispatcher.dispatchEvent(event, tail);
>
>     longendTime = System.currentTimeMillis();
>
>     longtimeSpentInNested = TIME_TRACKER.exitNested(endTime);
>
>     if(timeSpentInNested > 10) {
>
>     longtotal = endTime - startTime;
>
>     LOGGER.warning("Slow Event (self/total: "+ timeSpentInNested +
>     "/"+ total + " ms @ level "+ TIME_TRACKER.getCurrentLevel() + "):
>     "+ event);
>
>     }
>
>     returnreturnedEvent;
>
>     }
>
>     });
>
>     }
>
>     --John
>
>     On 05/08/2024 17:17, Thiago Milczarek Say?o wrote:
>>     Hi,
>>
>>     Interesting idea. We have this problem specially when Junior
>>     developers touch the code.
>>
>>     The other way around would be nice too - if some I/O task
>>     executes on the FX thread.
>>
>>     This can make the OS think the application hanged and offer to
>>     kill it, since it won't respond to "pings". And I/O tasks
>>     processing time may vary between installations. Also causes
>>     "white screens" since it blocks painting.
>>
>>     -- Thiago.
>>
>>     Em seg., 5 de ago. de 2024 ?s 11:59, Kevin Rushforth
>>     <kevin.rushforth at oracle.com> escreveu:
>>
>>>         Wouldn't it be better to implement this check in assert to
>>>         avoid any impact in production?
>>
>>         No. Using an assert in a case like this is an anti-pattern. A
>>         call to assert in a library such as JavaFX is only
>>         appropriate for checking an invariant in internal logic. If
>>         we are going to go down this route of doing a thread check
>>         when mutating properties of "live" nodes, we will throw the
>>         same IllegalStateException that is currently thrown by some
>>         methods on Stage and Scene.
>>
>>         As for the proposal itself, adding this check is an
>>         interesting idea. We considered doing this back in the JDK 7
>>         (JavaFX 2) time frame, but decided not to pursue it then. I
>>         think the idea is worth further discussion. I would limit any
>>         thread checking to setting the property. It would be too
>>         restrictive (and largely unnecessary) to prevent reading a
>>         property from the application thread.
>>
>>         The things to consider would be:
>>
>>         1. What is the performance hit of doing this check on the
>>         setting of every property?
>>         2. What is the effect on bound properties?
>>         3. How intrusive is it in the code?
>>         4. Should we add a property to enable / disable the thread
>>         check, possibly a three- or four-valued property
>>         (allow|warn|debug?|deny), as was recently done in JEP 471 for
>>         sun.misc.Unsafe memory access methods. If so, what should the
>>         default be?
>>
>>         My quick take is that if this can be done in a minimally
>>         intrusive manner with low overhead, we should consider
>>         pursing this. As for 4, my preference would be to add a
>>         three- or four-valued system property to control the check,
>>         with "warn" as the default initially, changing the default to
>>         "disallow" in a subsequent version. This would, of course,
>>         require a lot of testing.
>>
>>         -- Kevin
>>
>>
>>         On 8/4/2024 8:40 PM, quizynox wrote:
>>>         Hello,
>>>
>>>         Wouldn't it be better to implement this check in assert to
>>>         avoid any impact in production?
>>>
>>>         ??, 5 ???. 2024??. ? 03:30, John Hendrikx
>>>         <john.hendrikx at gmail.com>:
>>>
>>>             Hi list,
>>>
>>>             I know of quite some bugs and users that have been
>>>             bitten by the
>>>             threading model used by JavaFX.? Basically, anything
>>>             directly or
>>>             indirectly linked to an active Scene must be accessed on
>>>             the FX thread.
>>>             However, as FX also allows manipulating nodes and
>>>             properties before
>>>             they're displayed, there can be no "hard" check
>>>             everywhere to ensure we
>>>             are on the FX thread (specifically, in properties).
>>>
>>>             Now, I think this situation is annoying, as a simple
>>>             mistake where a
>>>             Platform.runLater wrapper was forgotten usually results
>>>             in programs
>>>             operating mostly flawlessly, but then fail in mysterious
>>>             and random and
>>>             hard to reproduce ways.? The blame is often put on FX as
>>>             the resulting
>>>             exceptions will almost never show the user code which
>>>             was the actual
>>>             culprit.? It can result in FX being perceived as
>>>             unstable or buggy.
>>>
>>>             So I've been thinking if there isn't something we can do
>>>             to detect these
>>>             bugs originating from user code much earlier, similar to
>>>             the
>>>             `ConcurrentModificationException` the collection classes
>>>             do when
>>>             accessed in nested or concurrent contexts.
>>>
>>>             I think it may be possible to have properties check
>>>             whether they're part
>>>             of an active scene without too much of an performance
>>>             impact, possibly
>>>             even behind a switch. It would work like this:
>>>
>>>             Properties involved with Nodes will have an associated
>>>             bean instance
>>>             (`getBean`).? This is an object, but we could check here
>>>             if this
>>>             instance implements an interface:
>>>
>>>             ????? if (getBean() instanceof MayBePartOfSceneGraph x) {
>>>             ??????????? if (x.isPartOfActiveScene() &&
>>>             !isOnFxThread()) {
>>>             ???????????????? throw new
>>>             IllegalStateException("Property must only be
>>>             used from the FX Application Thread");
>>>             ??????????? }
>>>             ????? }
>>>
>>>             This check could be done on every set of the property,
>>>             and potentially
>>>             on every get as well.? It should be relatively cheap,
>>>             but will expose
>>>             problematic code patterns at a much earlier stage.?
>>>             There's a chance
>>>             that this will "break" some programs that seemed to be
>>>             behaving
>>>             correctly as well, so we may want to put it behind a
>>>             switch until such
>>>             programs (or libraries) can be fixed.
>>>
>>>             What do you all think?
>>>
>>>             --John
>>>
>>>             (*) Names of methods/interfaces are only used for
>>>             illustration purposes,
>>>             we can think of good names if this moves forward.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240809/4d587f58/attachment-0001.htm>

From jhendrikx at openjdk.org  Fri Aug  9 19:45:41 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 9 Aug 2024 19:45:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
 <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
Message-ID: <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>

On Fri, 9 Aug 2024 13:36:34 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Clear, thanks MIchael.  I would suggest `Reconstructable` as the name, which seems more inline with interface naming (especially `Interpolatable`). Reads nice also:
>> 
>>     if (converter instanceof Reconstructable r) { ... }
>
> But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are).

Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". 

I also think I smell something fishy.  The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object.

The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty).  Although that method is also called `convert` it is only used by  `CssStyleHelper`, which is completely unrelated to parsing.  A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short).

There does not seem to be any overlap between these two purposes.  That is it to say, a style converter that is used for  decoding sub-properties is never used for parsing, and vice versa.  FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`).

I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split.  On the one hand, you have a style converter which uses `convert` for parsing.  On the other hand, you have `CssMetaData`, which when it has  sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on.

The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property.  This could either implement two interfaces, or it could just be two classes.

I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still.  This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further).

See here: #1533

Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f

Let me know if you feel this has merit.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712057854

From mfox at openjdk.org  Fri Aug  9 20:18:36 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 9 Aug 2024 20:18:36 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>

On Tue, 30 Jul 2024 18:26:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

The cloning of an event is necessary in order to update the `target` when the event is fired and the `source` when the event is passed to a handler. The alternative would be to modify those fields in-place which sounds like a bookkeeping nightmare particularly if an event is re-fired (something this PR does). I can see why the JavaFX designers decided to make copies instead.

@andy-goryachev-oracle wrote:
> a) If the EventDispatcher does something different like creating the new events, it is up to that ED to deal with consequences. It means the developer wants to create new events and not to have the link between the events.

An EventDispatcher that creates a new event without linking it to the original will break this PR. But that's a consequence you're creating. You can't say the developer is making a choice about event linking when the very notion is new with this PR.

I agree with @mstr2, the dispatch machinery has an existing publicly accessible mechanism for communicating whether an event was consumed and it works fine. The documentation might be fuzzy around the edges but that can be solved.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2278679307

From mstrauss at openjdk.org  Fri Aug  9 22:32:46 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 22:32:46 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v25]
In-Reply-To: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
Message-ID: <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>

> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
> 
> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
> 
> 
> Background {
>     fills = [
>         BackgroundFill {
>             fill = Color.RED
>         }
>     ]
> }
> 
> 
> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
> 
> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
> 
> More specifically, the following types will now implement `Interpolatable`.
> 
> - `Insets`
> - `Background`
> - `BackgroundFill`
> - `BackgroundImage`
> - `BackgroundPosition`
> - `BackgroundSize`
> - `Border`
> - `BorderImage`
> - `BorderStroke`
> - `BorderWidths`
> - `CornerRadii`
> - `Stop`
> - `Paint` and all of its subclasses
> - `Margins` (internal type)
> - `BorderImageSlices` (internal type)
> 
> ## Interpolation of composite objects
> 
> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
> 
> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
> 
> | Interpolation type | Description |
> |---|---|
> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ...

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

  remove StyleConverter.WithReconstructionSupport

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1522/files
  - new: https://git.openjdk.org/jfx/pull/1522/files/a0557b8f..9bdea0a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=24
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=23-24

  Stats: 99 lines in 7 files changed: 62 ins; 27 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/jfx/pull/1522

From mstrauss at openjdk.org  Fri Aug  9 22:38:48 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 9 Aug 2024 22:38:48 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
 <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
 <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>
Message-ID: <A9SIgse-t6rhEO_zYew-d8yuPx1caNjmRNw2-kkz4qM=.b09ffb0b-9dd8-48cd-ad34-078ffc59cbe0@github.com>

On Fri, 9 Aug 2024 19:42:56 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> But the converter is not reconstructable (in comparison to Interpolatable, which is something the marked types actually are).
>
> Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". 
> 
> I also think I smell something fishy.  The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object.
> 
> The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty).  Although that method is also called `convert` it is only used by  `CssStyleHelper`, which is completely unrelated to parsing.  A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short).
> 
> There does not seem to be any overlap between these two purposes.  That is it to say, a style converter that is used for  decoding sub-properties is never used for parsing, and vice versa.  FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`).
> 
> I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split.  On the one hand, you have a style converter which uses `convert` for parsing.  On the other hand, you have `CssMetaData`, which when it has  sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on.
> 
> The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property.  This could either implement two interfaces, or it could just be two classes.
> 
> I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still.  This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further).
> 
> See here: #1533
> 
> Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f
> 
> Let me know if you feel this has merit.

I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations.

I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712306610

From mstrauss at openjdk.org  Sat Aug 10 01:07:42 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 10 Aug 2024 01:07:42 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v22]
In-Reply-To: <ozPGzeRYhOf-X6CBswLnlON3FDnoevHcTgnLVf2kUzo=.459a35ca-c37d-40f8-b89d-0de71117b712@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <eUi_GvFh8WI0Auy_K6SNaADrtBs3suqX1ef-_tdNPHY=.44d37d22-c9ee-4ae6-b294-ac73feaf3f05@github.com>
 <-jabO10B6k7F1v0fzRASTO9h3CXy1uPdwfCTzgX52u8=.c422abee-cb24-4a1e-8c71-79c626bddd01@github.com>
 <FLuoepBushZGQ6AdAcnO4TP53iJkmG4wpPyaOktSA5M=.3e4f7012-0cff-442f-936e-6348b3f50f90@github.com>
 <ozPGzeRYhOf-X6CBswLnlON3FDnoevHcTgnLVf2kUzo=.459a35ca-c37d-40f8-b89d-0de71117b712@github.com>
Message-ID: <msBhVfXMkpGmbAHp1yn6R9cdFy8rahdGc6zjW8BbEk4=.92eb5ee5-666b-4268-9d06-a0c87897a03c@github.com>

On Fri, 9 Aug 2024 15:37:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `reconstruct` is a misnomer, as reconstruction is a two-step operation (`convertBack` followed by `convert`). To be fair, I don't like any of these better than `convertBack`, mostly because I want to stress that those two operations are closely related, and none of the alternatives evoke that sentiment. That being said, this is a minor API and I don't really mind either way, but absent a compelling reason, I'd prefer to stick to `convertBack`.
>
> That's fine, I just think `convertBack` implies an arrow of time or a preferred spatial direction.
> 
> Maybe `toMap()`, but as long as the method is sufficiently documented, we should be fine.  Naming _is_ hard.

I've moved this to an internal interface (it doesn't need to be public for this PR), so we can have the discussion later if we choose to make this API public (and if so, how we go about doing that).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712445361

From duke at openjdk.org  Sat Aug 10 07:12:37 2024
From: duke at openjdk.org (Loay Ghreeb)
Date: Sat, 10 Aug 2024 07:12:37 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
 [v2]
In-Reply-To: <TyTZ06z9bvapO74_LV_QbP83rkZkkB36ns6EH76vW9U=.15196399-34c1-4f6a-818f-383aa9ddbd95@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
 <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>
 <TyTZ06z9bvapO74_LV_QbP83rkZkkB36ns6EH76vW9U=.15196399-34c1-4f6a-818f-383aa9ddbd95@github.com>
Message-ID: <PmAGas3sgjYUZbzitMZha_DwtPFmeGC6v_kflBrcxyE=.a7f2b6eb-8d67-4e67-9117-5a91bf6372c7@github.com>

On Fri, 9 Aug 2024 19:11:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation.
> 
> So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements.

The issue isn?t just with adding new elements. It also affects the `TableView` that populated with items from a `SortedList`, The `SortedList`'s comparator is bound to the `TableView`'s comparator.
When the table is sorted by multiple columns, removing a column from the sort order should reorder the items. However, currently, removing any column from the sort order doesn't change the items order until all sorting columns are removed. At that point, the items returned to the default insertion order.

For example:
![image](https://github.com/user-attachments/assets/9ed8b2ea-9879-4dc9-a285-4d03be2d2691)

1. The initial order is [0, 1, 2, 3] (index column).
2. Sort by `Col1`, the order will be: [1, 0, 2, 3].
3. Add a second sort (Shift + Click) on `Col2`, the order will be: [1, 2, 3, 0].
4. Shift + Click again on `Col2` to sort in descending order: [1, 0, 3, 2].
5. Shift + Click again on `Col2` to remove the sort from `Col2`. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.

<details>
<summary> Code </summary>


import javafx.application.Application;
import javafx.beans.property.ReadOnlyObjectWrapper;
import javafx.collections.FXCollections;
import javafx.collections.ObservableList;
import javafx.collections.transformation.SortedList;
import javafx.scene.Scene;
import javafx.scene.control.TableColumn;
import javafx.scene.control.TableView;
import javafx.stage.Stage;

public class Main extends Application {

    @Override
    public void start(Stage primaryStage) {
        primaryStage.setScene(new Scene(createTableView()));
        primaryStage.show();
    }

    private TableView<Data> createTableView() {
        TableView<Data> tableView = new TableView<>();

        TableColumn<Data, Integer> indexColumn = new TableColumn<>("#");
        indexColumn.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().index()));
        indexColumn.setSortable(false);

        TableColumn<Data, Integer> column1 = new TableColumn<>("Col1");
        column1.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().val1()));

        TableColumn<Data, Integer> column2 = new TableColumn<>("Col2");
        column2.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().val2()));

        tableView.getColumns().addAll(indexColumn, column1, column2);

        ObservableList<Data> data = FXCollections.observableArrayList(
                new Data(0, 5, 4),
                new Data(1, 1, 7),
                new Data(2, 5, 2),
                new Data(3, 5, 3)
        );

        SortedList<Data> sortedData = new SortedList<>(data);

        sortedData.comparatorProperty().bind(tableView.comparatorProperty());
        tableView.setItems(sortedData);
        return tableView;
    }

    public record Data(int index, int val1, int val2) {
    }
}


</details>

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

PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2279897597

From jhendrikx at openjdk.org  Sat Aug 10 11:27:41 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 10 Aug 2024 11:27:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <A9SIgse-t6rhEO_zYew-d8yuPx1caNjmRNw2-kkz4qM=.b09ffb0b-9dd8-48cd-ad34-078ffc59cbe0@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
 <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
 <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>
 <A9SIgse-t6rhEO_zYew-d8yuPx1caNjmRNw2-kkz4qM=.b09ffb0b-9dd8-48cd-ad34-078ffc59cbe0@github.com>
Message-ID: <S-kmxTQDxji9TkZo5DiyQa1XtjKsej5poY-J4-GMYwU=.43b06d2c-e836-438d-878d-4948c35cecf6@github.com>

On Fri, 9 Aug 2024 22:36:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Sorry to keep harping on this, but so far, I think all the options are quite poor from the perspective of the user, and from a perspective of "could it have been designed this way in the first place". 
>> 
>> I also think I smell something fishy.  The `StyleConverter` seems to serve two unrelated purposes. One is to convert raw parsed values for the CSS parser (`convert(ParsedValue, Font)`) to a Java object.
>> 
>> The other is to support sub-properties (which you can also detect by checking if `CssMetaData.getSubProperties` is not empty).  Although that method is also called `convert` it is only used by  `CssStyleHelper`, which is completely unrelated to parsing.  A more accurate name for that method would be "consolidateSubPropertyValues" (and the opposite would then be something like "extractSubPropertyValues", or `consolidate` and `extract` for short).
>> 
>> There does not seem to be any overlap between these two purposes.  That is it to say, a style converter that is used for  decoding sub-properties is never used for parsing, and vice versa.  FX also does not support special syntax for specifying say a border in short hand form (like `-fx-border: dashed red`).
>> 
>> I think it may be a good idea to perhaps have a look if these purposes shouldn't just be split.  On the one hand, you have a style converter which uses `convert` for parsing.  On the other hand, you have `CssMetaData`, which when it has  sub-properties **must** support a back-and-forth translation (`convert` + `convertBack`) -- this is currently not enforced (ie. you can create `CssMetaData` with sub-properties but then **not** implement `convert(Map)` in the used style converter... this causes problems later on.
>> 
>> The only CSS property currently that supports both short-hand and sub-properties is actually the newly introduced `transition` property.  This could either implement two interfaces, or it could just be two classes.
>> 
>> I've done a quick attempt to do such a split (not looking too much at API) and the whole thing compiles and passes all tests still.  This is surprising, because I deleted several pieces of code, that are apparently never used (or perhaps not tested for, we can investigate this further).
>> 
>> See here: #1533
>> 
>> Diff: https://github.com/openjdk/jfx/pull/1533/commits/8f6d1e56a43068184599ad1ea47b4da98eb70bff#diff-fc96cf3204909a6110e64c37a935927be56efedc9f3f4f6f6843cc4fa7da5a1f
>> 
>> Let me know if you feel this has merit.
>
> I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations.
> 
> I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time.

Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be.  With this API removed, I think we can get this merged.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712627157

From jhendrikx at openjdk.org  Sat Aug 10 11:36:38 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 10 Aug 2024 11:36:38 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <S-kmxTQDxji9TkZo5DiyQa1XtjKsej5poY-J4-GMYwU=.43b06d2c-e836-438d-878d-4948c35cecf6@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
 <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
 <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>
 <A9SIgse-t6rhEO_zYew-d8yuPx1caNjmRNw2-kkz4qM=.b09ffb0b-9dd8-48cd-ad34-078ffc59cbe0@github.com>
 <S-kmxTQDxji9TkZo5DiyQa1XtjKsej5poY-J4-GMYwU=.43b06d2c-e836-438d-878d-4948c35cecf6@github.com>
Message-ID: <JMOeSBxzjOSz-dhf10hk4d3RkGYBM-K1lP01ppb3Bwk=.e5defbca-2862-4b51-bcd7-8cfad69cfc6c@github.com>

On Sat, 10 Aug 2024 11:24:34 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I also think that we're probably dealing with two different things that are mixed up in `StyleConverter`. But instead of having this discussion here, it probably makes more sense to have it in the context of [JDK-8333121](https://bugs.openjdk.org/browse/JDK-8333121) because it seems relevant to eventually support both short-hand and long-hand property notations.
>> 
>> I've renamed `WithReconstructionSupport` to `SubPropertyConverter` and moved it to an internal package for now. Since both `BackgroundConverter` and `BorderConverter` are not public, we can change it any way we want at a later time.
>
> Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be.  With this API removed, I think we can get this merged.

One more thing.  You introduced `transition` short hand version.  Is it maybe a good idea to not do this yet until we have a better idea how to deal with them?  Shorthand properties are just a convenience; the feature will work without them.  If it was already released, then can ignore this as we're too late.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712628315

From jhendrikx at openjdk.org  Sat Aug 10 11:55:35 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 10 Aug 2024 11:55:35 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
 [v2]
In-Reply-To: <PmAGas3sgjYUZbzitMZha_DwtPFmeGC6v_kflBrcxyE=.a7f2b6eb-8d67-4e67-9117-5a91bf6372c7@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
 <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>
 <TyTZ06z9bvapO74_LV_QbP83rkZkkB36ns6EH76vW9U=.15196399-34c1-4f6a-818f-383aa9ddbd95@github.com>
 <PmAGas3sgjYUZbzitMZha_DwtPFmeGC6v_kflBrcxyE=.a7f2b6eb-8d67-4e67-9117-5a91bf6372c7@github.com>
Message-ID: <hrR1XWkDosSrxVmAvkIBy9xeOpq0-ReyPHYUqsVYHkc=.3e52f3a2-d563-4199-90f4-61a3e6e613ac@github.com>

On Sat, 10 Aug 2024 07:10:03 GMT, Loay Ghreeb <duke at openjdk.org> wrote:

> Shift + Click again on Col2 to remove the sort from Col2. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.

Why is that the expected order?  It is "a" possible, but valid order.  When only sorting on `Col1` then in my opinion [1, 0, 2, 3], [1, 0, 3, 2], [1, 2, 0, 3], etc.. are all valid sort orders.

If we want to distinguish between equal elements to give them a fixed sub-ordering (and the inverse one I suppose when the sort is descending) then what should the distinguishing factor be?  Its position in the underlying unsorted list?  The time it was added to the underlying list?  They need not be the same.  Using the position in the underlying list could be quite random if the source of the list doesn't guarantee a fixed position (from an unsorted database query for example).

What if the underlying list is another sorted list or a filtered list, can we even rely on the indices those provide?

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

PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2281285791

From mstrauss at openjdk.org  Sat Aug 10 14:08:40 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 10 Aug 2024 14:08:40 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v18]
In-Reply-To: <JMOeSBxzjOSz-dhf10hk4d3RkGYBM-K1lP01ppb3Bwk=.e5defbca-2862-4b51-bcd7-8cfad69cfc6c@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <Iaczm8orVDWHyWynpT6zJ0reKSDvPyi13T4ALPGriGo=.ff00c102-fe21-40cc-85fe-c4fd3f64ca3a@github.com>
 <opW3gfhcW6MMmLSATkyLsn0els8AnV9dKL_EpS-31iw=.7a6df295-4291-41b5-82fa-89695d704e1c@github.com>
 <hcwPjNgeIb4KdPCsT1s2W9A40EZG9AQfuMd9J6a8kDk=.da2467b8-dd26-41ec-9c02-0eb921a02601@github.com>
 <7h549vp05HqhgEL5Y39HbgX2dKOFR3-whufJVF7NiEM=.8d798285-74e2-4cbc-806a-4c55ab033b6c@github.com>
 <ZhfEd4fqZ2KHP9Vo7mQSvJn7tu4HAprwplXEex0q5Qs=.d34de6dc-f610-4b5f-915a-f42f871db4c5@github.com>
 <-KqcPLUE0D598kDjt6FnzlzAVhGj_GI5EfqwdnFDltM=.6ae60863-7262-4b6e-9ede-c5c4572931cc@github.com>
 <zgwPFKWkZm8lVHef3J2M-HBLBYDNMUUe-ezALrzocdw=.6177008a-ec7a-43a8-8500-f0272459caca@github.com>
 <Gzx51C1qMSbsmWunB-tpF2ZQFhUxL8lH_mlsgd-g6zc=.98be4b22-9757-4043-af6a-6f558500399f@github.com>
 <cBl764sBDWnLb0irLTzWWpv56NroMC4__1BFnpfYeOM=.9b80209d-c14d-410e-b1d9-fb68ce9129b1@github.com>
 <sI8iVz6mZkP1tPJ9RsukKQX9HKPslP_IY-U
 ahOhfnE8=.5b15c7c1-5e3b-49a1-b4d7-0e47fc124b3e@github.com>
 <mmFHswWmp_EvCxb_ISISNKlLtcY3KVDDMiSHzEF74qU=.b05be361-ce5b-4d00-8e45-35ba0c48e7f9@github.com>
 <UU_P6JiM9obM6G-BbIcD-uRc4d9pAnGhXf39bhwuVMY=.eb3995b0-b624-4bf1-901c-a4223e748fea@github.com>
 <xNUhpaVdlN5F-47HHqotXVcfr07jPWhncL9h02Edjoo=.3cd9e687-7b93-4ee7-a915-b3dd73546036@github.com>
 <A9SIgse-t6rhEO_zYew-d8yuPx1caNjmRNw2-kkz4qM=.b09ffb0b-9dd8-48cd-ad34-078ffc59cbe0@github.com>
 <S-kmxTQDxji9TkZo5DiyQa1XtjKsej5poY-J4-GMYwU=.43b06d2c-e836-438d-878d-4948c35cecf6@github.com>
 <JMOeSBxzjOSz-dhf10hk4d3RkGYBM-K1lP01ppb3Bwk=.e5defbca-2862-4b51-bcd7-8cfad69cfc6c@github.com>
Message-ID: <0eR3BWkeKqg7_CTsngqHnlHyoQXDZ2uBl1DY8ZUIuUo=.2a1acb89-14bb-4c13-b3a1-718458378168@github.com>

On Sat, 10 Aug 2024 11:33:43 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Yes, that's a good idea, I was mainly worried about introducing a new public API that we can't remove later when we haven't figured out yet what the best direction would be.  With this API removed, I think we can get this merged.
>
> One more thing.  You introduced `transition` short hand version.  Is it maybe a good idea to not do this yet until we have a better idea how to deal with them?  Shorthand properties are just a convenience; the feature will work without them.  If it was already released, then can ignore this as we're too late.

The `transition` shorthand is already on track to be released, and we?re deep into RDP2.

However, `TransitionDefinitionConverter` is not public API, it?s implementation can move around freely.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1712646742

From mfox at openjdk.org  Sat Aug 10 16:13:35 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 10 Aug 2024 16:13:35 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <RyXIJbS9fGSU5upaXoad-FyJxjy9in8IoCQmq98VMCA=.94da2730-7e3a-4fc8-ba80-b69a28fb1cb4@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
 <RyXIJbS9fGSU5upaXoad-FyJxjy9in8IoCQmq98VMCA=.94da2730-7e3a-4fc8-ba80-b69a28fb1cb4@github.com>
Message-ID: <ULFCdTRd2NjwMVA-L0mU2jWlidmYtRp7FBJojhZHDV0=.3d29582e-c83e-413d-9513-69ab2ab16568@github.com>

On Thu, 8 Aug 2024 17:38:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Thinking out loud for a moment: wouldn't it be better to use a kind of EventFilter specifically for the shortcuts, before the normal dispatching happens?

I think I see where you?re going here. We could send the KeyEvent into the scene graph and then catch it on the back end to be processed by the system menu bar. If the KeyEvent reaches the KeyboardAcceleratorHandler we know that it?s time for the menu bar to process it.

I?ve thought about this but it would tricky to implement. Currently we only send a subset of key events to the system menu bar (the one?s that are delivered to us via performKeyEquivalent). Once a KeyEvent is injected into the scene graph we lose track of whether it was generated by performKeyEquivalent or keyDown. We could also see KeyEvents that weren?t created by glass (anyone can create one). We would have to find a way to sort this out on the back end.

What truly makes me nervous is how we would have to alter the normal performKeyEquivalent flow. Usually NSApplication controls the order in which key equivalents are presented to different components (windows, views, the system menu bar, etc.) To implement this alternative approach we would have to short circuit the NSApplication flow and present events to the system menu bar manually.

This PR is the most conservative one I could come up with since it doesn?t change the order of event processing and fits into the normal performKeyEquivalent flow that NSApplication expects. It just avoids double-processing of the same event.

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2282197287

From mmack at openjdk.org  Sat Aug 10 16:21:11 2024
From: mmack at openjdk.org (Markus Mack)
Date: Sat, 10 Aug 2024 16:21:11 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v3]
In-Reply-To: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com>
Message-ID: <eGESHevviPz0wEOlPbqvtLJfbABhEO0NPupxQeJuwSQ=.cf2215a9-bfd6-4943-805d-e12678f05c59@github.com>

On Sat, 13 Jul 2024 10:00:31 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> This PR is a fix for another IOOBE that I discovered while working on #1476.
>> 
>> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
>> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
>> 
>> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
>> 
>> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
>> 
>> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
>> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.
>
> Markus Mack has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix "negative" style class when series is changed

I've added asserts verifying that the "negative" style class is added to the relevant tests, plus a new test to assert it is removed when data is changed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2282198878

From mmack at openjdk.org  Sat Aug 10 16:21:12 2024
From: mmack at openjdk.org (Markus Mack)
Date: Sat, 10 Aug 2024 16:21:12 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v3]
In-Reply-To: <w6XOToXmFm8cNl4lZRTRuP_mFRZxfUxRi6dTbQ7mKeU=.6a7beeb6-7389-4bde-bb8c-7d74f0836ead@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com>
 <w6XOToXmFm8cNl4lZRTRuP_mFRZxfUxRi6dTbQ7mKeU=.6a7beeb6-7389-4bde-bb8c-7d74f0836ead@github.com>
Message-ID: <scO-eyLdWzcbgHMICyv3yS4Sb6mvwaAz3v87zW3hJd4=.1faaaeaf-6e2e-4dc1-82f8-362d02cc5389@github.com>

On Mon, 15 Jul 2024 16:32:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Markus Mack has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix "negative" style class when series is changed
>
> modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java line 305:
> 
>> 303:         BarChart<String, Number> chart = new BarChart<>(new CategoryAxis(), new NumberAxis());
>> 304:         XYChart.Series<String, Number> series = new XYChart.Series<>();
>> 305:         chart.getData().add(series);
> 
> speaking of negative values - could we check **all** the possible ways where the 'negative' class is added?  or removed?
> 
> I think it might be possible to add a check to the exiting tests, to reuse the setup.
> 
> Lastly, I think we also need to test the case when the data point becomes non-negative after explicit XYChart.Data.setValue(), do you think?

good idea, done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1488#discussion_r1712669740

From mmack at openjdk.org  Sat Aug 10 16:21:11 2024
From: mmack at openjdk.org (Markus Mack)
Date: Sat, 10 Aug 2024 16:21:11 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v4]
In-Reply-To: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
Message-ID: <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>

> This PR is a fix for another IOOBE that I discovered while working on #1476.
> 
> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
> 
> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
> 
> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
> 
> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.

Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - test "negative" style class in BarChartTest tests
 - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
 - fix "negative" style class when series is changed
 - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
   
   # Conflicts:
   #	modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java
 - BarChart: Fix adding non-empty series
 - BarChart: Add styleClass "negative" for added data

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

Changes: https://git.openjdk.org/jfx/pull/1488/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=03
  Stats: 125 lines in 2 files changed: 94 ins; 28 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1488.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488

PR: https://git.openjdk.org/jfx/pull/1488

From mmack at openjdk.org  Sat Aug 10 16:24:36 2024
From: mmack at openjdk.org (Markus Mack)
Date: Sat, 10 Aug 2024 16:24:36 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v3]
In-Reply-To: <B5JALtelFxRa8y9yqXWZOJ1GtTJ7AoFG-ZS9NKA7b-U=.1e86df55-9305-46f7-b9a9-7395f4dc8e3b@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com>
 <B5JALtelFxRa8y9yqXWZOJ1GtTJ7AoFG-ZS9NKA7b-U=.1e86df55-9305-46f7-b9a9-7395f4dc8e3b@github.com>
Message-ID: <oBOLwTZ72oklGltK7e0ZS02UNkPvzBuuRzqCDUX-7_g=.ba1d4311-56dc-49ff-ab93-0b591302f5f8@github.com>

On Mon, 15 Jul 2024 16:42:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I am going to ask this question - unrelated to this PR, but in the context of this PR.
> 
> Consider the case of a context menu, where the application needs to know the data point from the screen/local coordinates.
> 
> Currently, we can get the Node from the Data instance (XYChart.Data.node property), but not the other way around - that is, given the chart, and given the PickResult of a MouseEvent, it is impossible to get the data point corresponding to a Node. In other words, we have the model->view path but not the view->model one.
> 
> In theory, the app developer could monitor the `node` property of Data and use `Node.getProperties()` map to set the Data instance on the node, or they could iterate through all the visible data points, matching the node with the data point, so it is not a big issue.
> 
> I am interested in your opinion. What do you think?

Good question, I'd say it is easy enough to loop through the chart's data items to find the correct node in that case, so I don't see a need to add this on the jfx side.
Also, currently Data.getNode() just returns an opaque Node, so I don't see a good place where to expose that without either changing that API. Adding an Node.getProperties() entry should probably be done only by application developers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2282199843

From kcr at openjdk.org  Sat Aug 10 17:26:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 10 Aug 2024 17:26:36 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <_HVoTjY-P7QxnDqYzPXGqcwWR20Hi1ZcdQCyZJleZOs=.75202cb0-e6e4-467e-9cca-965a1260a89e@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

@tiainen Do you want a chance to review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2282217801

From kcr at openjdk.org  Sat Aug 10 17:28:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 10 Aug 2024 17:28:35 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image
In-Reply-To: <B3jI0euuBGk8P6xtgy46o_vDAYYYYRWiiauxAMJ58Us=.f2582bf6-285a-404e-b66f-94c8fe729b2b@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <B3jI0euuBGk8P6xtgy46o_vDAYYYYRWiiauxAMJ58Us=.f2582bf6-285a-404e-b66f-94c8fe729b2b@github.com>
Message-ID: <ksxWZbcQvqwze7ea2aB_WtbW3r5kYa6-3DH39_1INZk=.1f49bdc6-0565-4c87-b37a-8b98e105eadc@github.com>

On Thu, 8 Aug 2024 16:01:59 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> I'm testing this PR, and I see that on macOS the offsets are now taken into account. 
> 
> However, comparing to Windows the behaviour is different:
> 
> - On Windows, offset 0,0 means the cursor is at the most top-left coordinates of the dragView image. Setting positive offsets in x, y goes to the right and down of the image (which goes in line with the usual JavaFX coordinate system)
> 
> - On macOS, with this PR, offset 0, 0 is at the centre of the dragView image, and positive offsets go to the opposite direction
> 
> From the test attached to the issue, and with this PR:
> 
> 
> WritableImage snapshot = source.snapshot(null, null);
> 
> db.setDragView(snapshot);
> db.setDragViewOffsetX(0);
> 
> db.setDragViewOffsetY(0);
> 
> on Windows -> cursor at the most top-left corner of the dragView
> on macOS -> cursor at the centre of the dragView.
> 
> And:
> 
> WritableImage snapshot = source.snapshot(null, null);
> 
> db.setDragView(snapshot);
> db.setDragViewOffsetX(snapshot.getWidth() / 2);
> 
> db.setDragViewOffsetY(snapshot.getHeight() / 2);
> 
> on Windows -> cursor at the centre of the dragView
> on macOS -> cursor at the most top-left corner of the dragView.
> 
> So I'd say macOS should do the same as Windows, and for that you could try:
> 
> -            dragPoint.x -= ([image size].width/2.0f);
> -            dragPoint.y -= ([image size].height/2.0f);
> +            // dragPoint.x -= ([image size].width/2.0f);
> +            // dragPoint.y -= ([image size].height/2.0f);
> 
> -                dragPoint.x += offset.x;
> -               dragPoint.y += offset.y;
> +               dragPoint.x -= offset.x;
> +               dragPoint.y -= offset.y;
> 
> 
> Does that make sense to you?

Reviewers: @jperedadnr @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2282218190

From mstrauss at openjdk.org  Sat Aug 10 18:02:41 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 10 Aug 2024 18:02:41 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v25]
In-Reply-To: <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
Message-ID: <r-DYvJWobjLYTBSvWeJwGrgWt-601tgL5W82kZe71X0=.15c2607c-6696-4d40-b55d-1541771db33c@github.com>

On Fri, 9 Aug 2024 22:32:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove StyleConverter.WithReconstructionSupport

CSS properties don't always correspond to JavaFX properties (for example, `-fx-background-color` has no corresponding JavaFX property, it is combined with other CSS properties and mapped to `backgroundProperty()`). It might be a good idea to add a column to the CSS property tables, indicating the animation type of each CSS property. It would look like this:

![animationtype](https://github.com/user-attachments/assets/4f1437f5-4b31-4800-aefa-ec7d7a80d95e)

However, this is a large documentation change in and of itself, and I strongly suggest to do this as part of [JDK-8338121](https://bugs.openjdk.org/browse/JDK-8338121) to keep this PR manageable and focused.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2282228208

From mfox at openjdk.org  Sat Aug 10 18:41:35 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 10 Aug 2024 18:41:35 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
Message-ID: <0EFkEwrKbfny1v9H1rfzTSPo_miMCpXKiUCe8MZuS5w=.4a2fc26c-1c62-4b7f-87c5-9f660e0eae6f@github.com>

On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar.
> 
> We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.
> 
> I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

I'm marking this PR as draft for now. Turns out we're relying on double-processing of key events to make IM's work.

macOS sends a navigation key to us via performKeyEquivalent. That includes Home, End, and any arrow key. Currently we let the scene graph act on the event first and if a TextInput control has the focus the event is usually consumed. If we stop processing the event (and we should since it's consumed) it will never reach the IM.

In other words, the current system relies on having the same navigation key event sent to both performKeyEquivalent and keyDown. It gets acted on twice, once by the TextInput control and again by the IM. This is wrong but prioritizing the TextInput control over the IM is more wrong.

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2282240246

From ashley.hales at gmail.com  Sun Aug 11 07:11:54 2024
From: ashley.hales at gmail.com (Ashley Hales)
Date: Sun, 11 Aug 2024 08:11:54 +0100
Subject: Fwd: Scene 3D objects throw exception on Android deivces
In-Reply-To: <CAM8NxRM-gb5c3p-VRwatRPSC+hwRty7diShRqzJSkDZ01imcGw@mail.gmail.com>
References: <CAM8NxRM-gb5c3p-VRwatRPSC+hwRty7diShRqzJSkDZ01imcGw@mail.gmail.com>
Message-ID: <CAM8NxRN2UA=GghdtgYeJRxgHbeH2kA6mg8nj-cBjR=3FD3fGeQ@mail.gmail.com>

Hi, I have been compiling a JavaFX app for Android using the Dalvik SDK. I
have managed to resolve all the dependencies and compile into an APK. This
APK will install on Android devices but doesn't work on all of them.

I have modified the HelloWorld app included with the Dalvik SDK to debug my
problem. It works on all of my devices with just a label on the screen but
as soon as I add a sphere into the scene it just displays a black screen on
some devices. I have searched on the internet and suggestions indicate that
this may be a memory issue but I have tried setting
android.monocle.stacksize = 12800 in the javafx.platform.properties but
this has had no effect. After reading other posts on the forum I was
wondering if this might be due to a lack of 3D support on embedded
(although this is an Android device).  I have tried modifying
the javafx.platform.properties by
setting android.com.sun.javafx.isEmbedded=false or
com.sun.javafx.experimental.embedded.3d=true
but neither have any effect.  I have also tried printing out the result of
Platform.isSupported(ConditionalFeature.SCENE3D) but confusingly this shows
true despite the error.

I have tested on a couple of devices so far.  The error occurs every time
on my MBOX MINIM8S II (Android 6.0.1) but never on my Samsung Galaxy Table
Model SM-T230 (Android 4.4.2)  device.

I have also shared the compiled APK on Google Drive which you may access
from
https://drive.google.com/file/d/1QLA21gg2g9-ODrKctSqac6pNC2cxzCtx/view?usp=drive_link
.

Here is the logcat report for the issue?

05-12 09:10:06.584 4053 4181 I ActivityManager: Start proc
8921:org.javafxports.helloworld/u0a56 for activity
org.javafxports.helloworld/javafxports.android.FXActivity
05-12 09:10:06.649 8921 8921 I art : Not late-enabling -Xcheck:jni (already
on)
05-12 09:10:06.731 8921 8921 I MultiDex: VM with version 2.1.0 has multidex
support
05-12 09:10:06.731 8921 8921 I MultiDex: install
05-12 09:10:06.731 8921 8921 I MultiDex: VM has multidex support, MultiDex
support library is disabled.
05-12 09:10:06.735 8921 8921 V FXActivity: Initializing JavaFX Platform,
using 8.60.9-SNAPSHOT
05-12 09:10:06.745 8921 8921 V FXActivity native: Loading JavaFXDalvik
library
05-12 09:10:06.751 8921 8921 I System.out: usetextureview = false,
useswipekeyboard = false
05-12 09:10:06.753 8921 8921 V FXActivity: onCreate called, using
8.60.9-SNAPSHOT
05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue
instance created.
05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue started
05-12 09:10:06.758 4172 4172 V PhoneStatusBar: setLightsOn(true)
05-12 09:10:06.789 8921 8921 V FXActivity native: appDataDir:
/data/user/0/org.javafxports.helloworld
05-12 09:10:06.790 8921 8921 V FXActivity: onStart
05-12 09:10:06.790 8921 8921 V FXActivity: onResume
05-12 09:10:06.827 8921 8921 V FXEntity: Surface created.
05-12 09:10:06.828 8921 8921 V FXActivity native: [JVDBG] SURFACE created
native android window at 0xf4a94608, surface = 0xffda7390
05-12 09:10:06.970 8921 8921 I System.out: user.locale=en-US
05-12 09:10:06.970 8921 8921 I System.out: monocle.stackSize=128000
05-12 09:10:06.970 8921 8921 I System.out: prism.text=native
05-12 09:10:06.970 8921 8921 I System.out: java.vendor.url=
http://www.android.com/
05-12 09:10:06.970 8921 8921 I System.out: java.ext.dirs=
05-12 09:10:06.970 8921 8921 I System.out: line.separator=
05-12 09:10:06.970 8921 8921 I System.out: file.encoding=UTF-8
05-12 09:10:06.970 8921 8921 I System.out: java.runtime.version=0.9
05-12 09:10:06.970 8921 8921 I System.out: prism.dirtyopts=true
05-12 09:10:06.970 8921 8921 I System.out: user.name=root
05-12 09:10:06.970 8921 8921 I System.out: monocle.input.touchRadius=1
05-12 09:10:06.970 8921 8921 I System.out: java.compiler=
05-12 09:10:06.970 8921 8921 I System.out: android.icu.unicode.version=7.0
05-12 09:10:06.970 8921 8921 I System.out: prism.debugfonts=true
05-12 09:10:06.970 8921 8921 I System.out: java.version=0
05-12 09:10:06.970 8921 8921 I System.out: android.icu.library.version=55.1
05-12 09:10:06.970 8921 8921 I System.out: use.egl=true
05-12 09:10:06.971 8921 8921 I System.out: embedded=monocle
05-12 09:10:06.971 8921 8921 I System.out: prism.lcdtext=false
05-12 09:10:06.971 8921 8921 I System.out: os.arch=armv8l
05-12 09:10:06.971 8921 8921 I System.out:
java.io.tmpdir=/data/user/0/org.javafxports.hellowor...
05-12 09:10:06.971 8921 8921 I System.out: glass.platform=Monocle
05-12 09:10:06.971 8921 8921 I System.out: android.zlib.version=1.2.8
05-12 09:10:06.971 8921 8921 I System.out: user.language=en
05-12 09:10:06.971 8921 8921 I System.out: java.vm.version=2.1.0
05-12 09:10:06.971 8921 8921 I System.out: com.sun.javafx.isEmbedded=true
05-12 09:10:06.971 8921 8921 I System.out: prism.glDepthSize=16
05-12 09:10:06.971 8921 8921 I System.out: path.separator=:
05-12 09:10:06.971 8921 8921 I System.out: java.runtime.name=Android Runtime
05-12 09:10:06.971 8921 8921 I System.out: java.specification.version=0.9
05-12 09:10:06.971 8921 8921 I System.out: user.dir=/
05-12 09:10:06.971 8921 8921 I System.out: prism.maxTextureSize=2048
05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.vendor=The
Android Project
05-12 09:10:06.971 8921 8921 I System.out: java.vm.name=Dalvik
05-12 09:10:06.971 8921 8921 I System.out: monocle.platform=Android
05-12 09:10:06.971 8921 8921 I System.out: log.lens=FINEST
05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.version=0.9
05-12 09:10:06.971 8921 8921 I System.out: user.home=
05-12 09:10:06.971 8921 8921 I System.out: java.specification.name=Dalvik
Core Library
05-12 09:10:06.971 8921 8921 I System.out: file.separator=/
05-12 09:10:06.971 8921 8921 I System.out:
java.library.path=/vendor/lib:/system/lib
05-12 09:10:06.971 8921 8921 I System.out: user.variant=
05-12 09:10:06.971 8921 8921 I System.out: os.version=3.14.29
05-12 09:10:06.971 8921 8921 I System.out:
java.boot.class.path=/system/framework/core-libart.jar:/sy...
05-12 09:10:06.971 8921 8921 I System.out: DALVIK.prism.verbose=true
05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.name=Dalvik
Virtual Machine Specification
05-12 09:10:06.971 8921 8921 I System.out: javafx.platform=android
05-12 09:10:06.971 8921 8921 I System.out: glass.lens=eglfb
05-12 09:10:06.971 8921 8921 I System.out: os.name=Linux
05-12 09:10:06.971 8921 8921 I System.out: user.region=US
05-12 09:10:06.971 8921 8921 I System.out: java.class.path=.
05-12 09:10:06.971 8921 8921 I System.out:
android.icu.impl.ICUBinary.dataPath=/data/misc/zoneinfo/current/icu:/syst...
05-12 09:10:06.971 8921 8921 I System.out: prism.verbose=true
05-12 09:10:06.971 8921 8921 I System.out: prism.vsync=false
05-12 09:10:06.971 8921 8921 I System.out: java.specification.vendor=The
Android Project
05-12 09:10:06.971 8921 8921 I System.out: java.vm.vendor=The Android
Project
05-12 09:10:06.971 8921 8921 I System.out: prism.allowhidpi=false
05-12 09:10:06.972 8921 8921 I System.out: java.vendor=The Android Project
05-12 09:10:06.972 8921 8921 I System.out: http.agent=Dalvik/2.1.0 (Linux;
U; Android 6.0.1...
05-12 09:10:06.972 8921 8921 I System.out: android.icu.cldr.version=27.0.1
05-12 09:10:06.972 8921 8921 I System.out: android.openssl.version=BoringSSL
05-12 09:10:06.972 8921 8921 I System.out: java.home=/system
05-12 09:10:06.972 8921 8921 I System.out: java.vm.vendor.url=
http://www.android.com/
05-12 09:10:06.972 8921 8921 I System.out: java.class.version=50.0
05-12 09:10:06.972 8921 8921 V DalvikLauncher: Launch JavaFX application on
DALVIK vm.
05-12 09:10:06.976 8921 8921 V DalvikLauncher: We have JavaFX on our
current (base) classpath, registered exit listener
05-12 09:10:06.978 8921 8921 V DalvikLauncher: application class: [class
org.javafxports.helloworld.HelloAndroid]
05-12 09:10:06.978 8921 8921 V DalvikLauncher: preloader class: [null]
05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx application class:
[class javafx.application.Application]
05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx launcher class:
[class com.sun.javafx.application.LauncherImpl]
05-12 09:10:06.978 8921 8921 V DalvikLauncher: launch application method:
[public static void
com.sun.javafx.application.LauncherImpl.launchApplication(java.lang.Class,java.lang.Class,java.lang.String[])]
05-12 09:10:06.979 8921 8921 V FXEntity: Called Surface changed [1280,
696], format 4
05-12 09:10:06.979 8921 8921 V FXActivity native: [JVDBG] SURFACE created
native android window at 0xf4a94608, surface = 0xffda7370
05-12 09:10:06.980 8921 8921 V FXEntity: Called Surface redraw needed
05-12 09:10:06.989 8921 8921 V FXEntity: Called Surface redraw needed
05-12 09:10:07.018 4053 4075 I ActivityManager: Displayed
org.javafxports.helloworld/javafxports.android.FXActivity: +461ms
05-12 09:10:07.020 8921 8938 I System.out: Prism pipeline init order: es2
05-12 09:10:07.020 8921 8938 I System.out: Using native-based Pisces
rasterizer
05-12 09:10:07.020 8921 8938 I System.out: Using dirty region optimizations
05-12 09:10:07.020 8921 8938 I System.out: Using system sized mask for
primitives
05-12 09:10:07.021 8921 8938 I System.out: Not forcing power of 2 sizes for
textures
05-12 09:10:07.021 8921 8938 I System.out: Using hardware CLAMP_TO_ZERO mode
05-12 09:10:07.021 8921 8938 I System.out: Not opting in for HiDPI pixel
scaling
05-12 09:10:07.026 8921 8939 I System.out: Prism pipeline name =
com.sun.prism.es2.ES2Pipeline
05-12 09:10:07.029 8921 8939 I System.out: Loading ES2 native library ...
prism_es2_monocle
05-12 09:10:07.039 8921 8939 I System.out: succeeded.
05-12 09:10:07.040 8921 8939 I System.out: GLFactory using
com.sun.prism.es2.MonocleGLFactory
05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libGLESv2.so
05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712dd04
05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libEGL.so
05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712d9c4
05-12 09:10:07.053 8921 8939 I GLASS : Binding to libactivity.so
05-12 09:10:07.054 8921 8939 I GLASS : GetNativeWindow = 0xf4ad86dc,
getDensitiy = 0xf4ad86ec
05-12 09:10:07.054 8921 8935 V FXEntity: notify_glassHasStarted called in
FXActivity. register device now.
05-12 09:10:07.072 8921 8939 E libEGL : eglMakeCurrent:800 error 3009
(EGL_BAD_MATCH)
05-12 09:10:07.076 8921 8939 I System.out: (X) Got class = class
com.sun.prism.es2.ES2Pipeline
05-12 09:10:07.077 8921 8939 I System.out: Initialized prism pipeline:
com.sun.prism.es2.ES2Pipeline
05-12 09:10:07.083 8921 8943 I DENSITY : GETDENSITY, answer = 1.000000
05-12 09:10:07.097 8921 8939 I System.out: Maximum supported texture size:
4096
05-12 09:10:07.097 8921 8939 I System.out: Maximum texture size clamped to
2048
05-12 09:10:07.097 8921 8939 I System.out: Non power of two texture support
= true
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of vertex
attributes = 16
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform vertex
components = 1024
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform
fragment components = 1024
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of varying
components = 48
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units
usable in a vertex shader = 0
05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units
usable in a fragment shader = 8
05-12 09:10:07.098 8921 8939 I System.out: Graphics Vendor: ARM
05-12 09:10:07.098 8921 8939 I System.out: Renderer: Mali-450 MP
05-12 09:10:07.098 8921 8939 I System.out: Version: OpenGL ES 2.0
05-12 09:10:07.104 8921 8935 I System.out: register device done
05-12 09:10:07.107 8921 8943 W System.err: vsync: false vpipe: true
05-12 09:10:07.107 8921 8943 I System.out: [MON] Create device
05-12 09:10:07.109 8921 8943 I System.out: [MON] Create device done, add
done
05-12 09:10:07.257 8921 8943 W System.err: Loading FontFactory
com.sun.javafx.font.freetype.FTFactory
05-12 09:10:07.258 8921 8943 W System.err: Subpixel: enabled
05-12 09:10:07.272 8921 8943 W System.err: Freetype2 Loaded (version 2.10.0)
05-12 09:10:07.272 8921 8943 W System.err: LCD support Enabled
05-12 09:10:07.302 8921 8943 W art : Before Android 4.1, method void
com.sun.javafx.scene.transform.TransformUtils$ImmutableTransform.ensureCanTransform2DPoint()
would have incorrectly overridden the package-private method in
javafx.scene.transform.Transform
05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double
javafx.scene.text.TextFlow.computeChildPrefAreaHeight(javafx.scene.Node,
javafx.geometry.Insets) would have incorrectly overridden the
package-private method in javafx.scene.layout.Region
05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double
javafx.scene.text.TextFlow.computeChildPrefAreaWidth(javafx.scene.Node,
javafx.geometry.Insets) would have incorrectly overridden the
package-private method in javafx.scene.layout.Region
05-12 09:10:08.001 8921 8939 I System.out: max rectangle texture cell size
= 62
05-12 09:10:08.019 8921 8939 I System.out: wrap rectangle texture = 2 x 2
05-12 09:10:08.024 8921 8939 I System.out: ES2ResourceFactory: Prism -
createStockShader: AlphaTexture_Color.frag
05-12 09:10:08.287 8921 8939 E javafx : Program link log: L0010 Uniform
'color' differ on precision
05-12 09:10:08.287 8921 8939 W System.err: java.lang.RuntimeException:
Error creating shader program
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:158)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:190)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:122)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:451)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:119)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:179)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGShape3D.renderContent(NGShape3D.java:201)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91)
05-12 09:10:08.288 8921 8939 W System.err: at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
05-12 09:10:08.288 8921 8939 W System.err: at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
05-12 09:10:08.288 8921 8939 W System.err: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
05-12 09:10:08.288 8921 8939 W System.err: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
05-12 09:10:08.288 8921 8939 W System.err: at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
05-12 09:10:08.288 8921 8939 W System.err: at
java.lang.Thread.run(Thread.java:818)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240811/467342af/attachment-0001.htm>

From nlisker at gmail.com  Mon Aug 12 07:59:32 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 12 Aug 2024 10:59:32 +0300
Subject: Scene 3D objects throw exception on Android deivces
In-Reply-To: <CAM8NxRN2UA=GghdtgYeJRxgHbeH2kA6mg8nj-cBjR=3FD3fGeQ@mail.gmail.com>
References: <CAM8NxRM-gb5c3p-VRwatRPSC+hwRty7diShRqzJSkDZ01imcGw@mail.gmail.com>
 <CAM8NxRN2UA=GghdtgYeJRxgHbeH2kA6mg8nj-cBjR=3FD3fGeQ@mail.gmail.com>
Message-ID: <CA+0ynh-eYQ2FEXwo31e_BCa7_y5dUaYc1m34MGo75KU7wTqT-w@mail.gmail.com>

This is not a JavaFX problem. From the stack trace, you're using
javafxports, which is a 3rd party (Gluon) technology. It was EOL years ago
and replaced by their client plugin [1][2]. See https://docs.gluonhq.com on
how to compile JavaFX to mobile.

There is, however, a 3D lighting issue with the OpenGL pipeline that
affects Android, as shown in [3] for example. It's probably something wrong
in the shader, but won't stop your application from running.

- Nir

[1] https://github.com/gluonhq/gluonfx-maven-plugin
[2] https://github.com/gluonhq/gluonfx-gradle-plugin
[3]
https://stackoverflow.com/questions/50163758/issue-with-point-lights-when-on-mobile

On Sun, Aug 11, 2024 at 10:12?AM Ashley Hales <ashley.hales at gmail.com>
wrote:

> Hi, I have been compiling a JavaFX app for Android using the Dalvik SDK. I
> have managed to resolve all the dependencies and compile into an APK. This
> APK will install on Android devices but doesn't work on all of them.
>
> I have modified the HelloWorld app included with the Dalvik SDK to debug
> my problem. It works on all of my devices with just a label on the screen
> but as soon as I add a sphere into the scene it just displays a black
> screen on some devices. I have searched on the internet and suggestions
> indicate that this may be a memory issue but I have tried setting
> android.monocle.stacksize = 12800 in the javafx.platform.properties but
> this has had no effect. After reading other posts on the forum I was
> wondering if this might be due to a lack of 3D support on embedded
> (although this is an Android device).  I have tried modifying
> the javafx.platform.properties by
> setting android.com.sun.javafx.isEmbedded=false or com.sun.javafx.experimental.embedded.3d=true
> but neither have any effect.  I have also tried printing out the result
> of Platform.isSupported(ConditionalFeature.SCENE3D) but confusingly this
> shows true despite the error.
>
> I have tested on a couple of devices so far.  The error occurs every time
> on my MBOX MINIM8S II (Android 6.0.1) but never on my Samsung Galaxy
> Table Model SM-T230 (Android 4.4.2)  device.
>
> I have also shared the compiled APK on Google Drive which you may access
> from
> https://drive.google.com/file/d/1QLA21gg2g9-ODrKctSqac6pNC2cxzCtx/view?usp=drive_link
> .
>
> Here is the logcat report for the issue?
>
> 05-12 09:10:06.584 4053 4181 I ActivityManager: Start proc
> 8921:org.javafxports.helloworld/u0a56 for activity
> org.javafxports.helloworld/javafxports.android.FXActivity
> 05-12 09:10:06.649 8921 8921 I art : Not late-enabling -Xcheck:jni
> (already on)
> 05-12 09:10:06.731 8921 8921 I MultiDex: VM with version 2.1.0 has
> multidex support
> 05-12 09:10:06.731 8921 8921 I MultiDex: install
> 05-12 09:10:06.731 8921 8921 I MultiDex: VM has multidex support, MultiDex
> support library is disabled.
> 05-12 09:10:06.735 8921 8921 V FXActivity: Initializing JavaFX Platform,
> using 8.60.9-SNAPSHOT
> 05-12 09:10:06.745 8921 8921 V FXActivity native: Loading JavaFXDalvik
> library
> 05-12 09:10:06.751 8921 8921 I System.out: usetextureview = false,
> useswipekeyboard = false
> 05-12 09:10:06.753 8921 8921 V FXActivity: onCreate called, using
> 8.60.9-SNAPSHOT
> 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue
> instance created.
> 05-12 09:10:06.754 8921 8934 V FXActivity native: Notification queue
> started
> 05-12 09:10:06.758 4172 4172 V PhoneStatusBar: setLightsOn(true)
> 05-12 09:10:06.789 8921 8921 V FXActivity native: appDataDir:
> /data/user/0/org.javafxports.helloworld
> 05-12 09:10:06.790 8921 8921 V FXActivity: onStart
> 05-12 09:10:06.790 8921 8921 V FXActivity: onResume
> 05-12 09:10:06.827 8921 8921 V FXEntity: Surface created.
> 05-12 09:10:06.828 8921 8921 V FXActivity native: [JVDBG] SURFACE created
> native android window at 0xf4a94608, surface = 0xffda7390
> 05-12 09:10:06.970 8921 8921 I System.out: user.locale=en-US
> 05-12 09:10:06.970 8921 8921 I System.out: monocle.stackSize=128000
> 05-12 09:10:06.970 8921 8921 I System.out: prism.text=native
> 05-12 09:10:06.970 8921 8921 I System.out: java.vendor.url=
> http://www.android.com/
> 05-12 09:10:06.970 8921 8921 I System.out: java.ext.dirs=
> 05-12 09:10:06.970 8921 8921 I System.out: line.separator=
> 05-12 09:10:06.970 8921 8921 I System.out: file.encoding=UTF-8
> 05-12 09:10:06.970 8921 8921 I System.out: java.runtime.version=0.9
> 05-12 09:10:06.970 8921 8921 I System.out: prism.dirtyopts=true
> 05-12 09:10:06.970 8921 8921 I System.out: user.name=root
> 05-12 09:10:06.970 8921 8921 I System.out: monocle.input.touchRadius=1
> 05-12 09:10:06.970 8921 8921 I System.out: java.compiler=
> 05-12 09:10:06.970 8921 8921 I System.out: android.icu.unicode.version=7.0
> 05-12 09:10:06.970 8921 8921 I System.out: prism.debugfonts=true
> 05-12 09:10:06.970 8921 8921 I System.out: java.version=0
> 05-12 09:10:06.970 8921 8921 I System.out: android.icu.library.version=55.1
> 05-12 09:10:06.970 8921 8921 I System.out: use.egl=true
> 05-12 09:10:06.971 8921 8921 I System.out: embedded=monocle
> 05-12 09:10:06.971 8921 8921 I System.out: prism.lcdtext=false
> 05-12 09:10:06.971 8921 8921 I System.out: os.arch=armv8l
> 05-12 09:10:06.971 8921 8921 I System.out:
> java.io.tmpdir=/data/user/0/org.javafxports.hellowor...
> 05-12 09:10:06.971 8921 8921 I System.out: glass.platform=Monocle
> 05-12 09:10:06.971 8921 8921 I System.out: android.zlib.version=1.2.8
> 05-12 09:10:06.971 8921 8921 I System.out: user.language=en
> 05-12 09:10:06.971 8921 8921 I System.out: java.vm.version=2.1.0
> 05-12 09:10:06.971 8921 8921 I System.out: com.sun.javafx.isEmbedded=true
> 05-12 09:10:06.971 8921 8921 I System.out: prism.glDepthSize=16
> 05-12 09:10:06.971 8921 8921 I System.out: path.separator=:
> 05-12 09:10:06.971 8921 8921 I System.out: java.runtime.name=Android
> Runtime
> 05-12 09:10:06.971 8921 8921 I System.out: java.specification.version=0.9
> 05-12 09:10:06.971 8921 8921 I System.out: user.dir=/
> 05-12 09:10:06.971 8921 8921 I System.out: prism.maxTextureSize=2048
> 05-12 09:10:06.971 8921 8921 I System.out:
> java.vm.specification.vendor=The Android Project
> 05-12 09:10:06.971 8921 8921 I System.out: java.vm.name=Dalvik
> 05-12 09:10:06.971 8921 8921 I System.out: monocle.platform=Android
> 05-12 09:10:06.971 8921 8921 I System.out: log.lens=FINEST
> 05-12 09:10:06.971 8921 8921 I System.out:
> java.vm.specification.version=0.9
> 05-12 09:10:06.971 8921 8921 I System.out: user.home=
> 05-12 09:10:06.971 8921 8921 I System.out: java.specification.name=Dalvik
> Core Library
> 05-12 09:10:06.971 8921 8921 I System.out: file.separator=/
> 05-12 09:10:06.971 8921 8921 I System.out:
> java.library.path=/vendor/lib:/system/lib
> 05-12 09:10:06.971 8921 8921 I System.out: user.variant=
> 05-12 09:10:06.971 8921 8921 I System.out: os.version=3.14.29
> 05-12 09:10:06.971 8921 8921 I System.out:
> java.boot.class.path=/system/framework/core-libart.jar:/sy...
> 05-12 09:10:06.971 8921 8921 I System.out: DALVIK.prism.verbose=true
> 05-12 09:10:06.971 8921 8921 I System.out: java.vm.specification.name=Dalvik
> Virtual Machine Specification
> 05-12 09:10:06.971 8921 8921 I System.out: javafx.platform=android
> 05-12 09:10:06.971 8921 8921 I System.out: glass.lens=eglfb
> 05-12 09:10:06.971 8921 8921 I System.out: os.name=Linux
> 05-12 09:10:06.971 8921 8921 I System.out: user.region=US
> 05-12 09:10:06.971 8921 8921 I System.out: java.class.path=.
> 05-12 09:10:06.971 8921 8921 I System.out:
> android.icu.impl.ICUBinary.dataPath=/data/misc/zoneinfo/current/icu:/syst...
> 05-12 09:10:06.971 8921 8921 I System.out: prism.verbose=true
> 05-12 09:10:06.971 8921 8921 I System.out: prism.vsync=false
> 05-12 09:10:06.971 8921 8921 I System.out: java.specification.vendor=The
> Android Project
> 05-12 09:10:06.971 8921 8921 I System.out: java.vm.vendor=The Android
> Project
> 05-12 09:10:06.971 8921 8921 I System.out: prism.allowhidpi=false
> 05-12 09:10:06.972 8921 8921 I System.out: java.vendor=The Android Project
> 05-12 09:10:06.972 8921 8921 I System.out: http.agent=Dalvik/2.1.0 (Linux;
> U; Android 6.0.1...
> 05-12 09:10:06.972 8921 8921 I System.out: android.icu.cldr.version=27.0.1
> 05-12 09:10:06.972 8921 8921 I System.out:
> android.openssl.version=BoringSSL
> 05-12 09:10:06.972 8921 8921 I System.out: java.home=/system
> 05-12 09:10:06.972 8921 8921 I System.out: java.vm.vendor.url=
> http://www.android.com/
> 05-12 09:10:06.972 8921 8921 I System.out: java.class.version=50.0
> 05-12 09:10:06.972 8921 8921 V DalvikLauncher: Launch JavaFX application
> on DALVIK vm.
> 05-12 09:10:06.976 8921 8921 V DalvikLauncher: We have JavaFX on our
> current (base) classpath, registered exit listener
> 05-12 09:10:06.978 8921 8921 V DalvikLauncher: application class: [class
> org.javafxports.helloworld.HelloAndroid]
> 05-12 09:10:06.978 8921 8921 V DalvikLauncher: preloader class: [null]
> 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx application class:
> [class javafx.application.Application]
> 05-12 09:10:06.978 8921 8921 V DalvikLauncher: javafx launcher class:
> [class com.sun.javafx.application.LauncherImpl]
> 05-12 09:10:06.978 8921 8921 V DalvikLauncher: launch application method:
> [public static void
> com.sun.javafx.application.LauncherImpl.launchApplication(java.lang.Class,java.lang.Class,java.lang.String[])]
> 05-12 09:10:06.979 8921 8921 V FXEntity: Called Surface changed [1280,
> 696], format 4
> 05-12 09:10:06.979 8921 8921 V FXActivity native: [JVDBG] SURFACE created
> native android window at 0xf4a94608, surface = 0xffda7370
> 05-12 09:10:06.980 8921 8921 V FXEntity: Called Surface redraw needed
> 05-12 09:10:06.989 8921 8921 V FXEntity: Called Surface redraw needed
> 05-12 09:10:07.018 4053 4075 I ActivityManager: Displayed
> org.javafxports.helloworld/javafxports.android.FXActivity: +461ms
> 05-12 09:10:07.020 8921 8938 I System.out: Prism pipeline init order: es2
> 05-12 09:10:07.020 8921 8938 I System.out: Using native-based Pisces
> rasterizer
> 05-12 09:10:07.020 8921 8938 I System.out: Using dirty region optimizations
> 05-12 09:10:07.020 8921 8938 I System.out: Using system sized mask for
> primitives
> 05-12 09:10:07.021 8921 8938 I System.out: Not forcing power of 2 sizes
> for textures
> 05-12 09:10:07.021 8921 8938 I System.out: Using hardware CLAMP_TO_ZERO
> mode
> 05-12 09:10:07.021 8921 8938 I System.out: Not opting in for HiDPI pixel
> scaling
> 05-12 09:10:07.026 8921 8939 I System.out: Prism pipeline name =
> com.sun.prism.es2.ES2Pipeline
> 05-12 09:10:07.029 8921 8939 I System.out: Loading ES2 native library ...
> prism_es2_monocle
> 05-12 09:10:07.039 8921 8939 I System.out: succeeded.
> 05-12 09:10:07.040 8921 8939 I System.out: GLFactory using
> com.sun.prism.es2.MonocleGLFactory
> 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libGLESv2.so
> 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712dd04
> 05-12 09:10:07.052 8921 8939 I GLASS : I have to Call dlopen libEGL.so
> 05-12 09:10:07.052 8921 8939 I GLASS : handle = 0xf712d9c4
> 05-12 09:10:07.053 8921 8939 I GLASS : Binding to libactivity.so
> 05-12 09:10:07.054 8921 8939 I GLASS : GetNativeWindow = 0xf4ad86dc,
> getDensitiy = 0xf4ad86ec
> 05-12 09:10:07.054 8921 8935 V FXEntity: notify_glassHasStarted called in
> FXActivity. register device now.
> 05-12 09:10:07.072 8921 8939 E libEGL : eglMakeCurrent:800 error 3009
> (EGL_BAD_MATCH)
> 05-12 09:10:07.076 8921 8939 I System.out: (X) Got class = class
> com.sun.prism.es2.ES2Pipeline
> 05-12 09:10:07.077 8921 8939 I System.out: Initialized prism pipeline:
> com.sun.prism.es2.ES2Pipeline
> 05-12 09:10:07.083 8921 8943 I DENSITY : GETDENSITY, answer = 1.000000
> 05-12 09:10:07.097 8921 8939 I System.out: Maximum supported texture size:
> 4096
> 05-12 09:10:07.097 8921 8939 I System.out: Maximum texture size clamped to
> 2048
> 05-12 09:10:07.097 8921 8939 I System.out: Non power of two texture
> support = true
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of vertex
> attributes = 16
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform
> vertex components = 1024
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of uniform
> fragment components = 1024
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of varying
> components = 48
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units
> usable in a vertex shader = 0
> 05-12 09:10:07.098 8921 8939 I System.out: Maximum number of texture units
> usable in a fragment shader = 8
> 05-12 09:10:07.098 8921 8939 I System.out: Graphics Vendor: ARM
> 05-12 09:10:07.098 8921 8939 I System.out: Renderer: Mali-450 MP
> 05-12 09:10:07.098 8921 8939 I System.out: Version: OpenGL ES 2.0
> 05-12 09:10:07.104 8921 8935 I System.out: register device done
> 05-12 09:10:07.107 8921 8943 W System.err: vsync: false vpipe: true
> 05-12 09:10:07.107 8921 8943 I System.out: [MON] Create device
> 05-12 09:10:07.109 8921 8943 I System.out: [MON] Create device done, add
> done
> 05-12 09:10:07.257 8921 8943 W System.err: Loading FontFactory
> com.sun.javafx.font.freetype.FTFactory
> 05-12 09:10:07.258 8921 8943 W System.err: Subpixel: enabled
> 05-12 09:10:07.272 8921 8943 W System.err: Freetype2 Loaded (version
> 2.10.0)
> 05-12 09:10:07.272 8921 8943 W System.err: LCD support Enabled
> 05-12 09:10:07.302 8921 8943 W art : Before Android 4.1, method void
> com.sun.javafx.scene.transform.TransformUtils$ImmutableTransform.ensureCanTransform2DPoint()
> would have incorrectly overridden the package-private method in
> javafx.scene.transform.Transform
> 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double
> javafx.scene.text.TextFlow.computeChildPrefAreaHeight(javafx.scene.Node,
> javafx.geometry.Insets) would have incorrectly overridden the
> package-private method in javafx.scene.layout.Region
> 05-12 09:10:07.784 8921 8943 W art : Before Android 4.1, method double
> javafx.scene.text.TextFlow.computeChildPrefAreaWidth(javafx.scene.Node,
> javafx.geometry.Insets) would have incorrectly overridden the
> package-private method in javafx.scene.layout.Region
> 05-12 09:10:08.001 8921 8939 I System.out: max rectangle texture cell size
> = 62
> 05-12 09:10:08.019 8921 8939 I System.out: wrap rectangle texture = 2 x 2
> 05-12 09:10:08.024 8921 8939 I System.out: ES2ResourceFactory: Prism -
> createStockShader: AlphaTexture_Color.frag
> 05-12 09:10:08.287 8921 8939 E javafx : Program link log: L0010 Uniform
> 'color' differ on precision
> 05-12 09:10:08.287 8921 8939 W System.err: java.lang.RuntimeException:
> Error creating shader program
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:158)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:190)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.prism.es2.ES2Context.getPhongShader(ES2Context.java:122)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.prism.es2.ES2Context.renderMeshView(ES2Context.java:451)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.prism.es2.ES2MeshView.render(ES2MeshView.java:119)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGShape3D.renderMeshView(NGShape3D.java:179)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGShape3D.renderContent(NGShape3D.java:201)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2056)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1948)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:423)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
> 05-12 09:10:08.288 8921 8939 W System.err: at
> java.lang.Thread.run(Thread.java:818)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240812/e1119df7/attachment-0001.htm>

From jpereda at openjdk.org  Mon Aug 12 10:02:39 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 10:02:39 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
Message-ID: <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>

On Fri, 9 Aug 2024 08:13:16 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GlassViewDelegate: Correctly set origin and offset in dragImage
>   
>   - Centering to dragImage was removed - origin is now top-left of dragImage
>   - Offset direction was swapped

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1049:

> 1047:         if (image != nil)
> 1048:         {
> 1049:             // select the center of the image as the drag origin

The old comment about RT-17629 (https://bugs.openjdk.org/browse/JDK-8091965) does not apply anymore: after this PR, the offset, which comes from the Java layer, does adjust the drag image origin.

So I believe we can remove the whole comment as well (and possibly close RT-17629).

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068:

> 1066: 
> 1067:                 dragPoint.x -= offset.x;
> 1068:                 dragPoint.y -= offset.y;

This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore:

- If you drag from {0,0} (top-left), it works from that position
- But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected.

So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713448689
PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713460897

From lkostyra at openjdk.org  Mon Aug 12 12:16:36 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 12 Aug 2024 12:16:36 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
Message-ID: <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>

On Mon, 12 Aug 2024 09:54:19 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   GlassViewDelegate: Correctly set origin and offset in dragImage
>>   
>>   - Centering to dragImage was removed - origin is now top-left of dragImage
>>   - Offset direction was swapped
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068:
> 
>> 1066: 
>> 1067:                 dragPoint.x -= offset.x;
>> 1068:                 dragPoint.y -= offset.y;
> 
> This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore:
> 
> - If you drag from {0,0} (top-left), it works from that position
> - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected.
> 
> So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all).

Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned.

I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713643394

From jpereda at openjdk.org  Mon Aug 12 12:42:38 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 12:42:38 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
 <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
Message-ID: <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>

On Mon, 12 Aug 2024 12:14:26 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1068:
>> 
>>> 1066: 
>>> 1067:                 dragPoint.x -= offset.x;
>>> 1068:                 dragPoint.y -= offset.y;
>> 
>> This works fine now, _if_ the offset values are smaller than the imageHalf X,Y values, which doesn't make sense anymore:
>> 
>> - If you drag from {0,0} (top-left), it works from that position
>> - But if you drag from {imageW, imageH} (bottom-right), the offset is clamped to the image centre, which it is not expected.
>> 
>> So now we need to change the above lines to clamp the offset between 0,0 and imageW,H (though Windows doesn't clamp the offset at all).
>
> Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned.
> 
> I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)?

Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). 

When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. 

And doing the same (clamping) for Windows would be a separate issue, indeed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1713684798

From kcr at openjdk.org  Mon Aug 12 12:52:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 12:52:37 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <fKZLn2iqMOgJfiLNFJ0bYK7uhpyxsRr-tYYI-WmPc0E=.1c69698d-7aee-442d-991b-4ba93f5cca72@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

@jaybhaskar Can you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1527#issuecomment-2283900603

From lkostyra at openjdk.org  Mon Aug 12 12:58:25 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 12 Aug 2024 12:58:25 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v3]
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <akGYIfcy0CwzGaaQUJ6AP2TKN3YhhJkpNleGo0hO9yI=.5c1c790f-0e24-41dc-9220-eaeb4c88af56@github.com>

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Adjust clamping values, remove old TODO

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1532/files
  - new: https://git.openjdk.org/jfx/pull/1532/files/c922de84..41cd6755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=01-02

  Stats: 14 lines in 1 file changed: 4 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1532.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532

PR: https://git.openjdk.org/jfx/pull/1532

From kcr at openjdk.org  Mon Aug 12 14:37:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 14:37:11 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not
 set
Message-ID: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>

1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:

C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
     (Enterprise|Professional|Community)\VC\Auxiliary\Build

2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
5. Removed the following unused variables:

DEVENVCMD
DXSDK_DIR
VS_VER

6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).


I left some debug print statements in, and will remove them in a follow-on commit.

I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

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

Commit messages:
 - Remove obsolete check for VS_VER in jfxmedia Makefile
 - Remove illegal char from 'REM' comment
 - Print deprecation warning if VS150COMNTOOLS is used
 - Add MSVCDIR back in
 - Add debug prints
 - 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set

Changes: https://git.openjdk.org/jfx/pull/1534/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289174
  Stats: 191 lines in 5 files changed: 60 ins; 79 del; 52 mod
  Patch: https://git.openjdk.org/jfx/pull/1534.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534

PR: https://git.openjdk.org/jfx/pull/1534

From kcr at openjdk.org  Mon Aug 12 14:37:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 14:37:11 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set
In-Reply-To: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
Message-ID: <U56Hf4hW0UycmeUDHYQEFtiGGgllFChWLrJiFxCk-es=.754828e1-78c8-44d5-99f9-ca18601e18ef@github.com>

On Mon, 12 Aug 2024 14:21:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
> 
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
> 
> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
> 5. Removed the following unused variables:
> 
> DEVENVCMD
> DXSDK_DIR
> VS_VER
> 
> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
> 
> 
> I left some debug print statements in, and will remove them in a follow-on commit.
> 
> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

Reviewers: @prrace and either @tiainen or @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284151235

From angorya at openjdk.org  Mon Aug 12 14:45:47 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 14:45:47 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v25]
In-Reply-To: <r-DYvJWobjLYTBSvWeJwGrgWt-601tgL5W82kZe71X0=.15c2607c-6696-4d40-b55d-1541771db33c@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
 <r-DYvJWobjLYTBSvWeJwGrgWt-601tgL5W82kZe71X0=.15c2607c-6696-4d40-b55d-1541771db33c@github.com>
Message-ID: <Tab46zFtWBGCJwTD9i4kH3PZ0bOkobKe6c4qPEfJeAQ=.249363d2-f551-493f-a6e1-0953130451e1@github.com>

On Sat, 10 Aug 2024 17:59:52 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I strongly suggest to do this as part of [JDK-8338121](https://bugs.openjdk.org/browse/JDK-8338121)

+1.  I am fine with splitting the work in two parts.  My only suggestion is to valign the table cells to top instead of center.

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2284177222

From jbhaskar at openjdk.org  Mon Aug 12 15:28:36 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 12 Aug 2024 15:28:36 GMT
Subject: RFR: 8336941 : Update libxslt to 1.1.42 [v2]
In-Reply-To: <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
 <cEr020-rj3X_5GGXYn6OlIK7Mtq9YALV9N3HO-I5vp0=.399e6c3a-afcd-49e5-8ddf-7ea8bcbec0c2@github.com>
Message-ID: <SL0Apz5v1djp1JDrANruaVsG9Kvsa4NesrADhsFhMJo=.0b72a776-ce27-411e-b408-fc462a078f90@github.com>

On Tue, 6 Aug 2024 08:08:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove deprecated file

+looks good to me

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1527#pullrequestreview-2233379048

From kcr at openjdk.org  Mon Aug 12 15:37:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 15:37:10 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
Message-ID: <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>

> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
> 
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
> 
> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
> 5. Removed the following unused variables:
> 
> DEVENVCMD
> DXSDK_DIR
> VS_VER
> 
> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
> 
> 
> I left some debug print statements in, and will remove them in a follow-on commit.
> 
> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Add debug prints"
  
  This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1534/files
  - new: https://git.openjdk.org/jfx/pull/1534/files/99f3804c..b6972b36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=00-01

  Stats: 28 lines in 2 files changed: 0 ins; 28 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1534.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534

PR: https://git.openjdk.org/jfx/pull/1534

From kcr at openjdk.org  Mon Aug 12 15:40:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 15:40:41 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
Message-ID: <5kO75QWUB85XSr3iPJipIL5MtnfQuGEmkJGEBHKlwPM=.3ddebd12-4a06-46a7-87de-fc9f66ba0565@github.com>

On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Add debug prints"
>   
>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.

> I left some debug print statements in, and will remove them in a follow-on commit.

I removed these with the last commit.

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

PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284307863

From jpereda at openjdk.org  Mon Aug 12 16:10:40 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 16:10:40 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v3]
In-Reply-To: <akGYIfcy0CwzGaaQUJ6AP2TKN3YhhJkpNleGo0hO9yI=.5c1c790f-0e24-41dc-9220-eaeb4c88af56@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <akGYIfcy0CwzGaaQUJ6AP2TKN3YhhJkpNleGo0hO9yI=.5c1c790f-0e24-41dc-9220-eaeb4c88af56@github.com>
Message-ID: <vAoOMNZ8bj6LwhgwIeAOOclNkcPfcexrqZWsP5fQa-0=.d1de9ce0-60b7-4292-92e4-254b20c2b731@github.com>

On Mon, 12 Aug 2024 12:58:25 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust clamping values, remove old TODO

Looking good, I still have two minor comments

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1049:

> 1047:         if (image != nil)
> 1048:         {
> 1049:             // select the center of the image as the drag origin

There are two consecutive `if (image != nil)` blocks, so you can remove the 4 lines above this one.

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

PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2233475851
PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714048165

From jpereda at openjdk.org  Mon Aug 12 16:10:40 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 16:10:40 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
 <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
 <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>
Message-ID: <L4QDj-Dy-SPNPll0O9c7sGWqgLagUR1vebdnpnXCduA=.15368b98-0364-4884-be3e-c8ca09d0340d@github.com>

On Mon, 12 Aug 2024 12:39:52 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Out of curiosity I removed offset clamping (macOS snaps the drag image regardless) and technically it still works, but when you cancel the drag the image snaps back to the offset position. With high enough (or negative) values drag image can animate back even outside the application bounds, which makes little sense and looks weird. I'll clamp it between 0,0 and imageW,H as you mentioned.
>> 
>> I also didn't find a way to disable above drag image "snapping". However, if it makes sense to clamp it on macOS, maybe it would also make sense to introduce similar limits to offsets on other platforms (probably as a separate issue)?
>
> Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). 
> 
> When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. 
> 
> And doing the same (clamping) for Windows would be a separate issue, indeed.

By the way, this is how you can disable the cancel animation:


diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
index 50a79cabf6..373537f24e 100644
--- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
+++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
@@ -40,6 +40,7 @@
 
 - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context
 {
+     session.animatesToStartingPositionsOnCancelOrFail = NO;
     // The Command key masks out every operation other than NSDragOperationGeneric. We want
     // internal Move events to get through this filtering so we copy the Move bit into the
     // Generic bit and treat Generic as a synonym for Move.


I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714046402

From angorya at openjdk.org  Mon Aug 12 16:24:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 16:24:36 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <L4QDj-Dy-SPNPll0O9c7sGWqgLagUR1vebdnpnXCduA=.15368b98-0364-4884-be3e-c8ca09d0340d@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
 <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
 <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>
 <L4QDj-Dy-SPNPll0O9c7sGWqgLagUR1vebdnpnXCduA=.15368b98-0364-4884-be3e-c8ca09d0340d@github.com>
Message-ID: <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com>

On Mon, 12 Aug 2024 16:02:32 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Right, there is a built-in native animation from the offset point to the mouse cursor (in and out). 
>> 
>> When the drag event is cancelled, the image returns to the offset location with this animation. We still want that, so I wouldn't remove the animation (if we could), but of course, with the original position of the source, no far away from it, so it makes sense to clamp between the image bounds. 
>> 
>> And doing the same (clamping) for Windows would be a separate issue, indeed.
>
> By the way, this is how you can disable the cancel animation:
> 
> 
> diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
> index 50a79cabf6..373537f24e 100644
> --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
> +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
> @@ -40,6 +40,7 @@
>  
>  - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context
>  {
> +     session.animatesToStartingPositionsOnCancelOrFail = NO;
>      // The Command key masks out every operation other than NSDragOperationGeneric. We want
>      // internal Move events to get through this filtering so we copy the Move bit into the
>      // Generic bit and treat Generic as a synonym for Move.
> 
> 
> I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms).

I wanted to chime in, thought it might be unrelated:

In the context of a docking framework, it is impossible to disable the cancel animation.  We should have a way to disable it.  The use case is when the user drags and drops a tab/pane outside of the dockable windows.  In this case a new window should appear at the drop location, without the drag image animated back to the start position.

Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content.

These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example
https://github.com/andy-goryachev/FxDock

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714071087

From nlisker at openjdk.org  Mon Aug 12 17:04:38 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 12 Aug 2024 17:04:38 GMT
Subject: RFR: 8301761: The sorting of the SortedList can become invalid
 [v2]
In-Reply-To: <hrR1XWkDosSrxVmAvkIBy9xeOpq0-ReyPHYUqsVYHkc=.3e52f3a2-d563-4199-90f4-61a3e6e613ac@github.com>
References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com>
 <gN7fVJmMMZawUTkUhEKciSwzYBZIm8lxbXr2MGjtgQE=.8dfd3b74-3eaf-4e29-929e-6cc13aa0be8f@github.com>
 <TyTZ06z9bvapO74_LV_QbP83rkZkkB36ns6EH76vW9U=.15196399-34c1-4f6a-818f-383aa9ddbd95@github.com>
 <PmAGas3sgjYUZbzitMZha_DwtPFmeGC6v_kflBrcxyE=.a7f2b6eb-8d67-4e67-9117-5a91bf6372c7@github.com>
 <hrR1XWkDosSrxVmAvkIBy9xeOpq0-ReyPHYUqsVYHkc=.3e52f3a2-d563-4199-90f4-61a3e6e613ac@github.com>
Message-ID: <FgmEHofJh9d3QWhgF_42cl1WkSyheMIR5I3KyuRHfhw=.774ad708-9ec9-4a65-9852-e0869804c525@github.com>

On Sat, 10 Aug 2024 11:53:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> This is not the case. The sorting is still correct. Claiming that the sorting is invalid because a newly added item was not placed in a specific location relative to other equal items is a bit of misrepresentation.
>>> 
>>> So, if this PR wants to move forward, I think we first need to decide if we want to guarantee a specific behavior when inserting new but equal elements.
>> 
>> The issue isn?t just with adding new elements. It also affects the `TableView` that populated with items from a `SortedList`, The `SortedList`'s comparator is bound to the `TableView`'s comparator.
>> When the table is sorted by two columns and the second sort is removed, the table should revert to sorting by just the first column. However, currently, removing the second column from the sort order doesn't change the items order.
>> 
>> For example:
>> ![image](https://github.com/user-attachments/assets/9ed8b2ea-9879-4dc9-a285-4d03be2d2691)
>> 
>> 1. The initial order is [0, 1, 2, 3] (index column).
>> 2. Sort by `Col1`, the order will be: [1, 0, 2, 3].
>> 3. Add a second sort (Shift + Click) on `Col2`, the order will be: [1, 2, 3, 0].
>> 4. Shift + Click again on `Col2` to sort in descending order: [1, 0, 3, 2].
>> 5. Shift + Click again on `Col2` to remove the sort from `Col2`. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.
>> 
>> <details>
>> <summary> Code </summary>
>> 
>> 
>> import javafx.application.Application;
>> import javafx.beans.property.ReadOnlyObjectWrapper;
>> import javafx.collections.FXCollections;
>> import javafx.collections.ObservableList;
>> import javafx.collections.transformation.SortedList;
>> import javafx.scene.Scene;
>> import javafx.scene.control.TableColumn;
>> import javafx.scene.control.TableView;
>> import javafx.stage.Stage;
>> 
>> public class Main extends Application {
>> 
>>     @Override
>>     public void start(Stage primaryStage) {
>>         primaryStage.setScene(new Scene(createTableView()));
>>         primaryStage.show();
>>     }
>> 
>>     private TableView<Data> createTableView() {
>>         TableView<Data> tableView = new TableView<>();
>> 
>>         TableColumn<Data, Integer> indexColumn = new TableColumn<>("#");
>>         indexColumn.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue().index()));
>>         indexColumn.setSortable(false);
>> 
>>         TableColumn<Data, Integer> column1 = new TableColumn<>("Col1");
>>         column1.setCellValueFactory(cell -> new ReadOnlyObjectWrapper<>(cell.getValue...
>
>> Shift + Click again on Col2 to remove the sort from Col2. The order will stay the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.
> 
> Why is that the expected order?  It is "a" possible, but valid order.  When only sorting on `Col1` then in my opinion [1, 0, 2, 3], [1, 0, 3, 2], [1, 2, 0, 3], etc.. are all valid sort orders.
> 
> If we want to distinguish between equal elements to give them a fixed sub-ordering (and the inverse one I suppose when the sort is descending) then what should the distinguishing factor be?  Its position in the underlying unsorted list?  The time it was added to the underlying list?  They need not be the same.  Using the position in the underlying list could be quite random if the source of the list doesn't guarantee a fixed position (from an unsorted database query for example).
> 
> What if the underlying list is another sorted list or a filtered list, can we even rely on the indices those provide?

@hjohn I was confused as well, but the [`TableView` docs](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#sorting-heading) say:
> Starting with JavaFX 8.0 (and the introduction of [SortedList](https://openjfx.io/javadoc/22/javafx.base/javafx/collections/transformation/SortedList.html)), it is now possible to have the collection return to the unsorted state when there are no columns as part of the TableView [sort order](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#getSortOrder()). To do this, you must create a SortedList instance, and bind its [comparator](https://openjfx.io/javadoc/22/javafx.base/javafx/collections/transformation/SortedList.html#comparatorProperty()) property to the TableView [comparator](https://openjfx.io/javadoc/22/javafx.controls/javafx/scene/control/TableView.html#comparatorProperty()) property

So I think that the confusion stems from the fuzzy guarantee that removing the column-based sorting will return the table to *the* unsorted state before that sorting (and not to *a* unsorted state). That might mean that `TableView` will have to maintain the initial sorting somewhere. Or... it's a bad documentation :)

I still don't see how this is a bug in `SortedList`. It could be a bug in `TableView`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1519#issuecomment-2284512503

From lkostyra at openjdk.org  Mon Aug 12 17:13:51 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 12 Aug 2024 17:13:51 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v4]
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Merge two if image != nil statements together
  
  Those were unnecessarily split

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1532/files
  - new: https://git.openjdk.org/jfx/pull/1532/files/41cd6755..f6d065ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1532&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1532.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1532/head:pull/1532

PR: https://git.openjdk.org/jfx/pull/1532

From jpereda at openjdk.org  Mon Aug 12 17:24:40 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 17:24:40 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
 <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
 <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>
 <L4QDj-Dy-SPNPll0O9c7sGWqgLagUR1vebdnpnXCduA=.15368b98-0364-4884-be3e-c8ca09d0340d@github.com>
 <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com>
Message-ID: <io9LKobKtOdedtQuWZWs78UDjrMZvlgDAPdLr8-K3cc=.f3b8e5e6-0b85-4e31-852c-7a8862dcf0d5@github.com>

On Mon, 12 Aug 2024 16:22:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> By the way, this is how you can disable the cancel animation:
>> 
>> 
>> diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
>> index 50a79cabf6..373537f24e 100644
>> --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
>> +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassDraggingSource.m
>> @@ -40,6 +40,7 @@
>>  
>>  - (NSDragOperation)draggingSession:(NSDraggingSession *)session sourceOperationMaskForDraggingContext:(NSDraggingContext)context
>>  {
>> +     session.animatesToStartingPositionsOnCancelOrFail = NO;
>>      // The Command key masks out every operation other than NSDragOperationGeneric. We want
>>      // internal Move events to get through this filtering so we copy the Move bit into the
>>      // Generic bit and treat Generic as a synonym for Move.
>> 
>> 
>> I'm still in favour of this native animation, as opposed to the Windows case that doesn't have it. This can be a separated issue as well (unifying the animation in all platforms).
>
> I wanted to chime in, thought it might be unrelated:
> 
> In the context of a docking framework, it is impossible to disable the cancel animation.  We should have a way to disable it.  The use case is when the user drags and drops a tab/pane outside of the dockable windows.  In this case a new window should appear at the drop location, without the drag image animated back to the start position.
> 
> Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content.
> 
> These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example
> https://github.com/andy-goryachev/FxDock

I'm not sure if I follow, but about the cancel animation, do you mean that is not possible to disable it on macOS? Have you tested `session.animatesToStartingPositionsOnCancelOrFail`? 
As for the image, `DragBoard::setDragView` allows you setting any image that you need for the drag gesture, or am I missing something?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714139069

From angorya at openjdk.org  Mon Aug 12 17:30:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 17:30:36 GMT
Subject: RFR: 8333919: dragViewOffsetX/dragViewOffsetY are ignored for the
 dragView image [v2]
In-Reply-To: <io9LKobKtOdedtQuWZWs78UDjrMZvlgDAPdLr8-K3cc=.f3b8e5e6-0b85-4e31-852c-7a8862dcf0d5@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <10PgwCqZ3JJPS9pyVDVEksYTQfTwDDL7lIrveeqAWwo=.74733912-3a6e-4093-8f80-21517825a403@github.com>
 <sHtXAR3RFzqvOHeaCym1q7N5VhUhKJj9WIzAuvVnN-U=.c0d9fb76-e53c-4f6c-b5f8-e85b8546e1ce@github.com>
 <xDKgoLV4NDx1hySLwCY3ih3sTzUaOyxuvRwNQ5L5jxg=.d8476566-b2d8-427c-99b8-6a9645cecd59@github.com>
 <YXZByCdg2DqcOq5ae2NdEQF77PmoW3PRahDNziDXOhI=.eb2dc234-8b34-4d70-ae45-db0ff7ae77d2@github.com>
 <L4QDj-Dy-SPNPll0O9c7sGWqgLagUR1vebdnpnXCduA=.15368b98-0364-4884-be3e-c8ca09d0340d@github.com>
 <1QkkaonBSkvBQKqBoclyuYyp-dHLzpjMjBNKmjpsazA=.7729c5a5-4356-4cbd-99f2-928b9ee3556b@github.com>
 <io9LKobKtOdedtQuWZWs78UDjrMZvlgDAPdLr8-K3cc=.f3b8e5e6-0b85-4e31-852c-7a8862dcf0d5@github.com>
Message-ID: <YP18ozz3ZkPL64tXfvEopHpcssqO8wFUb_xEHIwE4Eo=.0e8e01c3-74bd-443e-8f8a-5e32149f51bf@github.com>

On Mon, 12 Aug 2024 17:21:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> I wanted to chime in, thought it might be unrelated:
>> 
>> In the context of a docking framework, it is impossible to disable the cancel animation.  We should have a way to disable it.  The use case is when the user drags and drops a tab/pane outside of the dockable windows.  In this case a new window should appear at the drop location, without the drag image animated back to the start position.
>> 
>> Another thing that is impossible is to control the drag image: sometimes one needs a scaled icon, sometimes one wants the full content.
>> 
>> These two issues basically prevent implementing a docking framework via DnD, one needs to use other solution, for example
>> https://github.com/andy-goryachev/FxDock
>
> I'm not sure if I follow, but about the cancel animation, do you mean that is not possible to disable it on macOS? Have you tested `session.animatesToStartingPositionsOnCancelOrFail`? 
> As for the image, `DragBoard::setDragView` allows you setting any image that you need for the drag gesture, or am I missing something?

it's been a while - java8 time frame - back then I was unable to find a way to disable animation on cancel.

as for image - I was setting large image and fx tried to scale it to be smaller, I was unable to force it to show the unscaled full size image.

also, why does the drag image look fuzzy on mac retina?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714146005

From lkostyra at openjdk.org  Mon Aug 12 17:34:41 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 12 Aug 2024 17:34:41 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
Message-ID: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com>

On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Add debug prints"
>   
>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.

buildSrc/genVSproperties.bat line 52:

> 50:     for %%a in (2022, 2019, 2017) do (
> 51:         set year=%%a
> 52:         for %%b in (Enterprise, Professional, Community) do (

Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022

Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714151393

From lkostyra at openjdk.org  Mon Aug 12 17:36:43 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 12 Aug 2024 17:36:43 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <Iz2PqyapfKSHAXjyNRjFQuSTtGJb1f_XlFWBNSXY7ZA=.c061c7bf-71e2-466e-be45-25b6561330ae@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Also I noticed the PR title does not match the JBS issue title - missed the macOS tag while copying. Will update it to match.

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284567585

From kcr at openjdk.org  Mon Aug 12 18:07:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 18:07:36 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com>
Message-ID: <S7f6fKsTRFkDm3jAFGQGwARQHuXJ8RS2fgu1GEnPPxY=.f12f27cd-7503-48fc-ad4f-30dbf7eda206@github.com>

On Mon, 12 Aug 2024 17:32:10 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Add debug prints"
>>   
>>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.
>
> buildSrc/genVSproperties.bat line 52:
> 
>> 50:     for %%a in (2022, 2019, 2017) do (
>> 51:         set year=%%a
>> 52:         for %%b in (Enterprise, Professional, Community) do (
> 
> Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
> 
> Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review.

Thanks, that would be helpful. Let me know what you find.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714186379

From nlisker at openjdk.org  Mon Aug 12 19:21:35 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 12 Aug 2024 19:21:35 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
Message-ID: <cNhw2t1dxIOLbv6ohtflPH2E8atdrIe2j_VfR0PW2tk=.b5e8d5b9-6b14-4d6e-9c2f-7789b543ef4b@github.com>

On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Add debug prints"
>   
>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.

The wiki page for building OpenJFX will also need an update.

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

PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284741466

From kcr at openjdk.org  Mon Aug 12 19:50:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 19:50:37 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <cNhw2t1dxIOLbv6ohtflPH2E8atdrIe2j_VfR0PW2tk=.b5e8d5b9-6b14-4d6e-9c2f-7789b543ef4b@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <cNhw2t1dxIOLbv6ohtflPH2E8atdrIe2j_VfR0PW2tk=.b5e8d5b9-6b14-4d6e-9c2f-7789b543ef4b@github.com>
Message-ID: <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com>

On Mon, 12 Aug 2024 19:18:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> The wiki page for building OpenJFX will also need an update.

Yes. I plan to (I meant to list that in the Description, but forgot to add it). Thanks for the reminder.

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

PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284787751

From prr at openjdk.org  Mon Aug 12 20:27:37 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Aug 2024 20:27:37 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <cNhw2t1dxIOLbv6ohtflPH2E8atdrIe2j_VfR0PW2tk=.b5e8d5b9-6b14-4d6e-9c2f-7789b543ef4b@github.com>
 <6m1ntAfN41A1g1mHqzYzTow9C-ys9xIKwV6z1UYm23A=.5bae6aee-ab99-4b79-9870-02dfc80aa158@github.com>
Message-ID: <YNBeRv6BxPjV0aPuoI_i12pMiiu9WRg5XpUVefO-yqA=.3f5019d9-3b4f-4a3a-aeae-044f2a7e5b07@github.com>

On Mon, 12 Aug 2024 19:48:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > The wiki page for building OpenJFX will also need an update.
> 
> Yes. I plan to (I meant to list that in the Description, but forgot to add it). Thanks for the reminder.

Yes indeed, Kevin and I discussed that at some length. What is there today is useless anyway.

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

PR Comment: https://git.openjdk.org/jfx/pull/1534#issuecomment-2284844571

From prr at openjdk.org  Mon Aug 12 20:44:39 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Aug 2024 20:44:39 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
Message-ID: <DscJxEVfxI9HSGLJXc0EZqXZkRz_ioLxgvSq4C38nHY=.db769b4c-5f52-4a53-9add-cdf0d79ae5d9@github.com>

On Mon, 12 Aug 2024 15:37:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Add debug prints"
>   
>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.

buildSrc/genVSproperties.bat line 27:

> 25: 
> 26: REM Windows bat file that runs vcvars64.bat for Visual Studio
> 27: REM and echos out a property file with the values of the environment

nit : I think it is usually spelt echoes.

buildSrc/genVSproperties.bat line 55:

> 53:             set edition=%%b
> 54:             for %%c in ("Program Files", "Program Files (x86)") do (
> 55:                 set ProgramFiles=%%~c

What does the ~ do here ?

buildSrc/win.gradle line 93:

> 91:         defineProperty("WINDOWS_VS_LIB", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;" + "$WINDOWS_SDK_DIR/lib;")
> 92:         defineProperty("WINDOWS_VS_LIBPATH", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;")
> 93:         def parfaitPath = IS_COMPILE_PARFAIT ? System.getenv().get("PARFAIT_PATH") + ";" : "";

Did you mean to remove parfaitPath ?

buildSrc/win.gradle line 113:

> 111:     IS_DEBUG_NATIVE ? ["/MDd", "/Od", "/Zi", "/DDEBUG"] : ["/O2", "/MD", "/DNDEBUG"]
> 112: 
> 113: // Serialize access to PDB file for debug builds if on VS2013 or later

The "if on VS2013 or later" part of the comment is obsolete.

buildSrc/win.gradle line 141:

> 139: 
> 140: // Remove C++ static linking if not on VS2010
> 141: ccFlags -= ["/D_STATIC_CPPLIB", "/D_DISABLE_DEPRECATE_STATIC_CPPLIB"]

The "if not on VS2010" part of the comment is obsolete.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714334014
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714339338
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714344403
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714342671
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714343779

From angorya at openjdk.org  Mon Aug 12 20:51:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 20:51:37 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <aLS-AN0wjiCdxPcKPLa209MfcNY9iBeRxXzNbhnlvBk=.ceae7b69-16ac-4272-af96-4f3b52d82952@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

FYI, I've added Drag and Drop page to the Monkey Tester for testing various options:
https://github.com/andy-goryachev-oracle/MonkeyTest

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284881877

From angorya at openjdk.org  Mon Aug 12 20:57:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 20:57:36 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <IFPJSg6t_o-IgX_x8kys4bMCg8BRMogGh0yNDMOipgQ=.7b680188-dd75-4f18-8a41-24c4f1cdd12d@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

To clarify my earlier comments:

1. my complaints are related, but outside of the scope for this PR
2. the Dragboard class allows for setting of drag view image, but it always tries to resize it to some arbitrary size - increase the size if the image is too small, scale down if it is too large.  There is no way to customize that (but should be!)
3. there is no public API to control drop cancellation behavior.  At the minimum, there should be a way to disable the scuttling behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284890339

From angorya at openjdk.org  Mon Aug 12 21:02:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 21:02:41 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <C7NYHGeoiChLpROUoNbHC1TNFsJWdvZlQLDC2v5zwds=.d2e4c095-2b1c-4526-b989-79c927fdf463@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Question: how should we handle the negative offsets?

The way javadoc is currently phrased, "offsetX x position of the cursor **over** the image" implies that the offset is clamped to be inside of the (scaled) image.  If so, the behavior appears to be correct even in the presence of infinities and NaNs (the latter produces 0 offset).

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284896632

From angorya at openjdk.org  Mon Aug 12 21:12:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 21:12:36 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <sz0tYVOfRZHldNyg1a2i1vqnxzD6d6vFQ9uwFnhV_4E=.9edf5267-61e9-473d-8552-4497b2605c94@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Another issue - out of scope for this PR - is the DRAG_DONE event missing any coordinates, regardless of whether it was dropped over the accepting target or non-accepting target or no target.  I think this was another reason I could not implement the docking framework via DnD.


{event=DRAG_DONE, screenX=0.0, screenY=0.0, sceneX=0.0, sceneY=0.0}

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

PR Comment: https://git.openjdk.org/jfx/pull/1532#issuecomment-2284911706

From kcr at openjdk.org  Mon Aug 12 21:31:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 21:31:49 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v3]
In-Reply-To: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
Message-ID: <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>

> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
> 
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
> 
> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
> 5. Removed the following unused variables:
> 
> DEVENVCMD
> DXSDK_DIR
> VS_VER
> 
> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
> 
> 
> I left some debug print statements in, and will remove them in a follow-on commit.
> 
> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1534/files
  - new: https://git.openjdk.org/jfx/pull/1534/files/b6972b36..4bd166ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1534.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1534/head:pull/1534

PR: https://git.openjdk.org/jfx/pull/1534

From kcr at openjdk.org  Mon Aug 12 21:31:49 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 21:31:49 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <DscJxEVfxI9HSGLJXc0EZqXZkRz_ioLxgvSq4C38nHY=.db769b4c-5f52-4a53-9add-cdf0d79ae5d9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <DscJxEVfxI9HSGLJXc0EZqXZkRz_ioLxgvSq4C38nHY=.db769b4c-5f52-4a53-9add-cdf0d79ae5d9@github.com>
Message-ID: <1DQuapCS3wwDNWPnidhB0lrKWdvHqL077Ve9IxxlF6k=.8522bca7-cd16-4067-967a-e14c343d9f31@github.com>

On Mon, 12 Aug 2024 20:31:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Add debug prints"
>>   
>>   This reverts commit 3ea8ee58867d21e5c0aeb6a22170cdc28dd7a486.
>
> buildSrc/genVSproperties.bat line 27:
> 
>> 25: 
>> 26: REM Windows bat file that runs vcvars64.bat for Visual Studio
>> 27: REM and echos out a property file with the values of the environment
> 
> nit : I think it is usually spelt echoes.

This was preexisting, but since I touched this line (to remove white space), I'll fix it.

> buildSrc/genVSproperties.bat line 55:
> 
>> 53:             set edition=%%b
>> 54:             for %%c in ("Program Files", "Program Files (x86)") do (
>> 55:                 set ProgramFiles=%%~c
> 
> What does the ~ do here ?

It strips the quotes.

> buildSrc/win.gradle line 113:
> 
>> 111:     IS_DEBUG_NATIVE ? ["/MDd", "/Od", "/Zi", "/DDEBUG"] : ["/O2", "/MD", "/DNDEBUG"]
>> 112: 
>> 113: // Serialize access to PDB file for debug builds if on VS2013 or later
> 
> The "if on VS2013 or later" part of the comment is obsolete.

I'll remove it.

> buildSrc/win.gradle line 141:
> 
>> 139: 
>> 140: // Remove C++ static linking if not on VS2010
>> 141: ccFlags -= ["/D_STATIC_CPPLIB", "/D_DISABLE_DEPRECATE_STATIC_CPPLIB"]
> 
> The "if not on VS2010" part of the comment is obsolete.

I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714379348
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714379591
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714384323
PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714384853

From kcr at openjdk.org  Mon Aug 12 21:31:50 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 21:31:50 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v3]
In-Reply-To: <DscJxEVfxI9HSGLJXc0EZqXZkRz_ioLxgvSq4C38nHY=.db769b4c-5f52-4a53-9add-cdf0d79ae5d9@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <DscJxEVfxI9HSGLJXc0EZqXZkRz_ioLxgvSq4C38nHY=.db769b4c-5f52-4a53-9add-cdf0d79ae5d9@github.com>
Message-ID: <WyHP-Q_9gO_CqsS-5OAm465mq5T8gF48ybASvN5a5Eg=.91215406-b497-437a-88de-8d4a5fdbfc3f@github.com>

On Mon, 12 Aug 2024 20:41:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> buildSrc/win.gradle line 93:
> 
>> 91:         defineProperty("WINDOWS_VS_LIB", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;" + "$WINDOWS_SDK_DIR/lib;")
>> 92:         defineProperty("WINDOWS_VS_LIBPATH", properties, "$WINDOWS_VS_VCINSTALLDIR/LIB;")
>> 93:         def parfaitPath = IS_COMPILE_PARFAIT ? System.getenv().get("PARFAIT_PATH") + ";" : "";
> 
> Did you mean to remove parfaitPath ?

Yes, it was intentional. Once I removed the (unused) default for `WINDOWS_VS_PATH`, that local variable was no longer referenced.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714383497

From prr at openjdk.org  Mon Aug 12 21:36:37 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 12 Aug 2024 21:36:37 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v3]
In-Reply-To: <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
Message-ID: <IBfS-PJTyBBWH0TU1re3jYNTeMAPg8QBIUKMVtDe8e8=.ec7addca-4141-4f85-a9e2-60612fc94acd@github.com>

On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2234058329

From angorya at openjdk.org  Mon Aug 12 22:03:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 22:03:39 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <yoz-pdwPJMV7W9fbeYYd8h3IFVIvnzmXH_zGW9MASWw=.42284c82-bfab-479b-98a7-bcfa692ab657@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053:

> 1051:                 float imageH = [image size].height;
> 1052: 
> 1053:                 if (offset.x < 0.0f) {

I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)?

Should the ifs be restructured so as not to pass NaN downstream?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714411657

From kcr at openjdk.org  Mon Aug 12 22:50:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 22:50:54 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <n_0AWAtdMFB3NtfCRyTiUTyytH_DfG1gWokZmoYD1Wg=.99bd57e4-fa02-420a-a8ae-fd45477dc10c@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Looks good to me. Unifying the behavior on Windows and Linux can be done in the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204).

If needed, additional follow-up issues can be filed.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234132296

From kcr at openjdk.org  Mon Aug 12 22:50:55 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 22:50:55 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <yoz-pdwPJMV7W9fbeYYd8h3IFVIvnzmXH_zGW9MASWw=.42284c82-bfab-479b-98a7-bcfa692ab657@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
 <yoz-pdwPJMV7W9fbeYYd8h3IFVIvnzmXH_zGW9MASWw=.42284c82-bfab-479b-98a7-bcfa692ab657@github.com>
Message-ID: <lLCZujMbFxYtwhllOqbl5VCXEDJiiky9j6kg0qPiUrs=.a0f5cdfb-7d4b-4e66-abc0-3775aa1f2c32@github.com>

On Mon, 12 Aug 2024 21:58:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge two if image != nil statements together
>>   
>>   Those were unnecessarily split
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053:
> 
>> 1051:                 float imageH = [image size].height;
>> 1052: 
>> 1053:                 if (offset.x < 0.0f) {
> 
> I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)?
> 
> Should the ifs be restructured so as not to pass NaN downstream?

That seems out of scope for this PR. We typically don't do any special processing to deal with NaN unless there is a problem. If needed, maybe it could be done as part of the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714438854

From kcr at openjdk.org  Mon Aug 12 22:53:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 22:53:52 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6
In-Reply-To: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
Message-ID: <IPfinzQqNdpA2IHuA-hoQvFfZU6Y8EwLzeyIb0o2Tzs=.4d505c43-2973-4618-8914-538c9fa6b9d8@github.com>

On Wed, 7 Aug 2024 00:26:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - libFFI updated to 3.4.6.
> - No additional changes are done.
> - Tested on Windows, macOS and Linux with all supported formats.

@tiainen Do you want to be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285031562

From angorya at openjdk.org  Mon Aug 12 23:09:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 23:09:56 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <YxC9xHzLSp0hbimtMjrom07IRKjN2us8McPlBESFJTM=.ae24a092-4e28-4e71-8414-18020566b567@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234162494

From angorya at openjdk.org  Mon Aug 12 23:09:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Aug 2024 23:09:57 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <lLCZujMbFxYtwhllOqbl5VCXEDJiiky9j6kg0qPiUrs=.a0f5cdfb-7d4b-4e66-abc0-3775aa1f2c32@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
 <yoz-pdwPJMV7W9fbeYYd8h3IFVIvnzmXH_zGW9MASWw=.42284c82-bfab-479b-98a7-bcfa692ab657@github.com>
 <lLCZujMbFxYtwhllOqbl5VCXEDJiiky9j6kg0qPiUrs=.a0f5cdfb-7d4b-4e66-abc0-3775aa1f2c32@github.com>
Message-ID: <kcA7r6SxSyttsrV7dvdQaM3Xy6_jS-ezC-T5OlXDp6o=.e238f117-c789-4d02-8bce-a3db6cc06c18@github.com>

On Mon, 12 Aug 2024 22:38:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1053:
>> 
>>> 1051:                 float imageH = [image size].height;
>>> 1052: 
>>> 1053:                 if (offset.x < 0.0f) {
>> 
>> I am puzzled a bit: a NaN input seem to produce NaN offsets, yet the testing shows that it behaves as if 0 offsets (possibly in the native code)?
>> 
>> Should the ifs be restructured so as not to pass NaN downstream?
>
> That seems out of scope for this PR. We typically don't do any special processing to deal with NaN unless there is a problem. If needed, maybe it could be done as part of the follow-up bug [JDK-8338204](https://bugs.openjdk.org/browse/JDK-8338204).

Sounds good, especially since it seems to treat NaNs as 0's.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1532#discussion_r1714458124

From kcr at openjdk.org  Mon Aug 12 23:18:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Aug 2024 23:18:53 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6
In-Reply-To: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
Message-ID: <hp7bnjvPHmYY4NQrqdzaiG6Os0RIxv2VDSjFUe9Wnv8=.ff258b51-9fa5-417f-bee2-fefa0a8c099e@github.com>

On Wed, 7 Aug 2024 00:26:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - libFFI updated to 3.4.6.
> - No additional changes are done.
> - Tested on Windows, macOS and Linux with all supported formats.

I see one minor difference between the upstream and your PR in a commented out line of code in `sysv_intel.S`. I don't know whether it is significant (I guess not, as long as it compiles with the current inline comment style).


diff -u -w -r ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S ./src/x86/sysv_intel.S
--- ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S   2024-08-12 15:59:14.597741100 -0700
+++ ./src/x86/sysv_intel.S      2024-08-12 16:05:42.708534300 -0700
@@ -102,7 +102,7 @@
         mov         ecx, [12+ebp]               /* load return type code */
         mov     [ebp+8], ebx            /* preserve %ebx */
 L(UW2):
-        // cfi_rel_offset(%ebx, 8)
+       /* cfi_rel_offset(%ebx, 8) */

         and     ecx, X86_RET_TYPE_MASK
         lea     ebx, [L(store_table) + ecx * 8]

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

PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285054088

From jpereda at openjdk.org  Mon Aug 12 23:41:54 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 12 Aug 2024 23:41:54 GMT
Subject: RFR: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored
 for the dragView image [v4]
In-Reply-To: <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
 <3ylXbo8GGYhtrYI9KaapW98jJ4ACpJ0B4QUvldDdR10=.e962b141-5f0c-42b2-920d-0de620fc4e1e@github.com>
Message-ID: <jeMAFDt5RTqGDqjTpvnChd2QvNiPHkLn4QAcdepzwd0=.5be1f7c8-34f2-4b62-977c-4cf2bfcf7b07@github.com>

On Mon, 12 Aug 2024 17:13:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
>> 
>> This change fixes this mistake. Now drag image should be properly offset.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge two if image != nil statements together
>   
>   Those were unnecessarily split

Looks good

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

Marked as reviewed by jpereda (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1532#pullrequestreview-2234191527

From almatvee at openjdk.org  Tue Aug 13 01:05:51 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 13 Aug 2024 01:05:51 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6
In-Reply-To: <hp7bnjvPHmYY4NQrqdzaiG6Os0RIxv2VDSjFUe9Wnv8=.ff258b51-9fa5-417f-bee2-fefa0a8c099e@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
 <hp7bnjvPHmYY4NQrqdzaiG6Os0RIxv2VDSjFUe9Wnv8=.ff258b51-9fa5-417f-bee2-fefa0a8c099e@github.com>
Message-ID: <d-VBAVDhVTqb3qYQBzY2LRsH8aKa-jT5_pwuhzcUiUc=.edd14962-1bf5-40ec-a1b3-a4571d19cd2a@github.com>

On Mon, 12 Aug 2024 23:15:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I see one minor difference between the upstream and your PR in a commented out line of code in `sysv_intel.S`. I don't know whether it is significant (I guess not, as long as it compiles with the current inline comment style).
> 
> ```
> diff -u -w -r ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S ./src/x86/sysv_intel.S
> --- ../../jfx-tmp/jfx/rt/modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/x86/sysv_intel.S   2024-08-12 15:59:14.597741100 -0700
> +++ ./src/x86/sysv_intel.S      2024-08-12 16:05:42.708534300 -0700
> @@ -102,7 +102,7 @@
>          mov         ecx, [12+ebp]               /* load return type code */
>          mov     [ebp+8], ebx            /* preserve %ebx */
>  L(UW2):
> -        // cfi_rel_offset(%ebx, 8)
> +       /* cfi_rel_offset(%ebx, 8) */
> 
>          and     ecx, X86_RET_TYPE_MASK
>          lea     ebx, [L(store_table) + ecx * 8]
> ```

Yes, it compiles fine. It was changed by libFFI itself in 3.4.6. I think to be inline with rest of comments in this file.

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

PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2285153581

From lkostyra at openjdk.org  Tue Aug 13 06:30:58 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 13 Aug 2024 06:30:58 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <S7f6fKsTRFkDm3jAFGQGwARQHuXJ8RS2fgu1GEnPPxY=.f12f27cd-7503-48fc-ad4f-30dbf7eda206@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com>
 <S7f6fKsTRFkDm3jAFGQGwARQHuXJ8RS2fgu1GEnPPxY=.f12f27cd-7503-48fc-ad4f-30dbf7eda206@github.com>
Message-ID: <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com>

On Mon, 12 Aug 2024 18:04:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> buildSrc/genVSproperties.bat line 52:
>> 
>>> 50:     for %%a in (2022, 2019, 2017) do (
>>> 51:         set year=%%a
>>> 52:         for %%b in (Enterprise, Professional, Community) do (
>> 
>> Quick two cents from me on this part - Microsoft also offers a free CLI-only version of Visual Studio called "Build Tools for Visual Studio" - https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
>> 
>> Those install in a separate "BuildTools" directory (so ex. `C:\Program Files\Microsoft Visual Studio\2022\BuildTools...`). Internally the directory structure is the same and all the scripts we need are also there, so it seems like this should work. I think we could also add BuildTools as an option here? I can check on my machine if it builds as part of this review.
>
> Thanks, that would be helpful. Let me know what you find.

I checked on a Win 11 system where Build Tools 2022 are installed in default directory (no other Visual Studio edition) and the build failed with "Cannot locate Visual Studio compilers" message. Adding `BuildTools` as an option to this loop fixed it and JFX built properly (checked without Media and Webkit). Alternatively, setting `VSCOMMONTOOLS` also helps, but I think we can easily add `BuildTools` as an option here.

As a side-note - building without this PR on the same system also failed so it doesn't necessarily introduce a regression, but I think it would be a worthy addition regardless.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1714733992

From lkostyra at openjdk.org  Tue Aug 13 06:34:57 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 13 Aug 2024 06:34:57 GMT
Subject: Integrated: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are
 ignored for the dragView image
In-Reply-To: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
References: <4cAPbhUtjQFIavyEIlQuOiTZNjmQ3-vtvMsWI5B9u_c=.247f8cc4-0e9f-429f-967e-ba7944cae3f3@github.com>
Message-ID: <5JXB5AKz4i9YpaLuTtJZE0WSYmvhw2Tvv7xT_7vsLfE=.6f262d9b-e49b-41fa-a872-ee00a524be9f@github.com>

On Thu, 8 Aug 2024 12:35:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> When fixing [JDK-8233955](https://bugs.openjdk.org/browse/JDK-8233955) offset calculation was left out, which made Dragboard offset API not work on macOS.
> 
> This change fixes this mistake. Now drag image should be properly offset.

This pull request has now been integrated.

Changeset: 00c74ebf
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/00c74ebf96cbe24b833cb51d2ee533e69396c846
Stats:     24 lines in 1 file changed: 7 ins; 10 del; 7 mod

8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image

Reviewed-by: jpereda, kcr, angorya

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

PR: https://git.openjdk.org/jfx/pull/1532

From nlisker at openjdk.org  Tue Aug 13 11:53:59 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 13 Aug 2024 11:53:59 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
Message-ID: <iHuuXZhDCeJV4fa3NjeutsduWiaHY_vMNcxHIiAsclc=.af28ab04-764e-4804-87ef-6c78792b9ee8@github.com>

On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:

> 88:     private final int specificity;
> 89: 
> 90:     @SuppressWarnings("removal")

What is this removal warning suppression? I know it was there before these changes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715163301

From nlisker at openjdk.org  Tue Aug 13 11:56:54 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 13 Aug 2024 11:56:54 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
Message-ID: <zo3FrrQIREFQXi330fte8cq3GPNTE1_PG6Tltf_nvEQ=.848495a2-c4ef-4e77-972d-201b0ba462fc@github.com>

On Wed, 7 Aug 2024 02:13:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug

I see a lot of aversion from for-each loops in favor of indexed loops in the classes this PR touches. While I don't suggest to change it here, any idea why?

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286067091

From jhendrikx at openjdk.org  Tue Aug 13 12:02:59 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 12:02:59 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <zo3FrrQIREFQXi330fte8cq3GPNTE1_PG6Tltf_nvEQ=.848495a2-c4ef-4e77-972d-201b0ba462fc@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <zo3FrrQIREFQXi330fte8cq3GPNTE1_PG6Tltf_nvEQ=.848495a2-c4ef-4e77-972d-201b0ba462fc@github.com>
Message-ID: <Ja7YAC79g6pGhBGPI2ThUCXv57g3qG_hNQUJ8xlCQQw=.b77ad7ab-74f4-4c52-8804-901141ecfc1f@github.com>

On Tue, 13 Aug 2024 11:54:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I see a lot of aversion from for-each loops in favor of indexed loops in the classes this PR touches. While I don't suggest to change it here, any idea why?

It's just the style the original code was written with.  There is no reason to write the binary load/save code like this (as IO will be a far greater bottleneck).

There are/were other parts (in `Match` and the selector subtypes) however that are performance sensitive, so perhaps the entire classes were just written in a similar style "just in case".

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286078330

From jhendrikx at openjdk.org  Tue Aug 13 12:07:58 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 12:07:58 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <Q_0rih6AZecqeP4Sr6K5oFbBbtSBwGt2vagJbHoR5aU=.6c88ee0e-8e1d-4491-85c5-eabe241890f3@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <iHuuXZhDCeJV4fa3NjeutsduWiaHY_vMNcxHIiAsclc=.af28ab04-764e-4804-87ef-6c78792b9ee8@github.com>
 <Q_0rih6AZecqeP4Sr6K5oFbBbtSBwGt2vagJbHoR5aU=.6c88ee0e-8e1d-4491-85c5-eabe241890f3@github.com>
Message-ID: <gEMO4sNZBwbz-0bfeDm-r0D9peh2_MsHNVcqKynE78s=.d91b573f-9a9b-471d-b829-e5ac3ebb60b7@github.com>

On Tue, 13 Aug 2024 12:05:18 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
>> 
>>> 88:     private final int specificity;
>>> 89: 
>>> 90:     @SuppressWarnings("removal")
>> 
>> What is this removal warning suppression? I know it was there before these changes.
>
> `SimpleSelector` was deprecated for removal (from the public javafx.css package). Now that it is moved to the internal package, the deprecation on that was also removed.  The `SuppressWarnings` is therefore no longer needed here as the deprecation is no longer present on the now internal `SimpleSelector` type.

The diff seems to show I did not remove that line, but it should no longer be needed.  I'll check.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715180851

From jhendrikx at openjdk.org  Tue Aug 13 12:07:58 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 12:07:58 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <iHuuXZhDCeJV4fa3NjeutsduWiaHY_vMNcxHIiAsclc=.af28ab04-764e-4804-87ef-6c78792b9ee8@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <iHuuXZhDCeJV4fa3NjeutsduWiaHY_vMNcxHIiAsclc=.af28ab04-764e-4804-87ef-6c78792b9ee8@github.com>
Message-ID: <Q_0rih6AZecqeP4Sr6K5oFbBbtSBwGt2vagJbHoR5aU=.6c88ee0e-8e1d-4491-85c5-eabe241890f3@github.com>

On Tue, 13 Aug 2024 11:51:39 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
> 
>> 88:     private final int specificity;
>> 89: 
>> 90:     @SuppressWarnings("removal")
> 
> What is this removal warning suppression? I know it was there before these changes.

`SimpleSelector` was deprecated for removal (from the public javafx.css package). Now that it is moved to the internal package, the deprecation on that was also removed.  The `SuppressWarnings` is therefore no longer needed here as the deprecation is no longer present on the now internal `SimpleSelector` type.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715180348

From jhendrikx at openjdk.org  Tue Aug 13 12:18:12 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 12:18:12 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
Message-ID: <YsyVcFUQV_PbLr3c-ecfFQEuVAO6LlVnJxdIyeMqUVY=.3022f845-4f8c-4c30-812f-25d7730e4686@github.com>

On Wed, 7 Aug 2024 22:31:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSelector.java line 75:
> 
>> 73:     /**
>> 74:      * The relationships between the selectors
>> 75:      * @return Immutable List&lt;Combinator&gt;
> 
> minor: would {@code List<Combinator>} be a better choice here, if it works?

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1715189665

From jhendrikx at openjdk.org  Tue Aug 13 12:18:12 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 12:18:12 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v8]
In-Reply-To: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
Message-ID: <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>

> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
> 
> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
> 
> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
> 
> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
> 
> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
> - No need anymore for the `SimpleSelectorShim`

John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:

 - Fix javadoc
 - Remove unnecessary suppress warnings

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1333/files
  - new: https://git.openjdk.org/jfx/pull/1333/files/39c94408..875c1a88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1333.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333

PR: https://git.openjdk.org/jfx/pull/1333

From kcr at openjdk.org  Tue Aug 13 12:34:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Aug 2024 12:34:52 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6
In-Reply-To: <d-VBAVDhVTqb3qYQBzY2LRsH8aKa-jT5_pwuhzcUiUc=.edd14962-1bf5-40ec-a1b3-a4571d19cd2a@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
 <hp7bnjvPHmYY4NQrqdzaiG6Os0RIxv2VDSjFUe9Wnv8=.ff258b51-9fa5-417f-bee2-fefa0a8c099e@github.com>
 <d-VBAVDhVTqb3qYQBzY2LRsH8aKa-jT5_pwuhzcUiUc=.edd14962-1bf5-40ec-a1b3-a4571d19cd2a@github.com>
Message-ID: <G_7N6RZkcxf283mcZ8U1n510AFRYYoRX2-v3FYLSnnk=.0efba160-6fbb-4685-a8e3-a724d1cb6f9c@github.com>

On Tue, 13 Aug 2024 01:03:32 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Yes, it compiles fine. It was changed by libFFI itself in 3.4.6. I think to be inline with rest of comments in this file.

What I meant was that you missed making that change when you updated the file. The old line with the inline comment style is still in our copy of the file. So it no longer matches the upstream libffi 3.4.6. It seems best to apply that part of the patch so that we will match the upstream version of the file.

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

PR Comment: https://git.openjdk.org/jfx/pull/1531#issuecomment-2286144930

From nlisker at openjdk.org  Tue Aug 13 14:13:59 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 13 Aug 2024 14:13:59 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>
Message-ID: <nN3Vy1Xu8D-6Nh8q7kL8WjMVytT-G-e-d9c7Dq4pgxI=.deb49f23-3a61-46df-927f-564b20d4bc6d@github.com>

On Wed, 7 Aug 2024 22:47:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> oops, yes, you did, my mistake. the master progressed since then, got me confused.
> 
> I got a bunch of errors again after switching:
> 
> ```
> Description	Resource	Type	Path	Location
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3024
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3214
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3267
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3282
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3607
> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3651
> ```

I got these too, as well as many

The method createShader(String, InputStream, Map<String,Integer>, Map<String,Integer>, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap<String,Integer>, HashMap<String,Integer>, int, boolean, boolean)

I haven't worked on this repo for 3 weeks, what changed?

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286360227

From jhendrikx at openjdk.org  Tue Aug 13 14:20:58 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Aug 2024 14:20:58 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <nN3Vy1Xu8D-6Nh8q7kL8WjMVytT-G-e-d9c7Dq4pgxI=.deb49f23-3a61-46df-927f-564b20d4bc6d@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>
 <nN3Vy1Xu8D-6Nh8q7kL8WjMVytT-G-e-d9c7Dq4pgxI=.deb49f23-3a61-46df-927f-564b20d4bc6d@github.com>
Message-ID: <shz9RLO9Nl6oM1sz3ZjDXgv4vcjNE7keS8v2Med3_mY=.c0ae1e94-9c49-4851-9d3b-c454bf4ffcc5@github.com>

On Tue, 13 Aug 2024 14:10:52 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > oops, yes, you did, my mistake. the master progressed since then, got me confused.
> > I got a bunch of errors again after switching:
> > ```
> > Description	Resource	Type	Path	Location
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3024
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3214
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3267
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3282
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3607
> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3651
> > ```
> 
> I got these too, as well as many
> 
> ```
> The method createShader(String, InputStream, Map<String,Integer>, Map<String,Integer>, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap<String,Integer>, HashMap<String,Integer>, int, boolean, boolean)
> ```
> 
> I haven't worked on this repo for 3 weeks, what changed?

The ones mentioned by Andy I also see, and are just a difference in opinion between Javac and ECJ, or perhaps a bug in the incremental compilation that Eclipse does (as they usually only appear when it does an incremental compile, not a full one).  When those occur, I just select them and remove them from the errors list.

The others I haven't seen before, and I'm not seeing them now.  I did a search for `createShader` but didn't see anything unusual.

I'm not aware of any special changes in the last 3 weeks.  I did a fresh import recently, and nothing strange popped up.

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286377890

From kcr at openjdk.org  Tue Aug 13 14:42:59 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Aug 2024 14:42:59 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <shz9RLO9Nl6oM1sz3ZjDXgv4vcjNE7keS8v2Med3_mY=.c0ae1e94-9c49-4851-9d3b-c454bf4ffcc5@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>
 <nN3Vy1Xu8D-6Nh8q7kL8WjMVytT-G-e-d9c7Dq4pgxI=.deb49f23-3a61-46df-927f-564b20d4bc6d@github.com>
 <shz9RLO9Nl6oM1sz3ZjDXgv4vcjNE7keS8v2Med3_mY=.c0ae1e94-9c49-4851-9d3b-c454bf4ffcc5@github.com>
Message-ID: <xQvbCsT6TqdZxG74avuDtQq8WAHcOnGMPeATSE-gKjQ=.b4ba979e-3349-4c86-855a-1c6361bea3d8@github.com>

On Tue, 13 Aug 2024 14:18:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> ```
> The method createShader(String, InputStream, Map<String,Integer>, Map<String,Integer>, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap<String,Integer>, HashMap<String,Integer>, int, boolean, boolean)
> ```
> 
> I haven't worked on this repo for 3 weeks, what changed?

You need to do a clean build. This method was changed by [JDK-8336624](https://bugs.openjdk.org/browse/JDK-8336624) / PR #1530

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2286427951

From nlisker at openjdk.org  Tue Aug 13 15:28:56 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 13 Aug 2024 15:28:56 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v3]
In-Reply-To: <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
Message-ID: <AZfZO-II2we3Gt23bz8g9OyRwgqZFWJEPPwzPEGH1lk=.2490ed41-2a16-4006-a8c4-412baf8b7478@github.com>

On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Continuing from https://github.com/openjdk/jfx/pull/1333#issuecomment-2286427951, I updated my VS and did a clean build on `master` and got

> java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.33.31629/bin/Hostx64/x64/cl.exe''

After applying this patch, my clean build was successful (up to the webkit part). I then removed the `VS150COMNTOOLS` env var and tried another clean build and it worked as well.

Tested on Windows 10.

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

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2235891455

From almatvee at openjdk.org  Tue Aug 13 19:04:09 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 13 Aug 2024 19:04:09 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6 [v2]
In-Reply-To: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
Message-ID: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com>

> - libFFI updated to 3.4.6.
> - No additional changes are done.
> - Tested on Windows, macOS and Linux with all supported formats.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8336938: Update libFFI to 3.4.6 [v2]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1531/files
  - new: https://git.openjdk.org/jfx/pull/1531/files/e51e5c71..c4a9d5b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1531&range=00-01

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

PR: https://git.openjdk.org/jfx/pull/1531

From kcr at openjdk.org  Tue Aug 13 19:09:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Aug 2024 19:09:54 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6 [v2]
In-Reply-To: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
 <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com>
Message-ID: <fityoY4qpfMK-gVG8lRY7eIqJ4y6T6PnFzqBdE9TZp0=.fa39ae2c-dd00-4bef-aa11-692eb87747f6@github.com>

On Tue, 13 Aug 2024 19:04:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - libFFI updated to 3.4.6.
>> - No additional changes are done.
>> - Tested on Windows, macOS and Linux with all supported formats.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336938: Update libFFI to 3.4.6 [v2]

Code changes look good. Testing looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1531#pullrequestreview-2236361557

From mhanl at openjdk.org  Tue Aug 13 19:26:56 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 13 Aug 2024 19:26:56 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v3]
In-Reply-To: <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <QKmYanmMmRStXsPjvRoMmVDUZeZClCHOJKVasYle1Uc=.5a4924fc-6825-49d2-9ca4-8138582720eb@github.com>
Message-ID: <F5XgFcti1enj1kjniFxRdaCYgeHPcjECKIXzMFXU2-I=.1f9709c3-bb72-4567-b29a-23231be031a1@github.com>

On Mon, 12 Aug 2024 21:31:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Changes look good and also worked for me.
Removed the `VS150COMNTOOLS` variable and rebuild the project.

EDIT: Tested on Windows 11.

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2236391549

From angorya at openjdk.org  Tue Aug 13 21:06:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:06:57 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v4]
In-Reply-To: <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
Message-ID: <lKNCBoV_JRIeKh9vxmEZg-AUvI0bSOSWpEvatevR4rc=.fb03c102-2b59-4186-adf6-ea29bb42d73e@github.com>

On Sat, 10 Aug 2024 16:21:11 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> This PR is a fix for another IOOBE that I discovered while working on #1476.
>> 
>> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
>> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
>> 
>> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
>> 
>> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
>> 
>> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
>> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.
>
> Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - test "negative" style class in BarChartTest tests
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>  - fix "negative" style class when series is changed
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>    
>    # Conflicts:
>    #	modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java
>  - BarChart: Fix adding non-empty series
>  - BarChart: Add styleClass "negative" for added data

thank you for making the changes!  looks good now.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1488#pullrequestreview-2236574603

From angorya at openjdk.org  Tue Aug 13 21:20:55 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:20:55 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v8]
In-Reply-To: <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
Message-ID: <v5a2ZaMPnhsg2eaqaYExaJng5c2_AXgQcSXdgfpai_8=.161d98e3-4bb7-4657-9b26-8c32ce36e4f7@github.com>

On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix javadoc
>  - Remove unnecessary suppress warnings

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2236600499

From angorya at openjdk.org  Tue Aug 13 21:35:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:35:11 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
Message-ID: <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>

> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
> 
> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
> 
> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.

Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:

 - avoid csr
 - Merge remote-tracking branch 'origin/master' into ag.consume
 - only if consumed
 - only when consumed
 - propagate
 - cleanup
 - simpler
 - event helper
 - copy for test
 - propagate consume action

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1523/files
  - new: https://git.openjdk.org/jfx/pull/1523/files/551ed976..48022d6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1523&range=00-01

  Stats: 1379 lines in 29 files changed: 1135 ins; 90 del; 154 mod
  Patch: https://git.openjdk.org/jfx/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1523/head:pull/1523

PR: https://git.openjdk.org/jfx/pull/1523

From angorya at openjdk.org  Tue Aug 13 21:42:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:42:56 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
Message-ID: <9dThcWI8O458E7q99q_V2LCf2DAIubiD0ypNkSLKUNw=.4e67118b-e815-4c93-9dc5-ac29f79c53f5@github.com>

On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
>> 
>> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
>> 
>> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - avoid csr
>  - Merge remote-tracking branch 'origin/master' into ag.consume
>  - only if consumed
>  - only when consumed
>  - propagate
>  - cleanup
>  - simpler
>  - event helper
>  - copy for test
>  - propagate consume action

Removed 'final' keyword from existing public APIs.

The changes are limited to TextFieldBehavior and SpinnerSkin.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2287183307

From angorya at openjdk.org  Tue Aug 13 21:42:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:42:56 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
Message-ID: <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>

On Fri, 9 Aug 2024 20:16:29 GMT, Martin Fox <mfox at openjdk.org> wrote:

> An EventDispatcher that creates a new event without linking it to the original will break this PR. But that's a consequence you're creating. You can't say the developer is making a choice about event linking when the very notion is new with this PR.

Actually, this statement is not correct: the consumed flag will be propagated, but only if `propagateConsume` was set by the helper, which is being done in a very specific case.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2287186541

From angorya at openjdk.org  Tue Aug 13 21:54:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Aug 2024 21:54:02 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <nsVBnxrCJjQiGinej0m29z78oV8TamX7tJX4C3RTc7E=.40a4a148-c19d-48b3-be92-883776955b7d@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

Could we get this reviewed please?  Perhaps @lukostyra or @beldenfox ?

Also, there was a comment from @andzsinszan 

> TextFieldTableCell -> a bit buggy

has it been looked at?

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2287200158

From kcr at openjdk.org  Wed Aug 14 02:21:30 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 02:21:30 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v4]
In-Reply-To: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
Message-ID: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>

> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
> 
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
> 
> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
> 5. Removed the following unused variables:
> 
> DEVENVCMD
> DXSDK_DIR
> VS_VER
> 
> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
> 
> 
> I left some debug print statements in, and will remove them in a follow-on commit.
> 
> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Look for BuildTools if other VS editions not found

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1534/files
  - new: https://git.openjdk.org/jfx/pull/1534/files/4bd166ea..6cd3f239

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1534&range=02-03

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

PR: https://git.openjdk.org/jfx/pull/1534

From kcr at openjdk.org  Wed Aug 14 02:21:30 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 02:21:30 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v2]
In-Reply-To: <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <qWVMH087qEOl200mVrZOT42I4PV_NWazM2llluWl-Og=.8fa829f7-000a-4463-bbfa-26c2f650d4b9@github.com>
 <29t5_6eG_DHQ7vnsCTsTGbbqC64_bWwrIuriL2Usp5c=.f5c23666-b874-4e42-b04d-94d5e7004082@github.com>
 <S7f6fKsTRFkDm3jAFGQGwARQHuXJ8RS2fgu1GEnPPxY=.f12f27cd-7503-48fc-ad4f-30dbf7eda206@github.com>
 <3ELosjv6Xqh7GRy6eU9nhZ9G4BjZJ6fIwDHza1JiMMQ=.696a4555-fff2-46f9-b3dd-a0a0981afa02@github.com>
Message-ID: <Z9vcC07uFRpU6h489v7WaWEFOotQuLbgVLg0aEc7qac=.c6f6c138-b03b-4b1e-8f1b-e8721abf7219@github.com>

On Tue, 13 Aug 2024 06:27:51 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thanks, that would be helpful. Let me know what you find.
>
> I checked on a Win 11 system where Build Tools 2022 are installed in default directory (no other Visual Studio edition) and the build failed with "Cannot locate Visual Studio compilers" message. Adding `BuildTools` as an option to this loop fixed it and JFX built properly (checked without Media and Webkit). Alternatively, setting `VSCOMMONTOOLS` also helps, but I think we can easily add `BuildTools` as an option here.
> 
> As a side-note - building without this PR on the same system also failed so it doesn't necessarily introduce a regression, but I think it would be a worthy addition regardless.

I decided to go ahead and add this. Can you test and review it?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1534#discussion_r1716227825

From azvegint at openjdk.org  Wed Aug 14 06:27:19 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 14 Aug 2024 06:27:19 GMT
Subject: RFR: 8337827: [XWayland] Skip failing tests on Wayland
Message-ID: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>

This changeset introduces the `Util.isOnWayland()` method and skips failing tests on Wayland.

After that, all tests run on Wayland without failures.

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

Commit messages:
 - add javadoc
 - 8337827: [XWayland] Skip failing tests on Wayland

Changes: https://git.openjdk.org/jfx/pull/1536/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1536&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337827
  Stats: 31 lines in 4 files changed: 25 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1536.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1536/head:pull/1536

PR: https://git.openjdk.org/jfx/pull/1536

From lkostyra at openjdk.org  Wed Aug 14 08:28:59 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 14 Aug 2024 08:28:59 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v4]
In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
Message-ID: <oArtYjQcOBXpNtaEyPH6AvBB2OgzQSuQOR8S_Qno3yg=.27f7907b-9d6e-4b49-92e3-747c54cf845a@github.com>

On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Look for BuildTools if other VS editions not found

Looks good.

Tested a clean build on two Win 11 machines (one with VS 2022 Pro, one with VS 2022 Build Tools) and everything built with no issues.

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2237487481

From duke at openjdk.org  Wed Aug 14 10:41:57 2024
From: duke at openjdk.org (Dirk Lemmermann)
Date: Wed, 14 Aug 2024 10:41:57 GMT
Subject: RFR: 8337656 iOS WebView Position
In-Reply-To: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
References: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
Message-ID: <OXCXz2rFECzwGZ5yX9Js_Yd-Vhjhcc3XDhaT3gAFKuM=.a622c48e-c4b0-40a3-8fcd-68e22d4024d3@github.com>

On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Fixing WebView on iOS
> (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.)
> 
> @johanvos 
> If this looks reasonable to you, can you provide a test build for @dlemmermann ?
> Then he can test it with his JFX-Central iOS version.

The proper positioning of the WebView is the last thing missing for us to go for a release. Would be great to know whether we can use the WebView for displaying YouTube videos or not. Any support in this area would be much appreciated.

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

PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2288414826

From nlisker at openjdk.org  Wed Aug 14 11:11:01 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 14 Aug 2024 11:11:01 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v4]
In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
Message-ID: <14zBPDcoJXuCNTCeJOjqly3LMI_vulye9I77fgt4OQk=.ed76334b-9235-464f-94fc-de81501ca5a9@github.com>

On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Look for BuildTools if other VS editions not found

Re-approving

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

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2237844252

From nlisker at gmail.com  Wed Aug 14 12:03:35 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 14 Aug 2024 15:03:35 +0300
Subject: RichTextArea: API Review
In-Reply-To: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>

My questions are similar to the ones in the previous discussion, but now I
can be more specific.

I see a list of "building blocks" in
https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically,
two types of building blocks additions are important as I see it: rich
text-specific ones like document models and a way to add decorations/colors
etc., and the split of controls in general into skin/input/behavior (on
which there has been a long discussion). My questions are:

1. If these are provided to the user, how difficult is it for them to
compose a RTA? JavaFX doesn't provide some somewhat-common controls that
you see in various other libraries with the reasoning that the library
should give the user the ability to create their own controls (which is not
so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
2. Can these building blocks be used to enhance existing controls? For
example, to help with TextArea's performance with long texts, or allow rich
text-like features in other controls, like the squiggly red line under the
text in a TextField?
3. As also mentioned in the proposal, there are already 3rd party RTAs -
RichTextFX and Gluon's. Does the proposed RTA offer more than these
(besides the ease of use by being in JavaFX)? Do the building blocks of
these offer advantages that the proposed building blocks don't? An abstract
test that can be done is to see if these controls can be "retrofitted" with
the proposed new building blocks (no need to actually rewrite the code). If
not, it could hint to an incompatibility or a limit of the proposal that
makes it less appealing.

Thanks,
Nir


On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Dear fellow developers:
>
>
>
> Thank you for the early feedback on the RichTextArea proposal [0].
>
>
>
> We are moving to the next phase by submitting the public pull request [1].
> The main goal is to include the new control in an incubating module [8],
> hopefully in jfx24, as a means of putting non-final API in the hands of
> developers while the API and implementation progress towards either
> finalization or removal in a future release.
>
>
>
> For your convenience, two test applications are provided -
> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new
> controls with a number of different models.  In addition to these two
> testers, please check out a simple standalone rich text editor application,
> *RichEditorDemoApp*,
>
>
>
> We would encourage anyone - the javafx developers, and especially the
> application developers, to take a look at the public API [3].  It's
> probably less important at this stage to do a deep code review of the
> implementation, but we would certainly appreciate and welcome your code
> review comments.
>
>
>
> Thank you in advance,
>
> -andy
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>
> [1] Pull request: https://github.com/openjdk/jfx/pull/1524
>
> [2] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [3] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [4] CSS Reference:
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>
> [5] Behavior doc:
> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>
> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [7] Previous (now obsolete) draft pull request:
> https://github.com/openjdk/jfx/pull/1374
>
> [8] Incubator module JEP:
> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/a5ab4859/attachment.htm>

From mhanl at openjdk.org  Wed Aug 14 13:34:57 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Aug 2024 13:34:57 GMT
Subject: RFR: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is
 not set [v4]
In-Reply-To: <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
 <6wffZBTMZ6wNo-5vWRplWbX4DdZ9ZoRQzEZwZs-SYXU=.2d7a629e-1ea1-47fb-b48c-a253582ec14a@github.com>
Message-ID: <JhGIdkVQJCL6J-uBwjSrRf7D3soMlncoKLxQDMVxIS0=.c68bc3f3-639f-4746-84fc-69493ee573cf@github.com>

On Wed, 14 Aug 2024 02:21:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
>> 
>> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
>> 
>> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
>> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
>> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
>> 5. Removed the following unused variables:
>> 
>> DEVENVCMD
>> DXSDK_DIR
>> VS_VER
>> 
>> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
>> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
>> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
>> 
>> 
>> I left some debug print statements in, and will remove them in a follow-on commit.
>> 
>> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Look for BuildTools if other VS editions not found

Marked as reviewed by mhanl (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1534#pullrequestreview-2238184522

From quizynox at gmail.com  Wed Aug 14 13:35:42 2024
From: quizynox at gmail.com (quizynox)
Date: Wed, 14 Aug 2024 17:35:42 +0400
Subject: RichTextArea: API Review
In-Reply-To: <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
Message-ID: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com>

Hello,

> As also mentioned in the proposal, there are already 3rd party RTAs - 
> RichTextFX and Gluon's. Does the proposed RTA offer more than these 
> (besides the ease of use by being in JavaFX)? Do the building blocks 
> of these offer advantages that the proposed building blocks don't? An 
> abstract test that can be done is to see if these controls can be 
> "retrofitted" with the proposed new building blocks (no need to 
> actually rewrite the code). If not, it could hint to an 
> incompatibility or a limit of the proposal that makes it less appealing.

- Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for 
commercial projects (even internal non-profit projects). It can't be an 
alternative, because of this alone.
- RichTextFX depends on several long-unmaintained libraries, namely 
ReactFX. There is nothing that can be done from the OpenJFX side, as it 
would require rewriting RichTextFX from scratch.

I don't think anyone expects OpenJFX to provide something as complex as 
CodeMirror. However, having a basic rich text control with reasonable 
extension points would already be a significant improvement.

On 14/08/2024 16.03, Nir Lisker wrote:
> My questions are similar to the ones in the previous?discussion,?but 
> now I can be more specific.
>
> I see a list of "building blocks" in 
> https://bugs.openjdk.org/browse/JDK-8300569, which I like. 
> Specifically, two types of building blocks additions are important as 
> I see it: rich text-specific ones like document models and a way to 
> add decorations/colors etc., and the split of controls in general into 
> skin/input/behavior (on which there has been a long discussion). My 
> questions are:
>
> 1. If these are provided to the user, how difficult is it for them to 
> compose a RTA? JavaFX doesn't provide some somewhat-common controls 
> that you see in various other libraries with the reasoning that the 
> library should give the user the ability to create their own controls 
> (which is not so easy right now). Is RTA an exception,?like 
> ColorPicker and DatePicker?
> 2. Can these building blocks be used to enhance existing controls? For 
> example, to help with TextArea's performance with long texts, or allow 
> rich text-like features in other controls, like the squiggly red line 
> under the text in a TextField?
> 3. As also mentioned in the proposal, there are already 3rd party RTAs 
> - RichTextFX and Gluon's. Does the proposed RTA offer more than these 
> (besides the ease of use by being in JavaFX)? Do the building blocks 
> of these offer advantages that the proposed building blocks don't? An 
> abstract test that can be done is to see if these controls can be 
> "retrofitted" with the proposed new building blocks (no need to 
> actually rewrite the code). If not, it could hint to an 
> incompatibility or a limit of the proposal that makes it less appealing.
>
> Thanks,
> Nir
>
>
> On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev 
> <andy.goryachev at oracle.com> wrote:
>
>     Dear fellow developers:
>
>     Thank you for the early feedback on the RichTextArea proposal [0].
>
>     We are moving to the next phase by submitting the public pull
>     request [1].The main goal is to include the new control in an
>     incubating module [8], hopefully in jfx24, as a means of putting
>     non-final API in the hands of developers while the API and
>     implementation progress towards either finalization or removal in
>     a future release.
>
>     For your convenience, two test applications are provided -
>     *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the
>     new controls with a number of different models.In addition to
>     these two testers, please check out a simple standalone rich text
>     editor application, *RichEditorDemoApp*,
>
>     We would encourage anyone - the javafx developers, and especially
>     the application developers, to take a look at the public API
>     [3].It's probably less important at this stage to do a deep code
>     review of the implementation, but we would certainly appreciate
>     and welcome your code review comments.
>
>     Thank you in advance,
>
>     -andy
>
>     [0] Proposal:
>     https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>
>     [1] Pull request: https://github.com/openjdk/jfx/pull/1524
>
>     [2] Discussion points:
>     https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>
>     [3] API specification (javadoc):
>     https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
>     [4] CSS Reference:
>     https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>
>     [5] Behavior doc:
>     https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>
>     [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>     <https://bugs.openjdk.org/browse/JDK-8301121>
>
>     [7] Previous (now obsolete) draft pull request:
>     https://github.com/openjdk/jfx/pull/1374
>
>     [8] Incubator module JEP:
>     https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/d649ea39/attachment-0001.htm>

From nlisker at gmail.com  Wed Aug 14 14:45:16 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 14 Aug 2024 17:45:16 +0300
Subject: RichTextArea: API Review
In-Reply-To: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
 <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com>
Message-ID: <CA+0ynh8XRdcTmGno_-5P0xA0LFDXJb1PDuS2GR-KrKb8m_CydQ@mail.gmail.com>

>
> - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for
> commercial projects
>

Didn't know. That's a good point.


> - RichTextFX depends on several long-unmaintained libraries, namely
> ReactFX.
>

ReactFX is mostly finished. I have been using it for years, there are only
a few bugs there that I have hit. Some of the features there were even
imported to JavaFX. Otherwise, I don't know about the 3rd party libraries
situation there.

having a basic rich text control with reasonable extension points would
> already be a significant improvement.
>

Having a lot of things in JavaFX will be a significant improvement. The
question we're discussing is, is this worth the time compared to other
things that could have a bigger impact. The developer resources are very
limited. As someone who doesn't need this level of rich text support, I
would personally like to see time invested elsewhere, but as a maintainer I
acknowledge that others do want this, so I don't mind supporting it. Tray
icon support is one of the most requested features (which I also don't
require personally), maybe that's a better time investment, I don't know.

On Wed, Aug 14, 2024 at 4:35?PM quizynox <quizynox at gmail.com> wrote:

> Hello,
>
> As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
> - Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for
> commercial projects (even internal non-profit projects). It can't be an
> alternative, because of this alone.
> - RichTextFX depends on several long-unmaintained libraries, namely
> ReactFX. There is nothing that can be done from the OpenJFX side, as it
> would require rewriting RichTextFX from scratch.
>
> I don't think anyone expects OpenJFX to provide something as complex as
> CodeMirror. However, having a basic rich text control with reasonable
> extension points would already be a significant improvement.
> On 14/08/2024 16.03, Nir Lisker wrote:
>
> My questions are similar to the ones in the previous discussion, but now I
> can be more specific.
>
> I see a list of "building blocks" in
> https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically,
> two types of building blocks additions are important as I see it: rich
> text-specific ones like document models and a way to add decorations/colors
> etc., and the split of controls in general into skin/input/behavior (on
> which there has been a long discussion). My questions are:
>
> 1. If these are provided to the user, how difficult is it for them to
> compose a RTA? JavaFX doesn't provide some somewhat-common controls that
> you see in various other libraries with the reasoning that the library
> should give the user the ability to create their own controls (which is not
> so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
> 2. Can these building blocks be used to enhance existing controls? For
> example, to help with TextArea's performance with long texts, or allow rich
> text-like features in other controls, like the squiggly red line under the
> text in a TextField?
> 3. As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
> Thanks,
> Nir
>
>
> On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
>> Dear fellow developers:
>>
>>
>>
>> Thank you for the early feedback on the RichTextArea proposal [0].
>>
>>
>>
>> We are moving to the next phase by submitting the public pull request [1].
>> The main goal is to include the new control in an incubating module [8],
>> hopefully in jfx24, as a means of putting non-final API in the hands of
>> developers while the API and implementation progress towards either
>> finalization or removal in a future release.
>>
>>
>>
>> For your convenience, two test applications are provided -
>> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new
>> controls with a number of different models.  In addition to these two
>> testers, please check out a simple standalone rich text editor application,
>> *RichEditorDemoApp*,
>>
>>
>>
>> We would encourage anyone - the javafx developers, and especially the
>> application developers, to take a look at the public API [3].  It's
>> probably less important at this stage to do a deep code review of the
>> implementation, but we would certainly appreciate and welcome your code
>> review comments.
>>
>>
>>
>> Thank you in advance,
>>
>> -andy
>>
>>
>>
>>
>>
>> [0] Proposal:
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>>
>> [1] Pull request: https://github.com/openjdk/jfx/pull/1524
>>
>> [2] Discussion points:
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>>
>> [3] API specification (javadoc):
>> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>>
>> [4] CSS Reference:
>> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>>
>> [5] Behavior doc:
>> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>>
>> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>>
>> [7] Previous (now obsolete) draft pull request:
>> https://github.com/openjdk/jfx/pull/1374
>>
>> [8] Incubator module JEP:
>> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/547c96f8/attachment.htm>

From rlichten at openjdk.org  Wed Aug 14 14:47:01 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Wed, 14 Aug 2024 14:47:01 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <vllhPDbc7cQ5TVT0QIlMMmPxrX2oAzLJD1PlZdX_Cuo=.41c95533-d025-4d1f-b17a-bb40f5e95489@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SyntaxDecorator.java line 37:

> 35:     /**
> 36:      * Creates a {@link RichParagraph} from the paragraph plain text.
> 37:      * The text string is guaranteed to contain neither newline nor carriage return symbols.

Comment seems unclear to me. Which text string ? There is no String parameter here, only a CodeTextModel with a paragraph index...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717071557

From hmeda at openjdk.org  Wed Aug 14 14:50:55 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 14 Aug 2024 14:50:55 GMT
Subject: Integrated: 8336941 : Update libxslt to 1.1.42
In-Reply-To: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
References: <JjH5YY_ZXBFZlS9cjugAOXbt66g3z3g1-ckkbRa8R-c=.7afc650c-35b0-48a5-b823-2a14920c481b@github.com>
Message-ID: <jHpSGQHsiQaprdN9ACbFLtn2rsz852yzEmzVFy4qON8=.b58cb90b-4729-40a4-8598-9c116855e547@github.com>

On Fri, 2 Aug 2024 06:36:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated libxslt to v1.1.42. Verified build on all platforms. No issue seen

This pull request has now been integrated.

Changeset: dc8f607e
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/dc8f607e4ce95e348bb812a1c942e4321c00f0f8
Stats:     478 lines in 19 files changed: 111 ins; 316 del; 51 mod

8336941: Update libxslt to 1.1.42

Reviewed-by: kcr, jbhaskar

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

PR: https://git.openjdk.org/jfx/pull/1527

From rlichten at openjdk.org  Wed Aug 14 14:51:56 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Wed, 14 Aug 2024 14:51:56 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <aUHFtj0SLs2gohTkGccvE-9bfko9Ov1TFzr9qFZN0KA=.324359d4-1458-4cf1-93fe-9a523dadaedd@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 198:

> 196:      */
> 197:     public static class InMemoryContent implements Content {
> 198:         private final ArrayList<String> paragraphs = new ArrayList<>();

Since paragraphs may be inserted anywhere, I would guess that using a LinkedList should be more efficient here. Otherwise, when adding a line break somewhere in the middle of a long text, a lot of array members must be copied.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717082870

From rlichten at openjdk.org  Wed Aug 14 14:57:54 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Wed, 14 Aug 2024 14:57:54 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com>

On Tue, 30 Jul 2024 21:01:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

tests/manual/RichTextAreaDemo/src/com/oracle/demo/richtext/codearea/DemoSyntaxDecorator.java line 54:

> 52: 
> 53:     @Override
> 54:     public RichParagraph createRichParagraph(CodeTextModel model, int index) {

When implementing "real" syntax highlighting, the style of a paragraph will depend on the style of it's predecessors (e.g. multiline strings or multiline comments)...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717093140

From r.lichtenberger at gmail.com  Wed Aug 14 14:59:04 2024
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Wed, 14 Aug 2024 16:59:04 +0200
Subject: RichTextArea: API Review
In-Reply-To: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <a4c58c77-645e-40e3-862d-06b20f77d4a1@gmail.com>


Am 02.08.24 um 21:41 schrieb Andy Goryachev:
>
> Dear fellow developers:
>
> Thank you for the early feedback on the RichTextArea proposal [0].
>
> We are moving to the next phase by submitting the public pull request 
> [1].The main goal is to include the new control in an incubating 
> module [8], hopefully in jfx24, as a means of putting non-final API in 
> the hands of developers while the API and implementation progress 
> towards either finalization or removal in a future release.
>
> For your convenience, two test applications are provided - 
> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new 
> controls with a number of different models.In addition to these two 
> testers, please check out a simple standalone rich text editor 
> application, *RichEditorDemoApp*,
>
> We would encourage anyone - the javafx developers, and especially the 
> application developers, to take a look at the public API [3].It's 
> probably less important at this stage to do a deep code review of the 
> implementation, but we would certainly appreciate and welcome your 
> code review comments.
>
Just taken a very cursory look over the pull request (leaving a few 
thoughts) and I like the API very much.

I would indeed try to get rid of RichTextFX in our application, if RTA 
becomes available.

Thanks for the effort,

Robert

> Thank you in advance,
>
> -andy
>
> [0] Proposal: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>
> [1] Pull request: https://github.com/openjdk/jfx/pull/1524
>
> [2] Discussion points: 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>
> [3] API specification (javadoc): 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [4] CSS Reference: 
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>
> [5] Behavior doc: 
> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>
> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 
> <https://bugs.openjdk.org/browse/JDK-8301121>
>
> [7] Previous (now obsolete) draft pull request: 
> https://github.com/openjdk/jfx/pull/1374
>
> [8] Incubator module JEP: 
> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/fef4cdf6/attachment-0001.htm>

From kcr at openjdk.org  Wed Aug 14 15:02:58 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 15:02:58 GMT
Subject: Integrated: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS
 is not set
In-Reply-To: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
References: <Y1VSuGpVAgyfJl5IFruB460Z9RxzfWs_me5BemU6MBw=.b4560d92-abc7-4375-94e9-49db88b706b3@github.com>
Message-ID: <duQ7NBleKImVgFbdW3TY3AqS-CUgU26ExRnyKLwrCnA=.36e470bb-d9e9-4608-8d7d-f11dc3b54c4a@github.com>

On Mon, 12 Aug 2024 14:21:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> 1. Added logic to look in the standard locations for Visual Studio 2022, with a fallback to 2019 and then 2017 if 2022 is not found. It will look in the following locations:
> 
> C:("Program Files"|"Program Files (x86)")\Microsoft Visual Studio(2022|2019|2017)\
>      (Enterprise|Professional|Community)\VC\Auxiliary\Build
> 
> 2. Use `VSCOMNTOOLS` as the primary way for a developer to specify a custom location for Visual Studio, with `VS150COMNTOOLS` as a legacy fallback (a warning is printed if `VS150COMNTOOLS` is set). If a developer installs Visual Studio in the default location, there will be no need to set this any more.
> 3. Removed support for older compilers (VS2010 and VS2013 in particular), since they will no longer work anyway. We were still using the 32-bit version of the script in many cases, which is unnecessary and no longer makes sense, so as part of this cleanup, I now consistently use `vcvars64.bat` to set up the environment.
> 4. Modified the GitHub actions build to no longer specify `VS150COMNTOOLS`, since it will now find it automatically.
> 5. Removed the following unused variables:
> 
> DEVENVCMD
> DXSDK_DIR
> VS_VER
> 
> 6. Changed most of the defaults in `win.gradle` to the empty string. The defaults were a misguided attempt to set values to something in case the Visual Studio installation cannot be found. By not having defaults, it will be more obvious if something goes wrong (and will fail fast).
> 7. If the Visual Studio Installation cannot be found, it will print a sensible error message and retry the next time the build is run (making it less likely that a manual `rm -rf build` is needed).
> 8. Fixed a bug where the Microsoft redist files were not being located and copied into the build dir (build/sdk/bin).
> 
> 
> I left some debug print statements in, and will remove them in a follow-on commit.
> 
> I have tested this with a local installation of Visual Studio 2022 Community and, via GitHub Actions, an installation of Visual Studio 2022 Enterprise. On my local system, I built with and without Media and WebKit.

This pull request has now been integrated.

Changeset: a8f78505
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a8f7850503043f616703fdfc8d0a26a00f47b7c8
Stats:     165 lines in 5 files changed: 32 ins; 79 del; 54 mod

8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set

Reviewed-by: nlisker, mhanl, lkostyra, prr

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

PR: https://git.openjdk.org/jfx/pull/1534

From mfox at openjdk.org  Wed Aug 14 15:13:57 2024
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 14 Aug 2024 15:13:57 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
 <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>
Message-ID: <sCs5MeNyqu3C9Wa_b8GeO73dLKFD6EomvXT9cQGIcpI=.75ca3cd9-4d30-4c24-bcfe-0146eb1e824d@github.com>

On Tue, 13 Aug 2024 21:40:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Actually, this statement is not correct: the consumed flag will be propagated, but only if `propagateConsume` was set by the helper, which is being done in a very specific case.

If a perfectly legal, properly written dispatcher in the chain creates a new event without using `copyFor` the `propagateConsume` link will be broken and this PR will not work correctly. That's solely because this PR is trying to create a new way of communicating whether an event is consumed or not instead of using the existing mechanism.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289078999

From mfox at openjdk.org  Wed Aug 14 15:16:04 2024
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 14 Aug 2024 15:16:04 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <EHVlHnSiFzGbsxGc9eVkBsS9pCQY81d-OWZgE0LIReA=.71ee8791-21fd-424b-aa8e-77b7c4243f97@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

I will take another look, I've only been holding off since I'm not a Reviewer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2289082850

From angorya at openjdk.org  Wed Aug 14 15:18:53 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 15:18:53 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <sCs5MeNyqu3C9Wa_b8GeO73dLKFD6EomvXT9cQGIcpI=.75ca3cd9-4d30-4c24-bcfe-0146eb1e824d@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
 <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>
 <sCs5MeNyqu3C9Wa_b8GeO73dLKFD6EomvXT9cQGIcpI=.75ca3cd9-4d30-4c24-bcfe-0146eb1e824d@github.com>
Message-ID: <769vbUzj0LR-ZxOOLiv4UJs02Nuo4v0NkGJmH4w_y2k=.b3da6801-9082-44e1-997d-aad6b15e482e@github.com>

On Wed, 14 Aug 2024 15:11:26 GMT, Martin Fox <mfox at openjdk.org> wrote:

> If a perfectly legal, properly written dispatcher in the chain creates a new event

As I mentioned earlier, this is the problem of the dispatcher.  Anyone can fire an event.

But this PR does not link the two events generally, but addresses one specific scenario.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289088913

From kcr at openjdk.org  Wed Aug 14 15:20:04 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 15:20:04 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <Zi2_ZnBwOqESBVvU0k7qhy_Y47Yw4B5p3u0WsGutTvU=.70b5b479-470b-4f62-b15c-a33b89fde7d3@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

I will also review it, focusing on the native code changes / additions. I don't have a good way to test it, so will leave that to others.

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2289091299

From mstrauss at openjdk.org  Wed Aug 14 16:29:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 14 Aug 2024 16:29:56 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
Message-ID: <4V03cMbn925E07tz925io3QkQFcXOK50dW7DG02aIrs=.6b2f67ff-395e-4295-b9ca-31a6fae96268@github.com>

On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
>> 
>> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
>> 
>> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - avoid csr
>  - Merge remote-tracking branch 'origin/master' into ag.consume
>  - only if consumed
>  - only when consumed
>  - propagate
>  - cleanup
>  - simpler
>  - event helper
>  - copy for test
>  - propagate consume action

> /csr unneeded

You will need a CSR, because you propose to make the public `consumed` field private (and change its type).

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289245880

From mstrauss at openjdk.org  Wed Aug 14 16:31:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 14 Aug 2024 16:31:56 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v4]
In-Reply-To: <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
Message-ID: <yXK8gdHNeNOFKpD3as7-zTx22koqz62mG18kkKyJQOw=.f7da3fb6-a9b7-4202-a13b-9c8a00fe6488@github.com>

On Sat, 10 Aug 2024 16:21:11 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> This PR is a fix for another IOOBE that I discovered while working on #1476.
>> 
>> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
>> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
>> 
>> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
>> 
>> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
>> 
>> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
>> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.
>
> Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - test "negative" style class in BarChartTest tests
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>  - fix "negative" style class when series is changed
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>    
>    # Conflicts:
>    #	modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java
>  - BarChart: Fix adding non-empty series
>  - BarChart: Add styleClass "negative" for added data

Marked as reviewed by mstrauss (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1488#pullrequestreview-2238671326

From mfox at openjdk.org  Wed Aug 14 16:57:58 2024
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 14 Aug 2024 16:57:58 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <769vbUzj0LR-ZxOOLiv4UJs02Nuo4v0NkGJmH4w_y2k=.b3da6801-9082-44e1-997d-aad6b15e482e@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
 <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>
 <sCs5MeNyqu3C9Wa_b8GeO73dLKFD6EomvXT9cQGIcpI=.75ca3cd9-4d30-4c24-bcfe-0146eb1e824d@github.com>
 <769vbUzj0LR-ZxOOLiv4UJs02Nuo4v0NkGJmH4w_y2k=.b3da6801-9082-44e1-997d-aad6b15e482e@github.com>
Message-ID: <fYfblSmBCMhjWXRuBKF47LwXQYGKRBbSxem6eDW8Fi8=.32649038-532f-41dc-b932-92ea786fde55@github.com>

On Wed, 14 Aug 2024 15:15:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> But this PR does not link the two events generally, but addresses one specific scenario.

The event is being fired which means it may pass through any number of dispatchers some of which may be written by outside developers.

> As I mentioned earlier, this is the problem of the dispatcher. Anyone can fire an event.

There are rules for how a dispatcher works. A dispatcher that follows those rules can still break this PR. This suggests that the problem is with the PR and not the dispatcher. And there is a way to write this PR that works with the existing rules governing dispatchers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289315066

From angorya at openjdk.org  Wed Aug 14 17:14:59 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 17:14:59 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
Message-ID: <3p5wnRU1y67iu3utIa-5Ps9Svb86twv69HGAMpXWIgQ=.10c5b3ee-2c75-42cf-b40f-5bc7d46bf8da@github.com>

On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`.
>> 
>> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate.
>> 
>> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary.
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - avoid csr
>  - Merge remote-tracking branch 'origin/master' into ag.consume
>  - only if consumed
>  - only when consumed
>  - propagate
>  - cleanup
>  - simpler
>  - event helper
>  - copy for test
>  - propagate consume action

you are right, csr **is** needed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289357113

From andy.goryachev at oracle.com  Wed Aug 14 17:20:21 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 14 Aug 2024 17:20:21 +0000
Subject: Proposing new APIs: additional SplitMenuButton constructors
Message-ID: <BL3PR10MB6185D120357F914AE1A0EBF7E5872@BL3PR10MB6185.namprd10.prod.outlook.com>

Dear fellow developers:

I?d like to propose new constructors for SplitMenuButton to match MenuButton constructors [0], [1], [2].  Any objections?

[0] JBS: https://bugs.openjdk.org/browse/JDK-8338016

[1] CSR: https://bugs.openjdk.org/browse/JDK-8338337

[2] PR: https://github.com/openjdk/jfx/pull/1535

Cheers,
-andy




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/bba25025/attachment.htm>

From angorya at openjdk.org  Wed Aug 14 17:25:06 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 17:25:06 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
Message-ID: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>

Adding SplitMenuButton constructors matching MenuButton:

- public SplitMenuButton(String text)
- public SplitMenuButton(String text, Node graphic)
- public SplitMenuButton(String text, Node graphic, MenuItem... items)

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

Commit messages:
 - javadoc
 - 8338016: SplitMenuButton constructors should match MenuButton

Changes: https://git.openjdk.org/jfx/pull/1535/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1535&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338016
  Stats: 47 lines in 1 file changed: 45 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1535.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1535/head:pull/1535

PR: https://git.openjdk.org/jfx/pull/1535

From mstrauss at openjdk.org  Wed Aug 14 17:25:06 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 14 Aug 2024 17:25:06 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
In-Reply-To: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
Message-ID: <nkL85o2I852WsxrqgeLIv8-3nqc77ErtLwZwcJqITGE=.eca36a53-de7c-43e4-9761-971a88ca5f83@github.com>

On Tue, 13 Aug 2024 22:27:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding SplitMenuButton constructors matching MenuButton:
> 
> - public SplitMenuButton(String text)
> - public SplitMenuButton(String text, Node graphic)
> - public SplitMenuButton(String text, Node graphic, MenuItem... items)

modules/javafx.controls/src/main/java/javafx/scene/control/SplitMenuButton.java line 123:

> 121:      * @param text the text to display on the menu button
> 122:      * @param graphic the graphic to display on the menu button
> 123:      * @param items The items to display in the popup menu.

Minor: description should start with a small letter and not end with a dot.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1717226223

From angorya at openjdk.org  Wed Aug 14 17:25:06 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 17:25:06 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
In-Reply-To: <nkL85o2I852WsxrqgeLIv8-3nqc77ErtLwZwcJqITGE=.eca36a53-de7c-43e4-9761-971a88ca5f83@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <nkL85o2I852WsxrqgeLIv8-3nqc77ErtLwZwcJqITGE=.eca36a53-de7c-43e4-9761-971a88ca5f83@github.com>
Message-ID: <uzYC-8V89QokDVqgcHHVTE-E07Th1yN-vyObAdJaIzU=.cdd47708-ce43-413d-9eee-96064dd150a2@github.com>

On Wed, 14 Aug 2024 16:21:48 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adding SplitMenuButton constructors matching MenuButton:
>> 
>> - public SplitMenuButton(String text)
>> - public SplitMenuButton(String text, Node graphic)
>> - public SplitMenuButton(String text, Node graphic, MenuItem... items)
>
> modules/javafx.controls/src/main/java/javafx/scene/control/SplitMenuButton.java line 123:
> 
>> 121:      * @param text the text to display on the menu button
>> 122:      * @param graphic the graphic to display on the menu button
>> 123:      * @param items The items to display in the popup menu.
> 
> Minor: description should start with a small letter and not end with a dot.

that was lifted straight from MenuButton...  but you are right of course.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1717292365

From duke at openjdk.org  Wed Aug 14 17:40:57 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 17:40:57 GMT
Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data [v4]
In-Reply-To: <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
 <omijvGGPp_qaTXjRttCiPKck5OoVQBNRboMoaQO9QoU=.392561f0-5473-4feb-b1d2-c2ff0bc22136@github.com>
Message-ID: <lp8t2rHbOCosZZ0sFWtPF9xyLf7CNwuNaHFZA3iJZ90=.39010b1f-c5d8-4aa0-a19f-55409befddc0@github.com>

On Sat, 10 Aug 2024 16:21:11 GMT, Markus Mack <mmack at openjdk.org> wrote:

>> This PR is a fix for another IOOBE that I discovered while working on #1476.
>> 
>> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
>> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
>> 
>> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
>> 
>> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
>> 
>> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
>> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.
>
> Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - test "negative" style class in BarChartTest tests
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>  - fix "negative" style class when series is changed
>  - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series
>    
>    # Conflicts:
>    #	modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java
>  - BarChart: Fix adding non-empty series
>  - BarChart: Add styleClass "negative" for added data

@drmarmac 
Your change (at version ed5d9c2a50d02fb1eb3d974b4a81da6ca035a7ba) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2289427553

From mmack at openjdk.org  Wed Aug 14 17:54:56 2024
From: mmack at openjdk.org (Markus Mack)
Date: Wed, 14 Aug 2024 17:54:56 GMT
Subject: Integrated: 8334900: IOOBE when adding data to a Series of a BarChart
 that already contains data
In-Reply-To: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
References: <ej2UKUzhFvNAgOmvY2eLRoskMBCfbGGQ0P4fvPfeKY4=.052a86a6-2bef-463c-8f9c-f82c391a20d6@github.com>
Message-ID: <ywXd8BFfQLZPnp4v-J6C-tbY2w6TvvV6PVGJgxg1uro=.30c552ea-44d7-4b07-abec-94a4b59117a9@github.com>

On Mon, 24 Jun 2024 22:10:38 GMT, Markus Mack <mmack at openjdk.org> wrote:

> This PR is a fix for another IOOBE that I discovered while working on #1476.
> 
> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one.
> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
> 
> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
> 
> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
> 
> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed.

This pull request has now been integrated.

Changeset: 338b1f3a
Author:    Markus Mack <mmack at openjdk.org>
Committer: Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/338b1f3a1cff64f8eceb140015fec232f21234eb
Stats:     125 lines in 2 files changed: 94 ins; 28 del; 3 mod

8334900: IOOBE when adding data to a Series of a BarChart that already contains data
8334901: Style class "negative" is not always added for new BarChart data with negative value

Reviewed-by: mstrauss, angorya

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

PR: https://git.openjdk.org/jfx/pull/1488

From kcr at openjdk.org  Wed Aug 14 18:04:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 18:04:54 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed [v2]
In-Reply-To: <4V03cMbn925E07tz925io3QkQFcXOK50dW7DG02aIrs=.6b2f67ff-395e-4295-b9ca-31a6fae96268@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <fsp6VztiEMwPsDVBM8JXsuwRbTRV1DETYF_Q0EXsHg8=.9c9593ce-cadb-42ea-8d86-e32803172c6c@github.com>
 <4V03cMbn925E07tz925io3QkQFcXOK50dW7DG02aIrs=.6b2f67ff-395e-4295-b9ca-31a6fae96268@github.com>
Message-ID: <0n0mISqlNGOjD0btEddyJN6lmaLktOqYxAggpLywZiY=.86370acb-dbff-4bef-beda-76338c89688c@github.com>

On Wed, 14 Aug 2024 16:27:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> You will need a CSR, because you propose to make the public `consumed` field private (and change its type).

Thanks for pointing this out. I haven't had time to look at this PR yet, but this aspect of the change is a breaking API change, and is not something we would generally do. There would  need to be an extremely compelling reason to do this. I am unconvinced that there is.

I haven't formed an opinion on the approach itself, since I haven't read through all of the discussion. If we do end up going this route, there are behavioral aspects that need to be captured in a CSR as well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289491234

From kevin.rushforth at oracle.com  Wed Aug 14 18:06:59 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Aug 2024 11:06:59 -0700
Subject: Proposing new APIs: additional SplitMenuButton constructors
In-Reply-To: <BL3PR10MB6185D120357F914AE1A0EBF7E5872@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB6185D120357F914AE1A0EBF7E5872@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <16fe7e54-fdeb-47db-b328-fa997ac197a2@oracle.com>

This seems like a reasonable request.

-- Kevin


On 8/14/2024 10:20 AM, Andy Goryachev wrote:
>
> Dear fellow developers:
>
> I?d like to propose new constructors for SplitMenuButton to match 
> MenuButton constructors [0], [1], [2].? Any objections?
>
> [0] JBS: https://bugs.openjdk.org/browse/JDK-8338016
>
> [1] CSR: https://bugs.openjdk.org/browse/JDK-8338337 
> <https://bugs.openjdk.org/browse/JDK-8338337>
>
> [2] PR: https://github.com/openjdk/jfx/pull/1535 
> <https://github.com/openjdk/jfx/pull/1535>
>
> Cheers,
>
> -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/b02ec859/attachment.htm>

From andy.goryachev at oracle.com  Wed Aug 14 18:09:24 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 14 Aug 2024 18:09:24 +0000
Subject: [External] : Re: RichTextArea: API Review
In-Reply-To: <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
Message-ID: <BL3PR10MB618576B9B3361AB13F2BCBF1E5872@BL3PR10MB6185.namprd10.prod.outlook.com>

Dear Nir, everyone:

Thank you for asking these good questions!


1. If these are provided to the user, how difficult is it for them to compose a RTA? JavaFX doesn't provide some somewhat-common controls that you see in various other libraries with the reasoning that the library should give the user the ability to create their own controls (which is not so easy right now). Is RTA an exception, like ColorPicker and DatePicker?

To create a full equivalent of the RTA as implemented in https://bugs.openjdk.org/browse/JDK-8301121 - difficult.

For starters, there are several missing pieces ? some do not have public API, and some are just missing.  No public API: focus traversal APIs, text layout information, input map.  Missing ? tab stop policy.  My intent is to make all of these available as public API, as well as fix some of the related bugs.  RTA is a complex control, and in that sense it goes beyond the Date/ColorPicker level of complexity, but the general idea is the same (as Robert explained earlier): to give the developers a fully functional control that can be used out of the box, or can serve as a basis for more complex things.


2. Can these building blocks be used to enhance existing controls? For example, to help with TextArea's performance with long texts, or allow rich text-like features in other controls, like the squiggly red line under the text in a TextField?

Some of the builing blocks are already available: for example, rich text can be rendered by using TextFlow set as a graphic on a Label.

Adding a squiggly line or similar decoration to the TextArea might also be possible.

Support for long texts in TextArea... I must say that pretty much nothing in the TextArea is done with long texts in mind.  Redesigning of TextArea for long texts or performance is rather unlikely for obvious reasons (one of which is textProperty).  One have to resort to paragraph-based text model and virtualization to do that, and even then the proposed RichTextArea will struggle with long paragraphs.


3. As also mentioned in the proposal, there are already 3rd party RTAs - RichTextFX and Gluon's. Does the proposed RTA offer more than these (besides the ease of use by being in JavaFX)? Do the building blocks of these offer advantages that the proposed building blocks don't? An abstract test that can be done is to see if these controls can be "retrofitted" with the proposed new building blocks (no need to actually rewrite the code). If not, it could hint to an incompatibility or a limit of the proposal that makes it less appealing.

Robert already addressed this in his earlier response (thank you, Robert!), so let me just reiterate one point: the proposed RTA is simpler than RichTextFX offering.  Simpler to use, and simpler in terms of supported features ? does not offer tables, for instance.  There are still use cases which RTA won?t be able to address, and for which an external library is still needed.

Thanks again for good questions.  Did I provide good answers?

-andy




From: Nir Lisker <nlisker at gmail.com>
Date: Wednesday, August 14, 2024 at 05:04
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: RichTextArea: API Review
My questions are similar to the ones in the previous discussion, but now I can be more specific.

I see a list of "building blocks" in https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically, two types of building blocks additions are important as I see it: rich text-specific ones like document models and a way to add decorations/colors etc., and the split of controls in general into skin/input/behavior (on which there has been a long discussion). My questions are:

1. If these are provided to the user, how difficult is it for them to compose a RTA? JavaFX doesn't provide some somewhat-common controls that you see in various other libraries with the reasoning that the library should give the user the ability to create their own controls (which is not so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
2. Can these building blocks be used to enhance existing controls? For example, to help with TextArea's performance with long texts, or allow rich text-like features in other controls, like the squiggly red line under the text in a TextField?
3. As also mentioned in the proposal, there are already 3rd party RTAs - RichTextFX and Gluon's. Does the proposed RTA offer more than these (besides the ease of use by being in JavaFX)? Do the building blocks of these offer advantages that the proposed building blocks don't? An abstract test that can be done is to see if these controls can be "retrofitted" with the proposed new building blocks (no need to actually rewrite the code). If not, it could hint to an incompatibility or a limit of the proposal that makes it less appealing.

Thanks,
Nir


On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:

Dear fellow developers:



Thank you for the early feedback on the RichTextArea proposal [0].



We are moving to the next phase by submitting the public pull request [1].  The main goal is to include the new control in an incubating module [8], hopefully in jfx24, as a means of putting non-final API in the hands of developers while the API and implementation progress towards either finalization or removal in a future release.



For your convenience, two test applications are provided - RichTextAreaDemoApp and CodeAreaDemoApp which demonstrate the new controls with a number of different models.  In addition to these two testers, please check out a simple standalone rich text editor application, RichEditorDemoApp,



We would encourage anyone - the javafx developers, and especially the application developers, to take a look at the public API [3].  It's probably less important at this stage to do a deep code review of the implementation, but we would certainly appreciate and welcome your code review comments.



Thank you in advance,

-andy





[0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md<https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9t4274lJ$>

[1] Pull request: https://github.com/openjdk/jfx/pull/1524<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1524__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9gf9BYIK$>

[2] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md<https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9nUSujTl$>

[3] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc

[4] CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html

[5] Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md<https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9pq__cpG$>

[6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[7] Previous (now obsolete) draft pull request: https://github.com/openjdk/jfx/pull/1374<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1374__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9v4KgU9J$>

[8] Incubator module JEP: https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md<https://urldefense.com/v3/__https:/github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9pjE-pZ5$>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/60116fb6/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Aug 14 18:19:24 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 14 Aug 2024 18:19:24 +0000
Subject: RichTextArea: API Review
In-Reply-To: <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
 <64c3167b-1a03-42b0-bab4-7b607f607206@gmail.com>
Message-ID: <BL3PR10MB6185C178A6CAE19AC2F6E6E9E5872@BL3PR10MB6185.namprd10.prod.outlook.com>

Thank you for offering your perspective!

Just wanted to add that one of the design goals of CodeArea is to enable the app or third party devs to implement the functionality found in CodeMirror or a similar code editor.

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of quizynox <quizynox at gmail.com>
Date: Wednesday, August 14, 2024 at 06:35
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RichTextArea: API Review

Hello,
As also mentioned in the proposal, there are already 3rd party RTAs - RichTextFX and Gluon's. Does the proposed RTA offer more than these (besides the ease of use by being in JavaFX)? Do the building blocks of these offer advantages that the proposed building blocks don't? An abstract test that can be done is to see if these controls can be "retrofitted" with the proposed new building blocks (no need to actually rewrite the code). If not, it could hint to an incompatibility or a limit of the proposal that makes it less appealing.

- Gluon's RTA is dual-licensed, so unlike OpenJFX, it is not free for commercial projects (even internal non-profit projects). It can't be an alternative, because of this alone.
- RichTextFX depends on several long-unmaintained libraries, namely ReactFX. There is nothing that can be done from the OpenJFX side, as it would require rewriting RichTextFX from scratch.

I don't think anyone expects OpenJFX to provide something as complex as CodeMirror. However, having a basic rich text control with reasonable extension points would already be a significant improvement.
On 14/08/2024 16.03, Nir Lisker wrote:
My questions are similar to the ones in the previous discussion, but now I can be more specific.

I see a list of "building blocks" in https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically, two types of building blocks additions are important as I see it: rich text-specific ones like document models and a way to add decorations/colors etc., and the split of controls in general into skin/input/behavior (on which there has been a long discussion). My questions are:

1. If these are provided to the user, how difficult is it for them to compose a RTA? JavaFX doesn't provide some somewhat-common controls that you see in various other libraries with the reasoning that the library should give the user the ability to create their own controls (which is not so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
2. Can these building blocks be used to enhance existing controls? For example, to help with TextArea's performance with long texts, or allow rich text-like features in other controls, like the squiggly red line under the text in a TextField?
3. As also mentioned in the proposal, there are already 3rd party RTAs - RichTextFX and Gluon's. Does the proposed RTA offer more than these (besides the ease of use by being in JavaFX)? Do the building blocks of these offer advantages that the proposed building blocks don't? An abstract test that can be done is to see if these controls can be "retrofitted" with the proposed new building blocks (no need to actually rewrite the code). If not, it could hint to an incompatibility or a limit of the proposal that makes it less appealing.

Thanks,
Nir


On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:

Dear fellow developers:



Thank you for the early feedback on the RichTextArea proposal [0].



We are moving to the next phase by submitting the public pull request [1].  The main goal is to include the new control in an incubating module [8], hopefully in jfx24, as a means of putting non-final API in the hands of developers while the API and implementation progress towards either finalization or removal in a future release.



For your convenience, two test applications are provided - RichTextAreaDemoApp and CodeAreaDemoApp which demonstrate the new controls with a number of different models.  In addition to these two testers, please check out a simple standalone rich text editor application, RichEditorDemoApp,



We would encourage anyone - the javafx developers, and especially the application developers, to take a look at the public API [3].  It's probably less important at this stage to do a deep code review of the implementation, but we would certainly appreciate and welcome your code review comments.



Thank you in advance,

-andy





[0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md

[1] Pull request: https://github.com/openjdk/jfx/pull/1524

[2] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md

[3] API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc

[4] CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html

[5] Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md

[6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[7] Previous (now obsolete) draft pull request: https://github.com/openjdk/jfx/pull/1374

[8] Incubator module JEP: https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240814/f2c9a7ba/attachment-0001.htm>

From angorya at openjdk.org  Wed Aug 14 18:29:55 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 18:29:55 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <vllhPDbc7cQ5TVT0QIlMMmPxrX2oAzLJD1PlZdX_Cuo=.41c95533-d025-4d1f-b17a-bb40f5e95489@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vllhPDbc7cQ5TVT0QIlMMmPxrX2oAzLJD1PlZdX_Cuo=.41c95533-d025-4d1f-b17a-bb40f5e95489@github.com>
Message-ID: <zqRh1Wpi0bTAVrcar04jPPE16Hr31pnQvLMIeFE-RQo=.ee9bf9a0-11d0-4f9e-af96-67798864c163@github.com>

On Wed, 14 Aug 2024 14:43:54 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SyntaxDecorator.java line 37:
> 
>> 35:     /**
>> 36:      * Creates a {@link RichParagraph} from the paragraph plain text.
>> 37:      * The text string is guaranteed to contain neither newline nor carriage return symbols.
> 
> Comment seems unclear to me. Which text string ? There is no String parameter here, only a CodeTextModel with a paragraph index...

Hmmm.  How about

Creates a {@link RichParagraph} from the paragraph plain text **string**.
The text string is guaranteed to contain neither newline nor carriage return symbols.

?

> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 198:
> 
>> 196:      */
>> 197:     public static class InMemoryContent implements Content {
>> 198:         private final ArrayList<String> paragraphs = new ArrayList<>();
> 
> Since paragraphs may be inserted anywhere, I would guess that using a LinkedList should be more efficient here. Otherwise, when adding a line break somewhere in the middle of a long text, a lot of array members must be copied.

You are right, but this is just a default implementation.  you can still implement your own `BasicTextModel.Content` and pass it to the constructor.

Do you want to see an in-memory implementation optimized for large number of paragraphs or should it better be left up to the app developers?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717383475
PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717382025

From angorya at openjdk.org  Wed Aug 14 18:35:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 18:35:57 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator)
In-Reply-To: <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com>
Message-ID: <Bvzu3evzfdJqZ-GK33MNnSgO6e_yfNAqT6ldAVg8Y8g=.75dc747e-0217-41ff-839d-244534188a54@github.com>

On Wed, 14 Aug 2024 14:54:57 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> tests/manual/RichTextAreaDemo/src/com/oracle/demo/richtext/codearea/DemoSyntaxDecorator.java line 54:
> 
>> 52: 
>> 53:     @Override
>> 54:     public RichParagraph createRichParagraph(CodeTextModel model, int index) {
> 
> When implementing "real" syntax highlighting, the style of a paragraph will depend on the style of it's predecessors (e.g. multiline strings or multiline comments)...

Correct, this is just a demo.

The information passed to the **SyntaxDecorator** interface should be sufficient to support any "real" syntax, at least I hope it is.  We are passing the model to each method, so it can re/construct the syntax or cache it as needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1717389569

From angorya at openjdk.org  Wed Aug 14 20:40:52 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 20:40:52 GMT
Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <fYfblSmBCMhjWXRuBKF47LwXQYGKRBbSxem6eDW8Fi8=.32649038-532f-41dc-b932-92ea786fde55@github.com>
References: <ODsq8EIF6T_ocG9PUZCht1g3NQ6BZYUV-jcofD1_ILM=.68dbfd23-9cb2-499a-a301-721e0980e816@github.com>
 <XWjSogc5WkFgoD3_HqDSaMNToOjhQNt9EitrzZgZaw4=.6be47ec3-6f41-4b4b-a3c8-ba81bdc546bf@github.com>
 <tZtHeizZRDgk1S4QxPm45nUSfXEvB5ACAH2NVk2-bhc=.b31d752d-9eb6-4de3-ab02-050fdb3d972d@github.com>
 <sCs5MeNyqu3C9Wa_b8GeO73dLKFD6EomvXT9cQGIcpI=.75ca3cd9-4d30-4c24-bcfe-0146eb1e824d@github.com>
 <769vbUzj0LR-ZxOOLiv4UJs02Nuo4v0NkGJmH4w_y2k=.b3da6801-9082-44e1-997d-aad6b15e482e@github.com>
 <fYfblSmBCMhjWXRuBKF47LwXQYGKRBbSxem6eDW8Fi8=.32649038-532f-41dc-b932-92ea786fde55@github.com>
Message-ID: <Wse-K4x2MKo8j1MRy1Jihxnizu0vVy4xVS25SUdtqs0=.56658a3a-dc99-4f36-994b-67b8e5a64c8a@github.com>

On Wed, 14 Aug 2024 16:55:25 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There are rules for how a dispatcher works. A dispatcher that follows those rules can still break this PR.

Here are the rules (in EventDispatcher interface):


    /**
     * Dispatches the specified event by this {@code EventDispatcher}. Does
     * any required event processing. Both the event and its further path can
     * be modified in this method. If the event is not handled / consumed during
     * the capturing phase, it should be dispatched to the rest of the chain
     * ({@code event = tail.dispatch(event);}).
     *
     * @param event the event do dispatch
     * @param tail the rest of the chain to dispatch event to
     * @return the return event or {@code null} if the event has been handled /
     *      consumed
     */


I don't see where it talks about creating new events, handling of cloned events and their `::isConsumed` in the context of EH.  The null return value, in my opinion, is only significant in the context of further event dispatching: null means no more dispatch.

If the dispatcher does something outside of the scope of event dispatching, it's the responsibility of the said dispatcher to deal with the consequences.

I don't see how this relates to the narrow scope of this PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2289832635

From nlisker at gmail.com  Wed Aug 14 22:39:13 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 15 Aug 2024 01:39:13 +0300
Subject: [External] : Re: RichTextArea: API Review
In-Reply-To: <BL3PR10MB618576B9B3361AB13F2BCBF1E5872@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB6185BB2DB2BEAA5E3970425BE5B32@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CA+0ynh-yDKgzoZJimvTMazSpHZbLxkrEojqXyHdasmVtrByksw@mail.gmail.com>
 <BL3PR10MB618576B9B3361AB13F2BCBF1E5872@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CA+0ynh9ws+JcxuXX9cNDDwAUUrv7h=JcmsKg4vZOnDHg_-oj5A@mail.gmail.com>

Yes, that clarifies a lot, thanks! I'll have a look at the API and
functionality of the demos.

On Wed, Aug 14, 2024 at 9:09?PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Dear Nir, everyone:
>
>
>
> Thank you for asking these good questions!
>
>
>
>
>
> 1. If these are provided to the user, how difficult is it for them to
> compose a RTA? JavaFX doesn't provide some somewhat-common controls that
> you see in various other libraries with the reasoning that the library
> should give the user the ability to create their own controls (which is not
> so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
>
>
>
> To create a full equivalent of the RTA as implemented in
> https://bugs.openjdk.org/browse/JDK-8301121 - difficult.
>
>
>
> For starters, there are several missing pieces ? some do not have public
> API, and some are just missing.  No public API: focus traversal APIs, text
> layout information, input map.  Missing ? tab stop policy.  My intent is to
> make all of these available as public API, as well as fix some of the
> related bugs.  RTA is a complex control, and in that sense it goes beyond
> the Date/ColorPicker level of complexity, but the general idea is the same
> (as Robert explained earlier): to give the developers a fully functional
> control that can be used out of the box, or can serve as a basis for more
> complex things.
>
>
>
>
>
> 2. Can these building blocks be used to enhance existing controls? For
> example, to help with TextArea's performance with long texts, or allow rich
> text-like features in other controls, like the squiggly red line under the
> text in a TextField?
>
>
>
> Some of the builing blocks are already available: for example, rich text
> can be rendered by using TextFlow set as a graphic on a Label.
>
>
>
> Adding a squiggly line or similar decoration to the TextArea might also be
> possible.
>
>
>
> Support for long texts in TextArea... I must say that pretty much nothing
> in the TextArea is done with long texts in mind.  Redesigning of TextArea
> for long texts or performance is rather unlikely for obvious reasons (one
> of which is textProperty).  One have to resort to paragraph-based text
> model and virtualization to do that, and even then the proposed
> RichTextArea will struggle with long paragraphs.
>
>
>
>
>
> 3. As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
>
>
> Robert already addressed this in his earlier response (thank you,
> Robert!), so let me just reiterate one point: the proposed RTA is simpler
> than RichTextFX offering.  Simpler to use, and simpler in terms of
> supported features ? does not offer tables, for instance.  There are still
> use cases which RTA won?t be able to address, and for which an external
> library is still needed.
>
>
>
> Thanks again for good questions.  Did I provide good answers?
>
>
>
> -andy
>
>
>
>
>
>
>
>
>
> *From: *Nir Lisker <nlisker at gmail.com>
> *Date: *Wednesday, August 14, 2024 at 05:04
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: RichTextArea: API Review
>
> My questions are similar to the ones in the previous discussion, but now I
> can be more specific.
>
>
>
> I see a list of "building blocks" in
> https://bugs.openjdk.org/browse/JDK-8300569, which I like. Specifically,
> two types of building blocks additions are important as I see it: rich
> text-specific ones like document models and a way to add decorations/colors
> etc., and the split of controls in general into skin/input/behavior (on
> which there has been a long discussion). My questions are:
>
>
>
> 1. If these are provided to the user, how difficult is it for them to
> compose a RTA? JavaFX doesn't provide some somewhat-common controls that
> you see in various other libraries with the reasoning that the library
> should give the user the ability to create their own controls (which is not
> so easy right now). Is RTA an exception, like ColorPicker and DatePicker?
>
> 2. Can these building blocks be used to enhance existing controls? For
> example, to help with TextArea's performance with long texts, or allow rich
> text-like features in other controls, like the squiggly red line under the
> text in a TextField?
>
> 3. As also mentioned in the proposal, there are already 3rd party RTAs -
> RichTextFX and Gluon's. Does the proposed RTA offer more than these
> (besides the ease of use by being in JavaFX)? Do the building blocks of
> these offer advantages that the proposed building blocks don't? An abstract
> test that can be done is to see if these controls can be "retrofitted" with
> the proposed new building blocks (no need to actually rewrite the code). If
> not, it could hint to an incompatibility or a limit of the proposal that
> makes it less appealing.
>
>
>
> Thanks,
>
> Nir
>
>
>
>
>
> On Fri, Aug 2, 2024 at 10:41?PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
> Dear fellow developers:
>
>
>
> Thank you for the early feedback on the RichTextArea proposal [0].
>
>
>
> We are moving to the next phase by submitting the public pull request [1].
> The main goal is to include the new control in an incubating module [8],
> hopefully in jfx24, as a means of putting non-final API in the hands of
> developers while the API and implementation progress towards either
> finalization or removal in a future release.
>
>
>
> For your convenience, two test applications are provided -
> *RichTextAreaDemoApp* and *CodeAreaDemoApp* which demonstrate the new
> controls with a number of different models.  In addition to these two
> testers, please check out a simple standalone rich text editor application,
> *RichEditorDemoApp*,
>
>
>
> We would encourage anyone - the javafx developers, and especially the
> application developers, to take a look at the public API [3].  It's
> probably less important at this stage to do a deep code review of the
> implementation, but we would certainly appreciate and welcome your code
> review comments.
>
>
>
> Thank you in advance,
>
> -andy
>
>
>
>
>
> [0] Proposal:
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> <https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9t4274lJ$>
>
> [1] Pull request: https://github.com/openjdk/jfx/pull/1524
> <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1524__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9gf9BYIK$>
>
> [2] Discussion points:
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> <https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9nUSujTl$>
>
> [3] API specification (javadoc):
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>
> [4] CSS Reference:
> https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>
> [5] Behavior doc:
> https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> <https://urldefense.com/v3/__https:/github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9pq__cpG$>
>
> [6] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>
> [7] Previous (now obsolete) draft pull request:
> https://github.com/openjdk/jfx/pull/1374
> <https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/1374__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9v4KgU9J$>
>
> [8] Incubator module JEP:
> https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md
> <https://urldefense.com/v3/__https:/github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md__;!!ACWV5N9M2RV99hQ!ObEX8HGQdm3Luimk7A9mRrJzS0gFeKC4Ys9K2gFkf9Sy_MN_X0OtuWziJDW3btm8gyihirZMlkJO9pjE-pZ5$>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240815/f573e585/attachment-0001.htm>

From angorya at openjdk.org  Wed Aug 14 23:40:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 23:40:12 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v2]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <PgyH3TU7lXKLB7EsE8ttMktQRDTtEvPwQZtHQhmrOAA=.7cd64847-8d1f-4e22-a9a5-ef29ae84c04a@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request 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. The pull request contains four additional commits since the last revision:

 - update + review comments
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - 8301121: RichTextArea Control (Incubator)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/4c472b7e..1cc77436

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=00-01

  Stats: 3765 lines in 84 files changed: 1975 ins; 1040 del; 750 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

From angorya at openjdk.org  Wed Aug 14 23:46:28 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Aug 2024 23:46:28 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v3]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <Zes-PadoPPSaYHGnBLZk1FNOd3BNtAbSN8CFkvDV1QU=.3e3fca20-b3d5-4676-820b-d816d6078586@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/1cc77436..3e55db8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=01-02

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

PR: https://git.openjdk.org/jfx/pull/1524

From kcr at openjdk.org  Wed Aug 14 23:54:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 23:54:52 GMT
Subject: RFR: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
References: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
Message-ID: <MzdS11r8ozPjCdRYsFNCPOqgKuUkqMDgEv92h6A6jfc=.c76f3ec0-85e0-4b2b-8bb9-c592424c9b31@github.com>

On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces the `Util.isOnWayland()` method and skips failing tests on Wayland.
> 
> After that, all tests run on Wayland without failures.

Looks good. A full test on our headful Wayland system now skips these tests (rather than failing).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1536#pullrequestreview-2239343340

From kcr at openjdk.org  Wed Aug 14 23:59:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 14 Aug 2024 23:59:52 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
In-Reply-To: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
Message-ID: <OM6Mma-omhyxZ7U2v3nH2n3PRjvvhuT2GlTLdPlyF0A=.f02645d7-8b38-4755-84cf-45de20512c21@github.com>

On Tue, 13 Aug 2024 22:27:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding SplitMenuButton constructors matching MenuButton:
> 
> - public SplitMenuButton(String text)
> - public SplitMenuButton(String text, Node graphic)
> - public SplitMenuButton(String text, Node graphic, MenuItem... items)

The API change looks good. Can you add tests for the new constructors in SplitMenuButtonTest, similar to those in MenuButtonTest?

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

PR Review: https://git.openjdk.org/jfx/pull/1535#pullrequestreview-2239346495

From fkirmaier at openjdk.org  Thu Aug 15 09:28:54 2024
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 15 Aug 2024 09:28:54 GMT
Subject: RFR: 8337656 iOS WebView Position
In-Reply-To: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
References: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
Message-ID: <XkXO4Ez9U-UZiURqu7uwCSfCr5H4m86cMdGLNHXR2UU=.8033106f-b2c3-42ea-a732-f1a4c71c0f1e@github.com>

On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Fixing WebView on iOS
> (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.)
> 
> @johanvos 
> If this looks reasonable to you, can you provide a test build for @dlemmermann ?
> Then he can test it with his JFX-Central iOS version.

Just some more Feedback.
The position of the WebView on iOS is sometimes wrong.
I assume it's because its position is only updated when its layout bounds change.
But it should be updated whenever its position - relative to the scene, is changed.
Therefore, I only change what we put the listener. It's a one-line change.
(The rest is refactoring to avoid duplicated code)

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

PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2290961459

From duke at openjdk.org  Thu Aug 15 09:33:54 2024
From: duke at openjdk.org (Dirk Lemmermann)
Date: Thu, 15 Aug 2024 09:33:54 GMT
Subject: RFR: 8337656 iOS WebView Position
In-Reply-To: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
References: <S4S4hmaJkhiTprEJ3knP7z7IdKHddQBIkI7VILmdYLs=.2ccc9ee2-43c1-47ae-8d47-873c3f8c1521@github.com>
Message-ID: <0UpECE4MragApQnyK-tadBylNRvUQPTJD4UOwRKmufw=.e2df1675-a3dc-45f9-8e71-27d2157b474d@github.com>

On Thu, 1 Aug 2024 11:40:06 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Fixing WebView on iOS
> (I couldn't compile it because I don't know how to build it for iOS, but the code should be correct.)
> 
> @johanvos 
> If this looks reasonable to you, can you provide a test build for @dlemmermann ?
> Then he can test it with his JFX-Central iOS version.

The bug can be tested by running the jfxcentral app on ios. The project is completely configured and can be quickly installed on your phone via the standard GluonFX plugin. The bug becomes visible when opening Frank's tutorial for an "LED strip with a JavaFX UI".

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

PR Comment: https://git.openjdk.org/jfx/pull/1526#issuecomment-2290966640

From angorya at openjdk.org  Thu Aug 15 14:46:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Aug 2024 14:46:23 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
Message-ID: <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>

> Adding SplitMenuButton constructors matching MenuButton:
> 
> - public SplitMenuButton(String text)
> - public SplitMenuButton(String text, Node graphic)
> - public SplitMenuButton(String text, Node graphic, MenuItem... items)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1535/files
  - new: https://git.openjdk.org/jfx/pull/1535/files/8aaa08b0..3f08be59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1535&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1535&range=00-01

  Stats: 63 lines in 1 file changed: 62 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1535.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1535/head:pull/1535

PR: https://git.openjdk.org/jfx/pull/1535

From angorya at openjdk.org  Thu Aug 15 15:13:54 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Aug 2024 15:13:54 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <OM6Mma-omhyxZ7U2v3nH2n3PRjvvhuT2GlTLdPlyF0A=.f02645d7-8b38-4755-84cf-45de20512c21@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <OM6Mma-omhyxZ7U2v3nH2n3PRjvvhuT2GlTLdPlyF0A=.f02645d7-8b38-4755-84cf-45de20512c21@github.com>
Message-ID: <0D4Sp9vYvnDZ_W0YdvqyO4Xcx_hTJy_wGEz6hxm8JXM=.fec928a9-9361-4ba9-8542-a162e062cbcd@github.com>

On Wed, 14 Aug 2024 23:56:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The API change looks good. Can you add tests for the new constructors in SplitMenuButtonTest, similar to those in MenuButtonTest?

tests added.

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

PR Comment: https://git.openjdk.org/jfx/pull/1535#issuecomment-2291494847

From kcr at openjdk.org  Thu Aug 15 15:20:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Aug 2024 15:20:54 GMT
Subject: RFR: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
References: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
Message-ID: <G_KdZBYQVdj-afYckka4NeepCpN_I6bleWIVokc-hnU=.ce091636-56d2-4505-bce3-8de004be9ab3@github.com>

On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces the `Util.isOnWayland()` method and skips failing tests on Wayland.
> 
> After that, all tests run on Wayland without failures.

A single reviewer should be enough for this test fix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1536#issuecomment-2291505592

From azvegint at openjdk.org  Thu Aug 15 15:35:59 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 15 Aug 2024 15:35:59 GMT
Subject: Integrated: 8337827: [XWayland] Skip failing tests on Wayland
In-Reply-To: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
References: <xEY2YTyzrpUXxG8VAFtSPpZZq4edP-kLVsXNsm2033Q=.025f9e42-cc82-4de3-823e-69985fef23d5@github.com>
Message-ID: <289loz0ZB6E3KU4N7WPaGg5UN5S1Mgq9WkZlAErP89g=.99a21cc3-7867-4207-ac98-4f676a68ee3b@github.com>

On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces the `Util.isOnWayland()` method and skips failing tests on Wayland.
> 
> After that, all tests run on Wayland without failures.

This pull request has now been integrated.

Changeset: 0ee74e18
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2
Stats:     31 lines in 4 files changed: 25 ins; 5 del; 1 mod

8337827: [XWayland] Skip failing tests on Wayland

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1536

From mstrauss at openjdk.org  Thu Aug 15 16:55:55 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 Aug 2024 16:55:55 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
Message-ID: <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>

On Thu, 15 Aug 2024 14:46:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding SplitMenuButton constructors matching MenuButton:
>> 
>> - public SplitMenuButton(String text)
>> - public SplitMenuButton(String text, Node graphic)
>> - public SplitMenuButton(String text, Node graphic, MenuItem... items)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests

modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitMenuButtonTest.java line 34:

> 32: import org.junit.Test;
> 33: 
> 34: import static org.junit.Assert.*;

Since you're modifying this file significantly, you could also use the JUnit5 imports.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718701002

From angorya at openjdk.org  Thu Aug 15 17:10:00 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Aug 2024 17:10:00 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
 <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
Message-ID: <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>

On Thu, 15 Aug 2024 16:53:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tests
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitMenuButtonTest.java line 34:
> 
>> 32: import org.junit.Test;
>> 33: 
>> 34: import static org.junit.Assert.*;
> 
> Since you're modifying this file significantly, you could also use the JUnit5 imports.

I think that would be out of scope for this PR.

We are considering updating tests to junit5 in bulk at some point, but I suspect it's a fairly low priority, unless we need to address something like https://bugs.openjdk.org/browse/JDK-8328629

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718724352

From mstrauss at openjdk.org  Thu Aug 15 17:43:56 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 Aug 2024 17:43:56 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
 <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
 <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>
Message-ID: <BO2gQXRks25sMpEpJLQ2lpKmd8Z99smKrcuzEQKkVRE=.f7d83a22-9e98-46f7-b411-021184125cfd@github.com>

On Thu, 15 Aug 2024 17:07:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/SplitMenuButtonTest.java line 34:
>> 
>>> 32: import org.junit.Test;
>>> 33: 
>>> 34: import static org.junit.Assert.*;
>> 
>> Since you're modifying this file significantly, you could also use the JUnit5 imports.
>
> I think that would be out of scope for this PR.
> 
> We are considering updating tests to junit5 in bulk at some point, but I suspect it's a fairly low priority, unless we need to address something like https://bugs.openjdk.org/browse/JDK-8328629

Well, you _do_ modify this file significantly, so it's not entirely out of scope. I've been converting files over to JUnit5 in the past as part of significant modifications, I think it's a valid path to get us to eventually move completely to JUnit5 (because as you say, bulk conversion isn't probably happening any time soon).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718773749

From angorya at openjdk.org  Thu Aug 15 17:51:54 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Aug 2024 17:51:54 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <BO2gQXRks25sMpEpJLQ2lpKmd8Z99smKrcuzEQKkVRE=.f7d83a22-9e98-46f7-b411-021184125cfd@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
 <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
 <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>
 <BO2gQXRks25sMpEpJLQ2lpKmd8Z99smKrcuzEQKkVRE=.f7d83a22-9e98-46f7-b411-021184125cfd@github.com>
Message-ID: <7zTP-nAEb64lTZh9fWuhLjgtZqhDen-yYKaqEyGKRO0=.f21e61cb-bf9e-4022-b774-1c248a3fb13d@github.com>

On Thu, 15 Aug 2024 17:41:44 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I think that would be out of scope for this PR.
>> 
>> We are considering updating tests to junit5 in bulk at some point, but I suspect it's a fairly low priority, unless we need to address something like https://bugs.openjdk.org/browse/JDK-8328629
>
> Well, you _do_ modify this file significantly, so it's not entirely out of scope. I've been converting files over to JUnit5 in the past as part of significant modifications, I think it's a valid path to get us to eventually move completely to JUnit5 (because as you say, bulk conversion isn't probably happening any time soon).

I do that too, typically.  But here I just copied some code from a sibling test.

If we are converting, then we also should convert MenuButtonTest as well, and now we are widening the scope.  There is no gain in going with junit5 with this test specifically, so I don't really want to do it right now, I would rather do it as a part of a bulk change.

Do you want me to convert this test?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718781360

From angorya at openjdk.org  Thu Aug 15 17:55:52 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Aug 2024 17:55:52 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <7zTP-nAEb64lTZh9fWuhLjgtZqhDen-yYKaqEyGKRO0=.f21e61cb-bf9e-4022-b774-1c248a3fb13d@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
 <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
 <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>
 <BO2gQXRks25sMpEpJLQ2lpKmd8Z99smKrcuzEQKkVRE=.f7d83a22-9e98-46f7-b411-021184125cfd@github.com>
 <7zTP-nAEb64lTZh9fWuhLjgtZqhDen-yYKaqEyGKRO0=.f21e61cb-bf9e-4022-b774-1c248a3fb13d@github.com>
Message-ID: <T1egv2VvFu8I-6Q9d7Nr8GsImy0vlljlzqxJ8TlX1eY=.449c23c3-e450-4918-8e4b-869acad2c8a3@github.com>

On Thu, 15 Aug 2024 17:49:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Well, you _do_ modify this file significantly, so it's not entirely out of scope. I've been converting files over to JUnit5 in the past as part of significant modifications, I think it's a valid path to get us to eventually move completely to JUnit5 (because as you say, bulk conversion isn't probably happening any time soon).
>
> I do that too, typically.  But here I just copied some code from a sibling test.
> 
> If we are converting, then we also should convert MenuButtonTest as well, and now we are widening the scope.  There is no gain in going with junit5 with this test specifically, so I don't really want to do it right now, I would rather do it as a part of a bulk change.
> 
> Do you want me to convert this test?

created https://bugs.openjdk.org/browse/JDK-8338468

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718786150

From mstrauss at openjdk.org  Thu Aug 15 18:08:00 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 Aug 2024 18:08:00 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
Message-ID: <gqm53qEZsrHgA_--lmwN0TpN212Qc_tAyh6pOvyXTLw=.4ea849e2-9df7-4930-b2f4-e0090277228e@github.com>

On Thu, 15 Aug 2024 14:46:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding SplitMenuButton constructors matching MenuButton:
>> 
>> - public SplitMenuButton(String text)
>> - public SplitMenuButton(String text, Node graphic)
>> - public SplitMenuButton(String text, Node graphic, MenuItem... items)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests

Marked as reviewed by mstrauss (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1535#pullrequestreview-2241022648

From mstrauss at openjdk.org  Thu Aug 15 18:08:01 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 15 Aug 2024 18:08:01 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <T1egv2VvFu8I-6Q9d7Nr8GsImy0vlljlzqxJ8TlX1eY=.449c23c3-e450-4918-8e4b-869acad2c8a3@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
 <XkPZ3pa2iM_bs50GWrQs6WsTR4yP_atyKwmpNSR03Xc=.aa10f1ee-dc43-44f9-989e-d49609d3d0aa@github.com>
 <X5oLXFzB_z0WIJdDorMrK53RA1s_ughLlsDVPUiebBg=.b50c3d03-154b-4fbb-bdc3-3331b0a96bd9@github.com>
 <BO2gQXRks25sMpEpJLQ2lpKmd8Z99smKrcuzEQKkVRE=.f7d83a22-9e98-46f7-b411-021184125cfd@github.com>
 <7zTP-nAEb64lTZh9fWuhLjgtZqhDen-yYKaqEyGKRO0=.f21e61cb-bf9e-4022-b774-1c248a3fb13d@github.com>
 <T1egv2VvFu8I-6Q9d7Nr8GsImy0vlljlzqxJ8TlX1eY=.449c23c3-e450-4918-8e4b-869acad2c8a3@github.com>
Message-ID: <C0hmRMB-gB4Cmz4uqEeAzgWCZY1uDoHS8I7w8Bci1ts=.a2bd5bb0-8fa7-4d4e-b188-0d1f625646a0@github.com>

On Thu, 15 Aug 2024 17:53:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I do that too, typically.  But here I just copied some code from a sibling test.
>> 
>> If we are converting, then we also should convert MenuButtonTest as well, and now we are widening the scope.  There is no gain in going with junit5 with this test specifically, so I don't really want to do it right now, I would rather do it as a part of a bulk change.
>> 
>> Do you want me to convert this test?
>
> created https://bugs.openjdk.org/browse/JDK-8338468

It's okay, I'd just like to see it get done _eventually_.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1535#discussion_r1718798147

From dlemmermann at gmail.com  Fri Aug 16 10:12:41 2024
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Fri, 16 Aug 2024 12:12:41 +0200
Subject: Label Text Selection
Message-ID: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>

Hi everyone,

I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible? 

I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.

Dirk


From daniel.peintner at gmail.com  Fri Aug 16 10:25:13 2024
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Fri, 16 Aug 2024 12:25:13 +0200
Subject: Label Text Selection
In-Reply-To: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
Message-ID: <CAAoP7T7ttYu965qSNYfTWhwYKZwFDzgCertRfLL4b-bLFbAZjw@mail.gmail.com>

Hi Dirk, all,

Personally I think this would be a great addition since I am getting the
same request over and over again.
I solved it by *mis-using* a TextField and making it look like a Label.

Thanks all for your efforts,

-- Daniel


On Fri, Aug 16, 2024 at 12:13?PM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> Hi everyone,
>
> I recently added a custom text control (called ?TextView") to the GemsFX
> project. It supports a somewhat limited text selection. Selection is only
> possible on a per-word basis. I received a bit of feedback on this control
> and I was wondering whether it would be worth thinking about adding a
> general text selection capability to labels. Is this something worth
> looking into? Is it even feasible?
>
> I guess one of the reasons why this topic keeps popping up is the fact
> that users are so used to selecting any text in web pages, but they can?t
> do it in desktop apps.
>
> Dirk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240816/1255aada/attachment.htm>

From thiago.sayao at gmail.com  Fri Aug 16 10:29:38 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 16 Aug 2024 07:29:38 -0300
Subject: Label Text Selection
In-Reply-To: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
Message-ID: <CAAP_wumy47vWX7p1DzA6kgJD5KLfzDknEGdBv_vd84wjbpRQdA@mail.gmail.com>

Hi Dirk,

This would be great. It's a feature I miss.

On my scenario (we do a POS pharmacy software) users want to copy things
such as product code/barcode, description, etc.

I think it's not a trivial task to develop this, since labels can wrap,
ellipsise. They are inside tables and other components.

Some countries have user information protection laws, so it should not
always be enabled.

-- Thiago



Em sex., 16 de ago. de 2024 07:13, Dirk Lemmermann <dlemmermann at gmail.com>
escreveu:

> Hi everyone,
>
> I recently added a custom text control (called ?TextView") to the GemsFX
> project. It supports a somewhat limited text selection. Selection is only
> possible on a per-word basis. I received a bit of feedback on this control
> and I was wondering whether it would be worth thinking about adding a
> general text selection capability to labels. Is this something worth
> looking into? Is it even feasible?
>
> I guess one of the reasons why this topic keeps popping up is the fact
> that users are so used to selecting any text in web pages, but they can?t
> do it in desktop apps.
>
> Dirk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240816/ce1449b3/attachment-0001.htm>

From tobias.oelgarte at gmail.com  Fri Aug 16 15:17:47 2024
From: tobias.oelgarte at gmail.com (Tobias Oelgarte)
Date: Fri, 16 Aug 2024 17:17:47 +0200
Subject: Label Text Selection
In-Reply-To: <CAAP_wumy47vWX7p1DzA6kgJD5KLfzDknEGdBv_vd84wjbpRQdA@mail.gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
 <CAAP_wumy47vWX7p1DzA6kgJD5KLfzDknEGdBv_vd84wjbpRQdA@mail.gmail.com>
Message-ID: <940f6a48-838f-4565-914d-69be2ceadfaf@gmail.com>

I would also like to see this implemented, but as an additional 
"SelectableLabel" control, to avoid side effects (ellipsise, ...).

I also had to use the non editable TextField hack way to often.

On 16.08.24 12:29, Thiago Milczarek Say?o wrote:
> Hi Dirk,
>
> This would be great. It's a feature I miss.
>
> On my scenario (we do a POS pharmacy software) users want to copy 
> things such as product code/barcode, description, etc.
>
> I think it's not a trivial task to develop this, since labels can 
> wrap, ellipsise. They are inside tables and other components.
>
> Some countries have user information protection laws, so it should not 
> always be enabled.
>
> -- Thiago
>
>
>
> Em sex., 16 de ago. de 2024 07:13, Dirk Lemmermann 
> <dlemmermann at gmail.com> escreveu:
>
>     Hi everyone,
>
>     I recently added a custom text control (called ?TextView") to the
>     GemsFX project. It supports a somewhat limited text selection.
>     Selection is only possible on a per-word basis. I received a bit
>     of feedback on this control and I was wondering whether it would
>     be worth thinking about adding a general text selection capability
>     to labels. Is this something worth looking into? Is it even feasible?
>
>     I guess one of the reasons why this topic keeps popping up is the
>     fact that users are so used to selecting any text in web pages,
>     but they can?t do it in desktop apps.
>
>     Dirk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240816/fc030fe4/attachment.htm>

From quizynox at gmail.com  Fri Aug 16 15:40:09 2024
From: quizynox at gmail.com (quizynox)
Date: Fri, 16 Aug 2024 19:40:09 +0400
Subject: Label Text Selection
In-Reply-To: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
Message-ID: <4b55ee9b-cbc6-4652-9a41-afa3c4015569@gmail.com>

Hello,

Both TextFlow and Text support the HitInfo API, which makes getting 
selected characters very easy. Then you just need to wrap the selected 
characters in Path. The way it is implemented in GemsFX with overlay 
pane is quite complicated. Here is a rough sketch of the selectable 
TextFlow I plan to release in AtlantaFX. I think implementing a 
selectable Label by wrapping a text node in Region isn't much harder. 
But I wouldn't mind if it was the Label out-of-the-box feature, although 
I think it would require implementing some sort of selection model, so 
it's unlikely to happen.

source code:
https://pastebin.com/9QKWYfx1

On 16/08/2024 14.12, Dirk Lemmermann wrote:
> Hi everyone,
>
> I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible?
>
> I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.
>
> Dirk
>

From andy.goryachev at oracle.com  Fri Aug 16 16:05:04 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 16 Aug 2024 16:05:04 +0000
Subject: Label Text Selection
In-Reply-To: <940f6a48-838f-4565-914d-69be2ceadfaf@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
 <CAAP_wumy47vWX7p1DzA6kgJD5KLfzDknEGdBv_vd84wjbpRQdA@mail.gmail.com>
 <940f6a48-838f-4565-914d-69be2ceadfaf@gmail.com>
Message-ID: <BL3PR10MB6185C51206E06BE2720BDAC3E5812@BL3PR10MB6185.namprd10.prod.outlook.com>

TextArea is probably the right approach given the requirements (selection, avoiding ellipses).  It needs one improvement though which is ?use content height? https://bugs.openjdk.org/browse/JDK-8310593 RFE to get rid of the scroll bars.

One can also try implementing a custom component modeled after TextArea/Label since the underlying Text class supports selection.

A different solution might involve adding a context menu with ?Copy Text to Clipboard?, but that might not work if the requirement is to be able to select portions of the text.

I doubt this qualifies as a standard component though, but that?s just my opinion.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Tobias Oelgarte <tobias.oelgarte at gmail.com>
Date: Friday, August 16, 2024 at 08:18
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Label Text Selection

I would also like to see this implemented, but as an additional "SelectableLabel" control, to avoid side effects (ellipsise, ...).

I also had to use the non editable TextField hack way to often.
On 16.08.24 12:29, Thiago Milczarek Say?o wrote:
Hi Dirk,

This would be great. It's a feature I miss.

On my scenario (we do a POS pharmacy software) users want to copy things such as product code/barcode, description, etc.

I think it's not a trivial task to develop this, since labels can wrap, ellipsise. They are inside tables and other components.

Some countries have user information protection laws, so it should not always be enabled.

-- Thiago



Em sex., 16 de ago. de 2024 07:13, Dirk Lemmermann <dlemmermann at gmail.com<mailto:dlemmermann at gmail.com>> escreveu:
Hi everyone,

I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible?

I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.

Dirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240816/cba6121d/attachment-0001.htm>

From mfox at openjdk.org  Fri Aug 16 16:57:06 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 Aug 2024 16:57:06 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
Message-ID: <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>

On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>> 
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
>> 
>> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
> 
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'refs/heads/master' into new_ime
>  - Merge branch 'master' into new_ime
>  - Add signals to avoid warnings
>  - Merge branch 'master' into new_ime
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>  - Add check for jview
>  - - Fix comment path
>  - - Fix double keyrelease
>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>    - Unref pango attr list
>  - Merge branch 'master' into new_ime
>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec

I took another look and left some inline comments.

Overall looks good to me. I've been doing some testing looking at the stream of KeyEvents and InputMethod events and it all seems to be working as expected.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkView.java line 123:

> 121:         if (w != null) {
> 122:             pos[0] -= (pos[0] > 0) ? ((w.getX() + getX())) : 0;
> 123:             pos[1] -= (pos[1] > 0) ? ((w.getY() + getY())) : 0;

This code will only adjust a position coordinate if it's positive. I can't easily test a dual-display Linux system but I'm pretty sure X or Y can be negative on a secondary display to the left or above the primary display. I think the conditional checks should be removed (but would appreciate a second opinion on this).

By the way, I test on a Retina display at 200% scaling and the IM positioning is working as expected.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 110:

> 108:                 slen,
> 109:                 slen,
> 110:                 NULL);

This call is expecting a byte integer so you should be passing in 0 instead of NULL.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 186:

> 184: void WindowContextBase::disableIME() {
> 185:     if (im_ctx.ctx != NULL) {
> 186:         g_signal_handlers_disconnect_matched(im_ctx.ctx, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NULL);

Since you're not passing in any data this disconnect call isn't disconnecting anything. Either pass `this` in the data argument or use `g_signal_handlers_disconnect_by_data` or just remove this line completely. According to the documentation the signal handlers will be disconnected when the IM context object is destroyed (but double-check that, I'm not a GObject expert).

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

Changes requested by mfox (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1080#pullrequestreview-2243000603
PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1720014105
PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1720027640
PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1720020746

From mfox at openjdk.org  Fri Aug 16 17:06:24 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 Aug 2024 17:06:24 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <LPAb1dUZi0fsoSpH5fbw8j158Zg96_ynuHWlKJT-46c=.c481a898-8b09-4c24-b112-50c535e3b205@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
 <LPAb1dUZi0fsoSpH5fbw8j158Zg96_ynuHWlKJT-46c=.c481a898-8b09-4c24-b112-50c535e3b205@github.com>
Message-ID: <H-fiXEqKRGrlc7D6tjBgu8w9ukX0OkqcgNz9RHdAjZI=.19d18a34-1546-4d8a-937b-bd33efda9ac8@github.com>

On Tue, 13 Aug 2024 21:46:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> is there a compelling reason we are not using Event::isConsumed?

As detailed in the discussion of PR #1523 the `isConsumed` flag doesn't work because the consumed event is a copy of the original one. The reliable way is to compare the result of the dispatch against null.

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2289084088

From mfox at openjdk.org  Fri Aug 16 17:06:24 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 Aug 2024 17:06:24 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value [v2]
In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
Message-ID: <9Mz-Z4B-uzX9_R2r_byykMmndy1cIIZjXtKSPSomUU8=.f1357296-8c8a-46b7-bddd-8df8ee84cd6b@github.com>

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crack at the event before it works its way out to the menu bar.
> 
> We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.
> 
> I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

Martin Fox has updated the pull request incrementally with three additional commits since the last revision:

 - Added some comments
 - Removed redundant check to avoid having the same NSEvent sent into
   the scene graph twice.
 - performKeyEquivalent and keyDown now do the same thing with a guard
   to prevent double-processing.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1528/files
  - new: https://git.openjdk.org/jfx/pull/1528/files/06d9422c..592b317e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1528&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1528&range=00-01

  Stats: 39 lines in 4 files changed: 24 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1528.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1528/head:pull/1528

PR: https://git.openjdk.org/jfx/pull/1528

From angorya at openjdk.org  Fri Aug 16 17:06:24 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Aug 2024 17:06:24 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
Message-ID: <LPAb1dUZi0fsoSpH5fbw8j158Zg96_ynuHWlKJT-46c=.c481a898-8b09-4c24-b112-50c535e3b205@github.com>

On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crack at the event before it works its way out to the menu bar.
> 
> We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.
> 
> I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

is there a compelling reason we are not using Event::isConsumed?

Maybe this case should also propagate `::isConsumed` flag similarly to #1523 

It looks to me we are trying to invent band-aids to what appears to be a design problem (cloning the events regardless of their `::isConsumed` state)

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2287194575
PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2289099708

From mfox at openjdk.org  Fri Aug 16 17:06:24 2024
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 16 Aug 2024 17:06:24 GMT
Subject: RFR: 8087863: Mac: "Select All" within ListView/TreeView is
 handled differently depending on the useSystemMenuBar value
In-Reply-To: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
References: <0rDxjMN_FmXkpieAulY_nPMZCML59SrTh4O52vkXtfg=.38c46e71-2983-429e-a6b9-4ae22bab943e@github.com>
Message-ID: <LtLgzpOHs55qGW3GV1Ok-NZxX2BIyzVIOigmkalXojg=.dcdbef32-21dd-493c-a630-0c82fe44df90@github.com>

On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it?s shopped around as a ?key equivalent?. If it?s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crack at the event before it works its way out to the menu bar.
> 
> We can?t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn?t allow it to continue on to the system menu bar.
> 
> I?m trying to fix this old, old problem because I?ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there?s just a boolean return value that needs to be plumbed through multiple layers.

Taking this out of Draft. To ensure consistent handling of the IM both `keyDown:` and `performKeyEquivalent:` use the same routine. There's a check to ensure that the same event doesn't get processed twice which mimics an older check that used to be in the view delegate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2293854333

From kcr at openjdk.org  Fri Aug 16 17:35:55 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Aug 2024 17:35:55 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v8]
In-Reply-To: <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
Message-ID: <sV3MhnbsVQt4bSjgBHKVevTuQEaA1lDiG-yG_tf-GZA=.4a310e1b-1cb3-49de-9ca4-2eaed5e7bfe2@github.com>

On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix javadoc
>  - Remove unnecessary suppress warnings

Doc changes and implementation both look good. I left one comment and will reapprove if you decide to make that change.

Please create the CSR.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2243153037

From kcr at openjdk.org  Fri Aug 16 17:35:56 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Aug 2024 17:35:56 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <DZYtD6xmcbHNnd9N7crWcZKwiOil2Ofe6y6eoQzkGt8=.22e0bc3a-2469-436e-8882-b1470172ef77@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <gHMwQy7NMcip72bDJtSxYmj0QuJiWho14OANLK1V57I=.49f99385-7274-4386-a4a1-a4b6b1094283@github.com>
 <DZYtD6xmcbHNnd9N7crWcZKwiOil2Ofe6y6eoQzkGt8=.22e0bc3a-2469-436e-8882-b1470172ef77@github.com>
Message-ID: <8rPYNEkOm5Pp-1o9M6-Coum-GC2KnYn2tf9Mghucj0M=.125ff814-7d72-45db-b710-fb55f11271e7@github.com>

On Wed, 7 Aug 2024 22:58:57 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Anyway, I'm fine with rejecting values that are not `TYPE_SIMPLE`.

That seems like a good idea for maximum compatibility.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1720105420

From kcr at openjdk.org  Fri Aug 16 17:45:57 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Aug 2024 17:45:57 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v8]
In-Reply-To: <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
Message-ID: <WB7aw59ezZTjJ00ChT3LQWFz_RZUj2-AG0f2cYgSxRg=.3d6e3dcf-63e8-4537-a8f3-fd5aa50afa59@github.com>

On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix javadoc
>  - Remove unnecessary suppress warnings

This PR is more limited in scope than when I initially requested 3 reviewers. I think 2 reviewers are sufficient. If someone else wants to review it as well, that would be fine. It will take a few more days to get the CSR reviewed and approved, so there will be time for others to weigh in if desired.

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2293905318

From angorya at openjdk.org  Fri Aug 16 17:45:57 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Aug 2024 17:45:57 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v8]
In-Reply-To: <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <ZdbEJSPGT3RYmUxWKn7TPOlliRbwiYxrxdXOeD4z4vc=.02df3ba4-b26e-4a96-9659-e944256c1b37@github.com>
Message-ID: <7JwRLqKYTw0ZkmXAcmRi-LYucjwksnZLQxC9ZZ5j7H0=.24f4788a-1ce1-4aca-8bf2-c0f6db677a06@github.com>

On Tue, 13 Aug 2024 12:18:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>> 
>> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before.  However, these classes could not be constructed by 3rd parties.  The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types).  The reason they were public at all was because the CSS engine needs to be able to access them from internal packages.
>> 
>> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`).
>> 
>> This PR as said has a small API break.  The other changes are (AFAICS) source and binary compatible:
>> 
>> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses
>> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose)
>> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible
>> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant
>> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector`
>> - No need anymore for the `SimpleSelectorShim`
>
> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix javadoc
>  - Remove unnecessary suppress warnings

I agree - two reviewers should be fine.

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2293907196

From kcr at openjdk.org  Fri Aug 16 18:01:58 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Aug 2024 18:01:58 GMT
Subject: RFR: 8338016: SplitMenuButton constructors should match MenuButton
 [v2]
In-Reply-To: <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
 <c1PVAtVxqc3S5FqW3_yciBTSyr2cfoBqzdtiCrIfTEM=.dc73dc72-e27e-4954-955b-81b3f96c8232@github.com>
Message-ID: <LjS9UzQkcb4x2PL8o7B97SqfbRwhkNFVIJVtbuV_1UA=.76b92eff-69b2-4631-ae39-e170cb4ec837@github.com>

On Thu, 15 Aug 2024 14:46:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding SplitMenuButton constructors matching MenuButton:
>> 
>> - public SplitMenuButton(String text)
>> - public SplitMenuButton(String text, Node graphic)
>> - public SplitMenuButton(String text, Node graphic, MenuItem... items)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1535#pullrequestreview-2243251544

From kcr at openjdk.org  Fri Aug 16 20:30:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Aug 2024 20:30:53 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <ctMoosdsyoSZ3wdOxPKri-nfRYOTgfpVLWJmCjGvLPw=.ab3f9ba1-d588-4c39-b9ef-ebf0a924f293@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

This causes a regression on Ubuntu 22.04. The following tests fail with this fix (they all pass with current master), when using X.org or Wayland:


SizeToSceneTest > testInitialSizeOnFullscreenThenSizeToScene() FAILED
    org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>

SizeToSceneTest > testInitialSizeOnMaximizedThenSizeToScene() FAILED
    org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>

SizeToSceneTest > testInitialSizeOnSizeToSceneThenMaximized() FAILED
    org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>


On Ubuntu 24.04 there are also some new failures in `SizeToSceneTest ` with this PR, but several of the test fail anyway on 24.04

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

PR Review: https://git.openjdk.org/jfx/pull/1520#pullrequestreview-2243499088

From angorya at openjdk.org  Fri Aug 16 22:01:01 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Aug 2024 22:01:01 GMT
Subject: Integrated: 8338016: SplitMenuButton constructors should match
 MenuButton
In-Reply-To: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
References: <2UW6YzPuOlS6nAfoBOY1v8UE5GbM8Bfbvi6wRJ1udpg=.d24cf69f-30c3-49bb-9791-5db57a7b2c54@github.com>
Message-ID: <ndAEwT2LTNHivYh9XvRODeffzu8m95AxP4muPth3Myc=.379146b4-d291-443c-87c1-36f28b77e385@github.com>

On Tue, 13 Aug 2024 22:27:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding SplitMenuButton constructors matching MenuButton:
> 
> - public SplitMenuButton(String text)
> - public SplitMenuButton(String text, Node graphic)
> - public SplitMenuButton(String text, Node graphic, MenuItem... items)

This pull request has now been integrated.

Changeset: 3261e940
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3261e940c0905b78230d5b6ce7980ed2d7476dfb
Stats:     110 lines in 2 files changed: 107 ins; 0 del; 3 mod

8338016: SplitMenuButton constructors should match MenuButton

Reviewed-by: kcr, mstrauss

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

PR: https://git.openjdk.org/jfx/pull/1535

From nlisker at openjdk.org  Sat Aug 17 15:59:59 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 17 Aug 2024 15:59:59 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v25]
In-Reply-To: <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
Message-ID: <KE0ZTKZgyz1Ota9eWdQ_NXJVRCvWZ74FDT2cBUmwo4c=.34641fba-d027-462e-bb70-1343a86d31d4@github.com>

On Fri, 9 Aug 2024 22:32:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions.
>> 
>> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`:
>> 
>> 
>> Background {
>>     fills = [
>>         BackgroundFill {
>>             fill = Color.RED
>>         }
>>     ]
>> }
>> 
>> 
>> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`.
>> 
>> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds.
>> 
>> More specifically, the following types will now implement `Interpolatable`.
>> 
>> - `Insets`
>> - `Background`
>> - `BackgroundFill`
>> - `BackgroundImage`
>> - `BackgroundPosition`
>> - `BackgroundSize`
>> - `Border`
>> - `BorderImage`
>> - `BorderStroke`
>> - `BorderWidths`
>> - `CornerRadii`
>> - `Stop`
>> - `Paint` and all of its subclasses
>> - `Margins` (internal type)
>> - `BorderImageSlices` (internal type)
>> 
>> ## Interpolation of composite objects
>> 
>> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation".
>> 
>> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation:
>> 
>> | Interpolation type | Description |
>> |---|---|
>> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. |
>> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. |
>> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. |
>> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove StyleConverter.WithReconstructionSupport

> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation

Can you give a link to these CSS specifications?

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2294898337

From mstrauss at openjdk.org  Sat Aug 17 17:46:02 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 17 Aug 2024 17:46:02 GMT
Subject: RFR: 8332895: Support interpolation for backgrounds and borders
 [v25]
In-Reply-To: <KE0ZTKZgyz1Ota9eWdQ_NXJVRCvWZ74FDT2cBUmwo4c=.34641fba-d027-462e-bb70-1343a86d31d4@github.com>
References: <KMipYH2z4sQX68vEIVj2CR4VJgnDUcNovCGTyXLqIfM=.58b5c8c2-1d6c-4cc2-90c0-4856b75de14f@github.com>
 <JKXiTa1yyhIEayJat6f7zacaUavlV20T8pVjRLlxyuU=.e042cb74-047e-4628-b605-cd205b30fa7f@github.com>
 <KE0ZTKZgyz1Ota9eWdQ_NXJVRCvWZ74FDT2cBUmwo4c=.34641fba-d027-462e-bb70-1343a86d31d4@github.com>
Message-ID: <0SnRNvQxMvJdJUJ-au1Y7M1d3vGthR6pEu1ixGKEb08=.ada3c2af-5132-4d56-8357-1a8103ca7fe5@github.com>

On Sat, 17 Aug 2024 15:57:34 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation
> 
> Can you give a link to these CSS specifications?

I shouldn't say "mirroring", it's more "inspired by".

https://www.w3.org/TR/web-animations/#animating-properties

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

PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2294924353

From prr at openjdk.org  Sat Aug 17 21:07:21 2024
From: prr at openjdk.org (Phil Race)
Date: Sat, 17 Aug 2024 21:07:21 GMT
Subject: RFR: 8338478: [macos] Crash in CoreText with certain strings using JDK
 22 or later
Message-ID: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>

The test in the bug report crashes reliably with JDK 22 on retina.
It coincides with an update to the macOS compilers which seem likely to eagerly invalidate the target of a CFRelease on the native CTFontRef.
Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until after the method has finished using the native fontRef from the strike fixes it.
The same pattern is observed in 3 other methods (although no crash)  and a fence is added there too.

There is an existing test, which is how this problem was found.

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

Commit messages:
 - 8338478
 - 8338478

Changes: https://git.openjdk.org/jfx/pull/1537/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1537&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338478
  Stats: 87 lines in 1 file changed: 32 ins; 14 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1537.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1537/head:pull/1537

PR: https://git.openjdk.org/jfx/pull/1537

From tsayao at openjdk.org  Sun Aug 18 20:13:02 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 20:13:02 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
Message-ID: <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>

On Fri, 16 Aug 2024 15:41:44 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'master' into new_ime
>>  - Add signals to avoid warnings
>>  - Merge branch 'master' into new_ime
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>>  - Add check for jview
>>  - - Fix comment path
>>  - - Fix double keyrelease
>>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>>    - Unref pango attr list
>>  - Merge branch 'master' into new_ime
>>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkView.java line 123:
> 
>> 121:         if (w != null) {
>> 122:             pos[0] -= (pos[0] > 0) ? ((w.getX() + getX())) : 0;
>> 123:             pos[1] -= (pos[1] > 0) ? ((w.getY() + getY())) : 0;
> 
> This code will only adjust a position coordinate if it's positive. I can't easily test a dual-display Linux system but I'm pretty sure X or Y can be negative on a secondary display to the left or above the primary display. I think the conditional checks should be removed (but would appreciate a second opinion on this).
> 
> By the way, I test on a Retina display at 200% scaling and the IM positioning is working as expected.

I tested on both XWayland and Xorg. They are never negative.

The input method window did always pop up on the right place.

![image](https://github.com/user-attachments/assets/05568b82-3602-48d0-acf1-65aabc8a316b)

![image](https://github.com/user-attachments/assets/14d29bc3-9e57-47c3-b573-f08871306c69)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1721048492

From tsayao at openjdk.org  Sun Aug 18 20:40:35 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 20:40:35 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v23]
In-Reply-To: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
Message-ID: <2L-cuYPPOcGwMzTWwicXt5uBhF353i52NZ3pMap8yJc=.6384dd37-ed97-40a9-9027-da8d48682990@github.com>

> This replaces obsolete XIM and uses gtk api for IME.
> Gtk uses [ibus](https://github.com/ibus/ibus)
> 
> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
> 
> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)

Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:

 - Fix review points
 - Merge branch 'master' into new_ime
 - Merge branch 'refs/heads/master' into new_ime
 - Merge branch 'refs/heads/master' into new_ime
 - Merge branch 'master' into new_ime
 - Add signals to avoid warnings
 - Merge branch 'master' into new_ime
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
 - Add check for jview
 - - Fix comment path
 - - Fix double keyrelease
 - ... and 88 more: https://git.openjdk.org/jfx/compare/3261e940...8784f485

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

Changes: https://git.openjdk.org/jfx/pull/1080/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=22
  Stats: 452 lines in 8 files changed: 65 ins; 269 del; 118 mod
  Patch: https://git.openjdk.org/jfx/pull/1080.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080

PR: https://git.openjdk.org/jfx/pull/1080

From tsayao at openjdk.org  Sun Aug 18 20:40:35 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 20:40:35 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
Message-ID: <38fH19y7YrZaWzfzppne6Hqk0b_9Lu7_1MlLMlQBJlE=.20e4e441-3022-46c8-b50e-70891f9f6f79@github.com>

On Fri, 16 Aug 2024 15:54:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'master' into new_ime
>>  - Add signals to avoid warnings
>>  - Merge branch 'master' into new_ime
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>>  - Add check for jview
>>  - - Fix comment path
>>  - - Fix double keyrelease
>>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>>    - Unref pango attr list
>>  - Merge branch 'master' into new_ime
>>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 110:
> 
>> 108:                 slen,
>> 109:                 slen,
>> 110:                 NULL);
> 
> This call is expecting a byte integer so you should be passing in 0 instead of NULL.

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1721051923

From jvos at openjdk.org  Sun Aug 18 20:41:22 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 18 Aug 2024 20:41:22 GMT
Subject: [jfx23u] RFR: 8334874: Horizontal scroll events from touch pads should
 scroll the TabPane tabs
Message-ID: <Kc9SdbmlFsJHKtSJ0Bnoze05bWQXoDf-eHp5KV841cE=.c504b7b7-15d9-4049-8510-77a1b10e44df@github.com>

Hi all,

This pull request contains a backport of commit [1bdb93c7](https://github.com/openjdk/jfx/commit/1bdb93c792cf7c218c74ec5cacda8bac1242f73b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Jose Pereda on 25 Jul 2024 and was reviewed by Andy Goryachev and Kevin Rushforth.

Thanks!

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

Commit messages:
 - Backport 1bdb93c792cf7c218c74ec5cacda8bac1242f73b

Changes: https://git.openjdk.org/jfx23u/pull/8/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=8&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334874
  Stats: 111 lines in 2 files changed: 107 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx23u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/8/head:pull/8

PR: https://git.openjdk.org/jfx23u/pull/8

From jvos at openjdk.org  Sun Aug 18 20:42:25 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 18 Aug 2024 20:42:25 GMT
Subject: [jfx17u] RFR: 8334657: Enable binary check
Message-ID: <xXNvsotWErzMa-6BLoaDPwoGghSKLojCye-48dNwUgo=.0960befa-8c1e-4033-a7f3-6c14f8e92715@github.com>

Hi all,

This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.

The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.

Thanks!

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

Commit messages:
 - Backport 101e5175ff429828de25204bc3e5f216d383060b

Changes: https://git.openjdk.org/jfx17u/pull/198/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334657
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/198.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/198/head:pull/198

PR: https://git.openjdk.org/jfx17u/pull/198

From jvos at openjdk.org  Sun Aug 18 20:51:06 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 18 Aug 2024 20:51:06 GMT
Subject: [jfx23u] RFR: 8319779: SystemMenu: memory leak due to listener never
 being removed
Message-ID: <RtC6i2J-JVRMsqZehJ7ZqIH6br9L2JZ3l6FhR3jnjD0=.316c480f-06f9-416b-ab33-39f061bb2d59@github.com>

Hi all,

This pull request contains a backport of commit 25ac6fed from the openjdk/jfx repository.

The commit being backported was authored by Johan Vos on 25 Jul 2024 and was reviewed by John Hendrikx, Ambarish Rapte and Jose Pereda.

Thanks!

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

Commit messages:
 - Backport 25ac6fed22d0f49d01c831aaa48049c34899fe96

Changes: https://git.openjdk.org/jfx23u/pull/9/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=9&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319779
  Stats: 663 lines in 5 files changed: 462 ins; 192 del; 9 mod
  Patch: https://git.openjdk.org/jfx23u/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/9/head:pull/9

PR: https://git.openjdk.org/jfx23u/pull/9

From jvos at openjdk.org  Sun Aug 18 20:52:22 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 18 Aug 2024 20:52:22 GMT
Subject: [jfx21u] RFR: 8334657: Enable binary check
Message-ID: <mL_8GfMJzEvB812LwyCNNiwqpM-Wm-Q0aJ1140uyVxI=.7b106fad-e3af-4a8b-95a4-5d61b5871b56@github.com>

Hi all,

This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.

The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.

Thanks!

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

Commit messages:
 - Backport 101e5175ff429828de25204bc3e5f216d383060b

Changes: https://git.openjdk.org/jfx21u/pull/68/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=68&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334657
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/68/head:pull/68

PR: https://git.openjdk.org/jfx21u/pull/68

From tsayao at openjdk.org  Sun Aug 18 21:09:03 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 21:09:03 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
Message-ID: <UTRDAqOKtYqidX1FUSHsJdJUtM1xru1PEiaoVM8lCNU=.f35c2955-bf8b-4825-86b1-ef1acbe37dbe@github.com>

On Fri, 16 Aug 2024 15:48:00 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:
>> 
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'refs/heads/master' into new_ime
>>  - Merge branch 'master' into new_ime
>>  - Add signals to avoid warnings
>>  - Merge branch 'master' into new_ime
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>>  - Add check for jview
>>  - - Fix comment path
>>  - - Fix double keyrelease
>>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>>    - Unref pango attr list
>>  - Merge branch 'master' into new_ime
>>  - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 186:
> 
>> 184: void WindowContextBase::disableIME() {
>> 185:     if (im_ctx.ctx != NULL) {
>> 186:         g_signal_handlers_disconnect_matched(im_ctx.ctx, G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, NULL);
> 
> Since you're not passing in any data this disconnect call isn't disconnecting anything. Either pass `this` in the data argument or use `g_signal_handlers_disconnect_by_data` or just remove this line completely. According to the documentation the signal handlers will be disconnected when the IM context object is destroyed (but double-check that, I'm not a GObject expert).

g_object_unref() will destroy signals too as its part of the object structure (as long it has no more references `g_object_ref`). So the call is not needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1721056257

From tsayao at openjdk.org  Sun Aug 18 21:12:33 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 21:12:33 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v24]
In-Reply-To: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
Message-ID: <jLXhg1Ynqi3xYcs0NHSmjEHhfLH9qnLAobw3Dr2eYo0=.1a1187c4-9665-45ed-862e-20ff77ada4f2@github.com>

> This replaces obsolete XIM and uses gtk api for IME.
> Gtk uses [ibus](https://github.com/ibus/ibus)
> 
> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
> 
> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Revert idea file
 - Remove unused import

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1080/files
  - new: https://git.openjdk.org/jfx/pull/1080/files/8784f485..1e990a62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=22-23

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1080.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080

PR: https://git.openjdk.org/jfx/pull/1080

From jpereda at openjdk.org  Sun Aug 18 21:26:55 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Sun, 18 Aug 2024 21:26:55 GMT
Subject: [jfx17u] RFR: 8334657: Enable binary check
In-Reply-To: <xXNvsotWErzMa-6BLoaDPwoGghSKLojCye-48dNwUgo=.0960befa-8c1e-4033-a7f3-6c14f8e92715@github.com>
References: <xXNvsotWErzMa-6BLoaDPwoGghSKLojCye-48dNwUgo=.0960befa-8c1e-4033-a7f3-6c14f8e92715@github.com>
Message-ID: <b_oW9vHOFztW9HJGAY5YazdV_g0gWXkEy9ksGCVLnDQ=.8d11543e-a453-4376-9713-f995a8bb5b59@github.com>

On Sun, 18 Aug 2024 20:37:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.
> 
> Thanks!

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/198#pullrequestreview-2244401782

From jpereda at openjdk.org  Sun Aug 18 21:26:56 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Sun, 18 Aug 2024 21:26:56 GMT
Subject: [jfx21u] RFR: 8334657: Enable binary check
In-Reply-To: <mL_8GfMJzEvB812LwyCNNiwqpM-Wm-Q0aJ1140uyVxI=.7b106fad-e3af-4a8b-95a4-5d61b5871b56@github.com>
References: <mL_8GfMJzEvB812LwyCNNiwqpM-Wm-Q0aJ1140uyVxI=.7b106fad-e3af-4a8b-95a4-5d61b5871b56@github.com>
Message-ID: <4mnjIt_i74VaUyy_L_aW_CY8nd-snt0muzjxCLpV6dQ=.a6c0ef59-8c62-42f3-9b28-81df9385eb37@github.com>

On Sun, 18 Aug 2024 20:46:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.
> 
> Thanks!

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/68#pullrequestreview-2244401844

From mfox at openjdk.org  Sun Aug 18 21:37:00 2024
From: mfox at openjdk.org (Martin Fox)
Date: Sun, 18 Aug 2024 21:37:00 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
 <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>
Message-ID: <XiqyxBylC1tdYeLT_NVnDHkS6wBXwVUn7tiFwRBlZrw=.dd52fcb9-503d-4484-a6ee-b461a406a374@github.com>

On Sun, 18 Aug 2024 20:10:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkView.java line 123:
>> 
>>> 121:         if (w != null) {
>>> 122:             pos[0] -= (pos[0] > 0) ? ((w.getX() + getX())) : 0;
>>> 123:             pos[1] -= (pos[1] > 0) ? ((w.getY() + getY())) : 0;
>> 
>> This code will only adjust a position coordinate if it's positive. I can't easily test a dual-display Linux system but I'm pretty sure X or Y can be negative on a secondary display to the left or above the primary display. I think the conditional checks should be removed (but would appreciate a second opinion on this).
>> 
>> By the way, I test on a Retina display at 200% scaling and the IM positioning is working as expected.
>
> I tested on both XWayland and Xorg. They are never negative.
> 
> The input method window did always pop up on the right place.
> 
> ![image](https://github.com/user-attachments/assets/05568b82-3602-48d0-acf1-65aabc8a316b)
> 
> ![image](https://github.com/user-attachments/assets/14d29bc3-9e57-47c3-b573-f08871306c69)

Interesting. I just did a quick test on the Mac and verified that either coordinate can go negative. There must be a difference in the way the platform's model multiple monitors.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1721064868

From tsayao at openjdk.org  Sun Aug 18 22:16:51 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 18 Aug 2024 22:16:51 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <zN5mes8ikJu5CvabCgmvrIFoVk3nIMNHnv5Qhsvo6A4=.205feec6-9935-46a8-bfce-80428af691f3@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

The problem is a configure event is telling that the window is at 0,0 (that's wrong). I will investigate further way this event is being sent and find a better solution.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2295414446

From tsayao at openjdk.org  Mon Aug 19 00:08:53 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 19 Aug 2024 00:08:53 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <ctMoosdsyoSZ3wdOxPKri-nfRYOTgfpVLWJmCjGvLPw=.ab3f9ba1-d588-4c39-b9ef-ebf0a924f293@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
 <ctMoosdsyoSZ3wdOxPKri-nfRYOTgfpVLWJmCjGvLPw=.ab3f9ba1-d588-4c39-b9ef-ebf0a924f293@github.com>
Message-ID: <CVZNRIaPNxqtSeEX77lcq6cmOkgu5Zt7iS5pkh9ui3c=.d70c331c-4ed5-49a0-b6fb-c57c1c3e8982@github.com>

On Fri, 16 Aug 2024 20:28:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This causes a regression on Ubuntu 22.04. The following tests fail with this fix (they all pass with current master), when using X.org or Wayland:
> 
> ```
> SizeToSceneTest > testInitialSizeOnFullscreenThenSizeToScene() FAILED
>     org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>
> 
> SizeToSceneTest > testInitialSizeOnMaximizedThenSizeToScene() FAILED
>     org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>
> 
> SizeToSceneTest > testInitialSizeOnSizeToSceneThenMaximized() FAILED
>     org.opentest4j.AssertionFailedError: 360.0 >= 1870.0 ==> expected: <true> but was: <false>
> ```
> 
> On Ubuntu 24.04 there are also some new failures in `SizeToSceneTest ` with this PR, but several of the test fail anyway on 24.04

It always failing for me, with this PR or without.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2295445620

From rlichten at openjdk.org  Mon Aug 19 05:03:55 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Mon, 19 Aug 2024 05:03:55 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v3]
In-Reply-To: <zqRh1Wpi0bTAVrcar04jPPE16Hr31pnQvLMIeFE-RQo=.ee9bf9a0-11d0-4f9e-af96-67798864c163@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vllhPDbc7cQ5TVT0QIlMMmPxrX2oAzLJD1PlZdX_Cuo=.41c95533-d025-4d1f-b17a-bb40f5e95489@github.com>
 <zqRh1Wpi0bTAVrcar04jPPE16Hr31pnQvLMIeFE-RQo=.ee9bf9a0-11d0-4f9e-af96-67798864c163@github.com>
Message-ID: <_YEUoi0mqlyv2LMCdErmR16TBcPLBQ5r2NXkSV8K1c8=.2057eb4e-b15f-40fb-83aa-86b2625e6229@github.com>

On Wed, 14 Aug 2024 18:26:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/BasicTextModel.java line 198:
>> 
>>> 196:      */
>>> 197:     public static class InMemoryContent implements Content {
>>> 198:         private final ArrayList<String> paragraphs = new ArrayList<>();
>> 
>> Since paragraphs may be inserted anywhere, I would guess that using a LinkedList should be more efficient here. Otherwise, when adding a line break somewhere in the middle of a long text, a lot of array members must be copied.
>
> You are right, but this is just a default implementation.  you can still implement your own `BasicTextModel.Content` and pass it to the constructor.
> 
> Do you want to see an in-memory implementation optimized for large number of paragraphs or should it better be left up to the app developers?

Yes, we should definitely provide a very efficient implementation, because most app developers will not want to change it. We should definitely avoid another "TextArea situation", where the application breaks apart, if the text grows too big.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1721215337

From rlichten at openjdk.org  Mon Aug 19 05:07:56 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Mon, 19 Aug 2024 05:07:56 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v3]
In-Reply-To: <Bvzu3evzfdJqZ-GK33MNnSgO6e_yfNAqT6ldAVg8Y8g=.75dc747e-0217-41ff-839d-244534188a54@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com>
 <Bvzu3evzfdJqZ-GK33MNnSgO6e_yfNAqT6ldAVg8Y8g=.75dc747e-0217-41ff-839d-244534188a54@github.com>
Message-ID: <WNsk5UZa-8AWBNquSM1NH_8r7dxgRF5dck5vSnYcPog=.fb705267-d8c1-4ab6-a9f7-7aeb616bc883@github.com>

On Wed, 14 Aug 2024 18:33:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/manual/RichTextAreaDemo/src/com/oracle/demo/richtext/codearea/DemoSyntaxDecorator.java line 54:
>> 
>>> 52: 
>>> 53:     @Override
>>> 54:     public RichParagraph createRichParagraph(CodeTextModel model, int index) {
>> 
>> When implementing "real" syntax highlighting, the style of a paragraph will depend on the style of it's predecessors (e.g. multiline strings or multiline comments)...
>
> Correct, this is just a demo.
> 
> The information passed to the **SyntaxDecorator** interface should be sufficient to support any "real" syntax, at least I hope it is.  We are passing the model to each method, so it can re/construct the syntax or cache it as needed.

Consider this situation: When a user types some text into paragraph 2, it may change the styling in paragraph 2, 3, 4, ... 
Will the createRichParagraph - method be called for each paragraph after each typed character? That would probably be inefficient; On the other hand, if it is only called for the paragraph the user typed in, that may not be enough.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1721217128

From dlemmermann at gmail.com  Mon Aug 19 07:29:18 2024
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Mon, 19 Aug 2024 09:29:18 +0200
Subject: Label Text Selection
In-Reply-To: <4b55ee9b-cbc6-4652-9a41-afa3c4015569@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
 <4b55ee9b-cbc6-4652-9a41-afa3c4015569@gmail.com>
Message-ID: <3C41086B-D600-4346-8687-F38E6915212A@gmail.com>

That looks like a much better approach. We implemented the initial version of the selectable text control for JavaFX 8, so the whole hit point API wasn?t even there back then (or at least not public). I think I will move the control to use your approach ? which is probably what the TextArea is doing as well?

Dirk

> On 16 Aug 2024, at 17:40, quizynox <quizynox at gmail.com> wrote:
> 
> Hello,
> 
> Both TextFlow and Text support the HitInfo API, which makes getting selected characters very easy. Then you just need to wrap the selected characters in Path. The way it is implemented in GemsFX with overlay pane is quite complicated. Here is a rough sketch of the selectable TextFlow I plan to release in AtlantaFX. I think implementing a selectable Label by wrapping a text node in Region isn't much harder. But I wouldn't mind if it was the Label out-of-the-box feature, although I think it would require implementing some sort of selection model, so it's unlikely to happen.
> 
> source code:
> https://pastebin.com/9QKWYfx1
> 
> On 16/08/2024 14.12, Dirk Lemmermann wrote:
>> Hi everyone,
>> 
>> I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible?
>> 
>> I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.
>> 
>> Dirk
>> 


From jvos at openjdk.org  Mon Aug 19 07:31:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 19 Aug 2024 07:31:59 GMT
Subject: [jfx21u] Integrated: 8334657: Enable binary check
In-Reply-To: <mL_8GfMJzEvB812LwyCNNiwqpM-Wm-Q0aJ1140uyVxI=.7b106fad-e3af-4a8b-95a4-5d61b5871b56@github.com>
References: <mL_8GfMJzEvB812LwyCNNiwqpM-Wm-Q0aJ1140uyVxI=.7b106fad-e3af-4a8b-95a4-5d61b5871b56@github.com>
Message-ID: <g2eyjYl3Q47xn8gXoD5Q8EkuEhFOZ7SJ4Gbkq1O4Yw0=.6b7d1b47-16d4-4ed5-8826-5d680cd34566@github.com>

On Sun, 18 Aug 2024 20:46:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0fc3e512
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/0fc3e5124931c2b409bb961c20281ca497e7ae94
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8334657: Enable binary check
8334656: Enable issuestitle check

Reviewed-by: jpereda
Backport-of: 101e5175ff429828de25204bc3e5f216d383060b

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

PR: https://git.openjdk.org/jfx21u/pull/68

From jvos at openjdk.org  Mon Aug 19 07:47:57 2024
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 19 Aug 2024 07:47:57 GMT
Subject: [jfx17u] Integrated: 8334657: Enable binary check
In-Reply-To: <xXNvsotWErzMa-6BLoaDPwoGghSKLojCye-48dNwUgo=.0960befa-8c1e-4033-a7f3-6c14f8e92715@github.com>
References: <xXNvsotWErzMa-6BLoaDPwoGghSKLojCye-48dNwUgo=.0960befa-8c1e-4033-a7f3-6c14f8e92715@github.com>
Message-ID: <cXN1F1OQNl-Cr59zqiqeE7lY64IIHXlI-wKLEmN1xZw=.67369bf3-54a1-4b89-9492-1d662c8cb06f@github.com>

On Sun, 18 Aug 2024 20:37:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 101e5175 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Kevin Rushforth on 25 Jun 2024 and was reviewed by Ambarish Rapte and Phil Race.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0eef8544
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/0eef85446c0a31813cdc36ebe378b096a816c692
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8334657: Enable binary check
8334656: Enable issuestitle check

Reviewed-by: jpereda
Backport-of: 101e5175ff429828de25204bc3e5f216d383060b

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

PR: https://git.openjdk.org/jfx17u/pull/198

From mariushanl at web.de  Mon Aug 19 09:02:13 2024
From: mariushanl at web.de (Marius Hanl)
Date: Mon, 19 Aug 2024 11:02:13 +0200
Subject: Aw: Label Text Selection
In-Reply-To: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
Message-ID: <trinity-73509c63-f837-4402-ac38-0952c283e0c8-1724058133307@3c-app-webde-bap10>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240819/f184ad5e/attachment.htm>

From sykora at openjdk.org  Mon Aug 19 09:03:55 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Mon, 19 Aug 2024 09:03:55 GMT
Subject: RFR: 8336938: Update libFFI to 3.4.6 [v2]
In-Reply-To: <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
 <_TeCbCYVI53_qUmnJZVcp-EbmXN6Lc_bgx7xubyjovw=.3a14a0eb-9c96-4819-89aa-93af6ce42d61@github.com>
Message-ID: <9v24E6NZwM5NDwHPioWFVe_KVUEZQyDPdnz_mAIPeac=.5d3e54ee-9b75-41d3-978c-4e472b00b913@github.com>

On Tue, 13 Aug 2024 19:04:09 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - libFFI updated to 3.4.6.
>> - No additional changes are done.
>> - Tested on Windows, macOS and Linux with all supported formats.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336938: Update libFFI to 3.4.6 [v2]

All builds ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1531#pullrequestreview-2244997338

From jvos at openjdk.org  Mon Aug 19 12:55:05 2024
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 19 Aug 2024 12:55:05 GMT
Subject: [jfx23u] Integrated: 8334874: Horizontal scroll events from touch pads
 should scroll the TabPane tabs
In-Reply-To: <Kc9SdbmlFsJHKtSJ0Bnoze05bWQXoDf-eHp5KV841cE=.c504b7b7-15d9-4049-8510-77a1b10e44df@github.com>
References: <Kc9SdbmlFsJHKtSJ0Bnoze05bWQXoDf-eHp5KV841cE=.c504b7b7-15d9-4049-8510-77a1b10e44df@github.com>
Message-ID: <R5xrMEJ1mDz8mZm66UWYVkEgQ-XTA9D_uJkNh1S_YY4=.5aa945cc-317a-4980-acc0-62cf1e9743fc@github.com>

On Sun, 18 Aug 2024 20:36:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1bdb93c7](https://github.com/openjdk/jfx/commit/1bdb93c792cf7c218c74ec5cacda8bac1242f73b) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Jose Pereda on 25 Jul 2024 and was reviewed by Andy Goryachev and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b8a7a68e
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/b8a7a68eb6b7a0cef31f7ac672b903081fcba79c
Stats:     111 lines in 2 files changed: 107 ins; 0 del; 4 mod

8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs

Backport-of: 1bdb93c792cf7c218c74ec5cacda8bac1242f73b

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

PR: https://git.openjdk.org/jfx23u/pull/8

From jvos at openjdk.org  Mon Aug 19 13:02:59 2024
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 19 Aug 2024 13:02:59 GMT
Subject: [jfx23u] Integrated: 8319779: SystemMenu: memory leak due to listener
 never being removed
In-Reply-To: <RtC6i2J-JVRMsqZehJ7ZqIH6br9L2JZ3l6FhR3jnjD0=.316c480f-06f9-416b-ab33-39f061bb2d59@github.com>
References: <RtC6i2J-JVRMsqZehJ7ZqIH6br9L2JZ3l6FhR3jnjD0=.316c480f-06f9-416b-ab33-39f061bb2d59@github.com>
Message-ID: <N939fqHwYT_Fql3uAVxOWCDqSF-AQfNf05br9RRoNgM=.825d209d-77ae-477d-a66b-75b0ab6d3c7e@github.com>

On Sun, 18 Aug 2024 20:46:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 25ac6fed from the openjdk/jfx repository.
> 
> The commit being backported was authored by Johan Vos on 25 Jul 2024 and was reviewed by John Hendrikx, Ambarish Rapte and Jose Pereda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cdc3c300
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/cdc3c3005405fe02e7fd3108b463759cb31f318a
Stats:     663 lines in 5 files changed: 462 ins; 192 del; 9 mod

8319779: SystemMenu: memory leak due to listener never being removed
8323787: Mac System MenuBar throws IOB exception

Backport-of: 25ac6fed22d0f49d01c831aaa48049c34899fe96

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

PR: https://git.openjdk.org/jfx23u/pull/9

From kcr at openjdk.org  Mon Aug 19 13:44:57 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 Aug 2024 13:44:57 GMT
Subject: RFR: 8338478: [macos] Crash in CoreText with certain strings using
 JDK 22 or later
In-Reply-To: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
References: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
Message-ID: <z4NEDIIHDD4ku8MSl73LLNdSI1sFVTnZsUAwvKaP29Y=.3fab18a4-1d77-44ee-8d78-05fe7134c3f7@github.com>

On Sat, 17 Aug 2024 21:02:59 GMT, Phil Race <prr at openjdk.org> wrote:

> The test in the bug report crashes reliably with JDK 22 on retina.
> It coincides with an update to the macOS compilers which seem likely to eagerly invalidate the target of a CFRelease on the native CTFontRef.
> Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until after the method has finished using the native fontRef from the strike fixes it.
> The same pattern is observed in 3 other methods (although no crash)  and a fence is added there too.
> 
> There is an existing test, which is how this problem was found.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1537#issuecomment-2296611621

From kcr at openjdk.org  Mon Aug 19 13:48:58 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 Aug 2024 13:48:58 GMT
Subject: RFR: 8338478: [macos] Crash in CoreText with certain strings using
 JDK 22 or later
In-Reply-To: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
References: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
Message-ID: <trPFa1YPr0ueUMyf1HigSb58D6l5kuT1zbFDXsTWxPY=.09ae7a0c-5988-4a6f-862b-4b3594be01fa@github.com>

On Sat, 17 Aug 2024 21:02:59 GMT, Phil Race <prr at openjdk.org> wrote:

> The test in the bug report crashes reliably with JDK 22 on retina.
> It coincides with an update to the macOS compilers which seem likely to eagerly invalidate the target of a CFRelease on the native CTFontRef.
> Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until after the method has finished using the native fontRef from the strike fixes it.
> The same pattern is observed in 3 other methods (although no crash)  and a fence is added there too.
> 
> There is an existing test, which is how this problem was found.

The code changes look good.

All my testing is as expected: PangoTest fails (crashes) without the fix and passes with the fix on my M1 running macOS 14.5. The CoreTextCrash program attached to the JBS bug crashes without the fix and passes with the fix on both my M1 and on my Intel Mac running macOS 13.6.9.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1537#pullrequestreview-2245598099

From arapte at openjdk.org  Mon Aug 19 14:23:56 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 19 Aug 2024 14:23:56 GMT
Subject: RFR: 8338478: [macos] Crash in CoreText with certain strings using
 JDK 22 or later
In-Reply-To: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
References: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
Message-ID: <IcPPFroOP_KpDW7WSXDT1Na36eycfdQgJTczY3I-aU8=.07352851-341b-4c9b-8e04-ee614e9e2c68@github.com>

On Sat, 17 Aug 2024 21:02:59 GMT, Phil Race <prr at openjdk.org> wrote:

> The test in the bug report crashes reliably with JDK 22 on retina.
> It coincides with an update to the macOS compilers which seem likely to eagerly invalidate the target of a CFRelease on the native CTFontRef.
> Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until after the method has finished using the native fontRef from the strike fixes it.
> The same pattern is observed in 3 other methods (although no crash)  and a fence is added there too.
> 
> There is an existing test, which is how this problem was found.

Fix looks good. The test fails without this change and passes with the fix, tested with intel Mac, Sonoma 14.5

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1537#pullrequestreview-2245689472

From angorya at openjdk.org  Mon Aug 19 16:21:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 Aug 2024 16:21:56 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v3]
In-Reply-To: <WNsk5UZa-8AWBNquSM1NH_8r7dxgRF5dck5vSnYcPog=.fb705267-d8c1-4ab6-a9f7-7aeb616bc883@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <-WhEo5SNaDtEPHLJd_1ErFogQeAJ-sbJ1kxiPliYbDk=.1fac7bc2-fb5f-4d59-a35c-b352cfad1549@github.com>
 <Bvzu3evzfdJqZ-GK33MNnSgO6e_yfNAqT6ldAVg8Y8g=.75dc747e-0217-41ff-839d-244534188a54@github.com>
 <WNsk5UZa-8AWBNquSM1NH_8r7dxgRF5dck5vSnYcPog=.fb705267-d8c1-4ab6-a9f7-7aeb616bc883@github.com>
Message-ID: <7d6Zn-bthmPOq_jz91h2cQDjicNwmcKl4B1v3_Ai5y0=.debc7a17-013f-46ef-a5e2-a2e24528578d@github.com>

On Mon, 19 Aug 2024 05:05:08 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> Correct, this is just a demo.
>> 
>> The information passed to the **SyntaxDecorator** interface should be sufficient to support any "real" syntax, at least I hope it is.  We are passing the model to each method, so it can re/construct the syntax or cache it as needed.
>
> Consider this situation: When a user types some text into paragraph 2, it may change the styling in paragraph 2, 3, 4, ... 
> Will the createRichParagraph - method be called for each paragraph after each typed character? That would probably be inefficient; On the other hand, if it is only called for the paragraph the user typed in, that may not be enough.

In this case the model fires a change event which defines the affected area.  The view (the skin) determines which visible elements need to be updated, by calling StyledTextModel::getParagraph().

I don't think there will be efficiency issues because
1. these visuals are likely to be updated anyway
2. the number of requested paragraphs is limited by the size of the sliding window (i.e. screen size + some margin)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1722047884

From hmeda at openjdk.org  Mon Aug 19 16:32:22 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 19 Aug 2024 16:32:22 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1
Message-ID: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>

This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen

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

Commit messages:
 - Resolve DragandDrop issue

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

PR: https://git.openjdk.org/jfx/pull/1538

From angorya at openjdk.org  Mon Aug 19 16:33:03 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 Aug 2024 16:33:03 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v3]
In-Reply-To: <_YEUoi0mqlyv2LMCdErmR16TBcPLBQ5r2NXkSV8K1c8=.2057eb4e-b15f-40fb-83aa-86b2625e6229@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <vllhPDbc7cQ5TVT0QIlMMmPxrX2oAzLJD1PlZdX_Cuo=.41c95533-d025-4d1f-b17a-bb40f5e95489@github.com>
 <zqRh1Wpi0bTAVrcar04jPPE16Hr31pnQvLMIeFE-RQo=.ee9bf9a0-11d0-4f9e-af96-67798864c163@github.com>
 <_YEUoi0mqlyv2LMCdErmR16TBcPLBQ5r2NXkSV8K1c8=.2057eb4e-b15f-40fb-83aa-86b2625e6229@github.com>
Message-ID: <mG2PsF_gsWD-7aMQe-fTO0DpLlOYMAqhAgG4G89YVBk=.ec120622-4310-41d1-b9bb-5cc3c7ae49d8@github.com>

On Mon, 19 Aug 2024 05:01:13 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> You are right, but this is just a default implementation.  you can still implement your own `BasicTextModel.Content` and pass it to the constructor.
>> 
>> Do you want to see an in-memory implementation optimized for large number of paragraphs or should it better be left up to the app developers?
>
> Yes, we should definitely provide a very efficient implementation, because most app developers will not want to change it. We should definitely avoid another "TextArea situation", where the application breaks apart, if the text grows too big.

I am strongly against `LinkedList` here: not only it adds 2 pointers to each element, but mostly because it provides no random access.

ArrayList should be sufficient for simple cases, and the developers are free to implement a better Content _for their use case_.  Maybe it's a skip list, or BPlusTree, or something else.

I would also like to mention that the performance issue with TextArea is not the storage (at least it is not the first order issue), but the fact that it renders all the text (in a single Text node).  RTA renders only the sliding window, which should be much faster.  Of course, RTA will have issues with very long paragraphs, but that's a different story (and is mentioned in the Non-Goals section)

https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md#non-goals

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1722060389

From angorya at openjdk.org  Mon Aug 19 16:35:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 Aug 2024 16:35:02 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <XiqyxBylC1tdYeLT_NVnDHkS6wBXwVUn7tiFwRBlZrw=.dd52fcb9-503d-4484-a6ee-b461a406a374@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
 <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>
 <XiqyxBylC1tdYeLT_NVnDHkS6wBXwVUn7tiFwRBlZrw=.dd52fcb9-503d-4484-a6ee-b461a406a374@github.com>
Message-ID: <ri9SFUBbOW8TU_sK1gbO8kd3i0Af7TazOYzySHrbvFk=.a9138b55-a26f-4acf-b6f8-5928895d2e90@github.com>

On Sun, 18 Aug 2024 21:33:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> I tested on both XWayland and Xorg. They are never negative.
>> 
>> The input method window did always pop up on the right place.
>> 
>> ![image](https://github.com/user-attachments/assets/05568b82-3602-48d0-acf1-65aabc8a316b)
>> 
>> ![image](https://github.com/user-attachments/assets/14d29bc3-9e57-47c3-b573-f08871306c69)
>
> Interesting. I just did a quick test on the Mac and verified that either coordinate can go negative. There must be a difference in the way the platform's model multiple monitors.

on mac and windows the coordinates can be negative, depending on the screen arrangement.

why do we need to rely on the fact that `pos[]` values are positive anyway?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1722063195

From hmeda at openjdk.org  Mon Aug 19 17:02:06 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 19 Aug 2024 17:02:06 GMT
Subject: [jfx23u] Integrated: 8336941: Update libxslt to 1.1.42
Message-ID: <g9aIKf8HfN1mUntKM2SSiglBuLG6TYd-92UhPps1Jdo=.7c825427-2bee-4b56-839a-83b22e083c5c@github.com>

Clean Backport

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

Commit messages:
 - Backport dc8f607e4ce95e348bb812a1c942e4321c00f0f8

Changes: https://git.openjdk.org/jfx23u/pull/10/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=10&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336941
  Stats: 478 lines in 19 files changed: 111 ins; 316 del; 51 mod
  Patch: https://git.openjdk.org/jfx23u/pull/10.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/10/head:pull/10

PR: https://git.openjdk.org/jfx23u/pull/10

From hmeda at openjdk.org  Mon Aug 19 17:02:06 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 19 Aug 2024 17:02:06 GMT
Subject: [jfx23u] Integrated: 8336941: Update libxslt to 1.1.42
In-Reply-To: <g9aIKf8HfN1mUntKM2SSiglBuLG6TYd-92UhPps1Jdo=.7c825427-2bee-4b56-839a-83b22e083c5c@github.com>
References: <g9aIKf8HfN1mUntKM2SSiglBuLG6TYd-92UhPps1Jdo=.7c825427-2bee-4b56-839a-83b22e083c5c@github.com>
Message-ID: <S69Ld75_90nzH0oBn-KokofDTUOGGuEoe-qpLVPk_Q0=.fa1fcf7c-7632-465b-ad25-b6caac3aef7e@github.com>

On Mon, 19 Aug 2024 16:55:46 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 48853242
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/48853242735bc08c909eb0cb0a68a08ec50f7109
Stats:     478 lines in 19 files changed: 111 ins; 316 del; 51 mod

8336941: Update libxslt to 1.1.42

Backport-of: dc8f607e4ce95e348bb812a1c942e4321c00f0f8

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

PR: https://git.openjdk.org/jfx23u/pull/10

From mfox at openjdk.org  Mon Aug 19 17:42:00 2024
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 19 Aug 2024 17:42:00 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <ri9SFUBbOW8TU_sK1gbO8kd3i0Af7TazOYzySHrbvFk=.a9138b55-a26f-4acf-b6f8-5928895d2e90@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
 <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>
 <XiqyxBylC1tdYeLT_NVnDHkS6wBXwVUn7tiFwRBlZrw=.dd52fcb9-503d-4484-a6ee-b461a406a374@github.com>
 <ri9SFUBbOW8TU_sK1gbO8kd3i0Af7TazOYzySHrbvFk=.a9138b55-a26f-4acf-b6f8-5928895d2e90@github.com>
Message-ID: <AoaBb1Z_1_qsKNES4wvjk2TgqWbjmX6FSho4yV5ViNM=.c592d37e-7f6a-4224-ac30-be7ba55c4631@github.com>

On Mon, 19 Aug 2024 16:32:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Interesting. I just did a quick test on the Mac and verified that either coordinate can go negative. There must be a difference in the way the platform's model multiple monitors.
>
> on mac and windows the coordinates can be negative, depending on the screen arrangement.
> 
> why do we need to rely on the fact that `pos[]` values are positive anyway?

I was able to set up a multiple monitor system. Linux does work differently than Mac or Windows but the X coordinate returned by View can still be negative if the window is partially off the left edge of the leftmost screen. But in that case the Window's X coordinate will also be negative so subtracting it out will generate the correct widget-relative location. So I suggest removing the conditional checks here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1722137039

From kcr at openjdk.org  Mon Aug 19 18:15:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 Aug 2024 18:15:53 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1
In-Reply-To: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
Message-ID: <1a3qYrcpgagvH1m9DirH8jmsfl-QUAULrAIPO7EVzvw=.5fa687fe-5d74-4822-9563-4574d6262713@github.com>

On Mon, 19 Aug 2024 09:32:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen

Reviewers: @kevinrushforth and @tiainen or @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1538#issuecomment-2297152982

From kcr at openjdk.org  Mon Aug 19 18:21:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 19 Aug 2024 18:21:53 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1
In-Reply-To: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
Message-ID: <elYHF-qqOJXcJKNhhyqg68rs4jf1fgrsktojt7VdCoo=.b5692c11-79ba-482f-9380-b9d6ba119be9@github.com>

On Mon, 19 Aug 2024 09:32:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen

The fix works as expected. I confirm that Drag and Drop fails without the fix and works with the fix.

I left a suggestion and a question inline.

One other question: what was the root cause of this bug? Did WebKit recently change how the different DnD-related events are delivered?

modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/WebPage.cpp line 2254:

> 2252:             return 0;
> 2253:         case com_sun_webkit_WebPage_DND_DST_ENTER:
> 2254:             return dragOperationToDragCursor(std::get<std::optional<WebCore::DragOperation>>(dc.dragEnteredOrUpdated(*localMainFrame, WTFMove(dragData))));

This is identical to the body of the two cases below. It might be clearer to remove this return statement (line 2254) to avoid duplication.

Speaking of which, I presume that it is intentional to call `dragOperationToDragCursor` for all three of `DND_DST_ENTER`, `DND_DST_OVER`, and `DND_DST_CHANGE`?

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

PR Review: https://git.openjdk.org/jfx/pull/1538#pullrequestreview-2246176080
PR Comment: https://git.openjdk.org/jfx/pull/1538#issuecomment-2297165053
PR Review Comment: https://git.openjdk.org/jfx/pull/1538#discussion_r1722174148

From prr at openjdk.org  Mon Aug 19 19:21:58 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 19 Aug 2024 19:21:58 GMT
Subject: Integrated: 8338478: [macos] Crash in CoreText with certain strings
 using JDK 22 or later
In-Reply-To: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
References: <5kmEXw01pr4S0tgDhIQ7sP6vkD9WJdjbzwrDLvZe11Y=.59c7f0e1-7e81-4edb-9602-1f0ea70688ae@github.com>
Message-ID: <nkARTXq3OhguLH8636z0PoK2wVPzkIMBo1dJdap9hLw=.87b67334-edc4-4a95-b044-37348b81ee48@github.com>

On Sat, 17 Aug 2024 21:02:59 GMT, Phil Race <prr at openjdk.org> wrote:

> The test in the bug report crashes reliably with JDK 22 on retina.
> It coincides with an update to the macOS compilers which seem likely to eagerly invalidate the target of a CFRelease on the native CTFontRef.
> Adding a ReachabilityFence to prevent the GC from collecting CTFontStrike until after the method has finished using the native fontRef from the strike fixes it.
> The same pattern is observed in 3 other methods (although no crash)  and a fence is added there too.
> 
> There is an existing test, which is how this problem was found.

This pull request has now been integrated.

Changeset: 269d6897
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/269d6897e4d4e62beff3a2179dcdabe8a0bf0bc7
Stats:     87 lines in 1 file changed: 32 ins; 14 del; 41 mod

8338478: [macos] Crash in CoreText with certain strings using JDK 22 or later

Reviewed-by: kcr, arapte

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

PR: https://git.openjdk.org/jfx/pull/1537

From mhanl at openjdk.org  Mon Aug 19 19:33:52 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 19 Aug 2024 19:33:52 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <CVZNRIaPNxqtSeEX77lcq6cmOkgu5Zt7iS5pkh9ui3c=.d70c331c-4ed5-49a0-b6fb-c57c1c3e8982@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
 <ctMoosdsyoSZ3wdOxPKri-nfRYOTgfpVLWJmCjGvLPw=.ab3f9ba1-d588-4c39-b9ef-ebf0a924f293@github.com>
 <CVZNRIaPNxqtSeEX77lcq6cmOkgu5Zt7iS5pkh9ui3c=.d70c331c-4ed5-49a0-b6fb-c57c1c3e8982@github.com>
Message-ID: <Qs0maYpPJnfGry4L4gN_UPwz6mFWWqBGgsD5ujXo2HM=.d77d00de-6ba8-4846-9c4d-a8c2959c69c1@github.com>

On Mon, 19 Aug 2024 00:06:07 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> It always failing for me, with this PR or without.

Since I wrote them, maybe we can fix those tests for you as well and make them more stable across Linux.
I think generally those tests are good to have as they can catch serious issues when it comes to stage showing and sizing. But they should be as stable as they can be.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2297294544

From tsayao at openjdk.org  Mon Aug 19 20:03:53 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 19 Aug 2024 20:03:53 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <FqzVtKK4KQ4ye7J2YFs6KKFEtZvT3fFZxNIJmFlzNDU=.4c337184-b0e9-4769-8b95-ae1df5ae11ae@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

The problem is that on Ubuntu 24.04 with Xorg (aparrently does not affect XWayland - but not sure if it's true on all scenarios) there's an extra configure event that causes problems. For example, if the window is set to begin fullscreen it will go back to floating (because of this event) and the size test will fail.

It's something non-obvious that is causing this, problably.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2297345736

From almatvee at openjdk.org  Mon Aug 19 22:06:52 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 19 Aug 2024 22:06:52 GMT
Subject: Integrated: 8336938: Update libFFI to 3.4.6
In-Reply-To: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
References: <KSznac8byk1rj1jE5ExE-Inyuk8oUdgccbL2ZqXYMPg=.d2e7f5b8-009e-4032-bdd5-a3713ca66ec4@github.com>
Message-ID: <aWMPVhOK4F012Xh5XwhV7wWUOpQAwp9yJ8gBU39XaUQ=.3c9c20ad-f438-4f85-be13-4905108fd0f3@github.com>

On Wed, 7 Aug 2024 00:26:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - libFFI updated to 3.4.6.
> - No additional changes are done.
> - Tested on Windows, macOS and Linux with all supported formats.

This pull request has now been integrated.

Changeset: f1bac5a8
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f1bac5a829e1f2b75b863c4f0822bf418107a1fb
Stats:     1056 lines in 26 files changed: 388 ins; 373 del; 295 mod

8336938: Update libFFI to 3.4.6

Reviewed-by: kcr, sykora

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

PR: https://git.openjdk.org/jfx/pull/1531

From arapte at openjdk.org  Tue Aug 20 03:08:29 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 Aug 2024 03:08:29 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
Message-ID: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>

Gradle 8.8 released on May 31, 2024, supports JDK 22.
On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 

This gradle update is required in order to update the boot jdk to 22.0.2.
The changes are minimal, no source code changes were required.

This PR also includes the boot jdk update.

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

Commit messages:
 - chmod 644 gradlew
 - gradle 89, jdk 2202
 - revert gradle-wrapper.properties partially
 - gradle 8.9

Changes: https://git.openjdk.org/jfx/pull/1539/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1539&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336632
  Stats: 32 lines in 7 files changed: 5 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jfx/pull/1539.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1539/head:pull/1539

PR: https://git.openjdk.org/jfx/pull/1539

From kneester77 at gmail.com  Tue Aug 20 03:19:37 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Mon, 19 Aug 2024 20:19:37 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
Message-ID: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>

This is my first time attempting to submit a feature request so bear with
me if I mess up the instructions, I'll do my best to rectify any issues if
they occur and are pointed out.

*Feature Proposal:* Vertex Colors on TriangleMesh
Add a new ObservableIntegerArray to TriangleMesh which contains vertex
colors in ARGB8888 integer format. (I'm open to the pixel format being
flexible too, but this may be unnecessary).
Operation of this array should be the same as the other mesh arrays, in the
sense that the VertexFormat object configures how they should operate.
Similarly to how normals currently work, the array is optional, and may not
necessarily need to be included.
Additionally, the face array will also work the same as usual, where the
new color indices will be specified on a per-face-vertex basis. (Each
vertex of each face will have an index specified)
If the array is present/valid, the colors should be multiplied by 2x the
diffuse/selfIllumination/specular textures when calculating the FragColor.
(Clamp the color to the maximum color value of 1.0 when done)
The reason we multiply by two is to allow the vertex colors to create color
components larger than what was seen in the texture. So for example, a blue
component of .75 will result in 1.5x the blue value from the material
texture.
This is the standard way of calculating vertex colors when there is a
texture as I understand. If there were no texture, it would not be
multiplied by 2.0
The rasterization process should be responsible for interpolation colors,
as seen in my examples below.

Example without feature:
https://i.imgur.com/Hg81LtU.png


Example with feature:
Notice how the lava stream & pipes are the same texture repeated many
times, but once the vertex coloring feature is used it becomes
significantly less apparent.
It can also be used to add details like the rust on various
metal surfaces, or how the lava fades to black towards the edges. JavaFX
doesn't contain the appropriate tools to render this scene, but pretty much
any other 3D library does.




*Why adding this API to the core of JavaFX is a positive/useful addition
for different applications.*Vertex coloring is a core 3D rendering feature
supported by virtually every other 3D rendering system on the planet. It
works on low-end systems, and has been part of 3D rendering since the
beginning.
This is true whether the 3D rendering library is high-level (SGI
OpenInventor, Java3D, jmonkeyengine, etc), low-level (DirectX, Metal,
Vulkan, OpenGL), or somewhere in-between (Unreal Engine, Unity, Blender,
etc).
The only library I could even find which did not support this was JavaFX.

But, just because everyone else does it doesn't mean JavaFX should, right?
Well, I'd actually like to argue that it should. If JavaFX wants to be
reasonably compatible/interoperable with virtually any other 3D format,
application, or tool, it needs to support this.
Any tool with the capability of importing/exporting 3D models has only one
for displaying vertex coloring right now: to generate their own texture
sheet with vertex color shading baked in on a per-face basis.
This can be a pretty slow process when there are a lot of different faces,
since every single face with even a single polygon with a slightly
different texture coordinate will need a new texture on the texture sheet.
The above screenshot I've shown requires a 4096x4096 texture sheet in order
to render in JavaFX, and it's a pretty small scene! I've got significantly
larger scenes which I'm completely unable to render with shading because I
need to generate a texture sheet more than a gigabyte large in order to
shade it properly.
And forget about any kind of common texCoord/UV animations. The CPU needs
to be constantly redrawing shading textures onto the texture sheet in order
to ensure animations have the correct shading.
For the above example, trying to animate the lava to flow down the screen
as it's supposed to brings my FPS below 30.
This is despite the texture drawing process having run in parallel and
extensive performance profiling on my part. I've concluded there's no way
to get around having proper vertex color support as the main bottleneck is
just sending such a massively large image to the GPU so frequently as well
as having to actually shade the images still taking a pretty decent amount
of time even when done in parallel. And remember, these performance issues
are happening on one of my small scenes.

Normally drawing vertex colors like this is extremely fast (even on 30 year
old hardware!) when done by the GPU/dedicated hardware, but JavaFX just
doesn't provide a way to do it with the GPU.
JavaFX is also the only mainstream 3D library I could find which lacks this
feature.
There are 3D environments I cannot even display with shading right now at
all due to the sheer amount of large textures that need to have shading
manually drawn onto them.
This cannot be solved by using a project like Fxyz
<https://github.com/FXyz/FXyz>, since it just comes down to the texture
sheets being too large.
These scenes aren't even particularly large either, having been made for
game consoles in the range of 20-30 years ago.

This will happen to anyone who needs to use vertex coloring with a
significant number of textures, and requires writing a lot of code to
manage texture sheets to ultimately just for it to only partially suffice.

There are other reasons to want vertex coloring outside of compatibility
with other software too.
Vertex coloring can often be used to add significant mesh details.
In the above example, I've already demonstrated how this can be used to add
details such as rust, fade-outs, etc. But there are many more ways to
include it too, such as using art styles with flat textures, such as for
clouds, cartoon art-styles, etc. It's even possible to create shadows by
using darker colors in areas obscured by others. There are so many clever
ways this can be used, and I'd spend too much time on individual examples.
The reason vertex colors have been so prevalent is specifically because of
the payoff between how easy they are to add and how much can be achieved
with them.
I'm not enough of an artist to explain everything with words, but I can
certainly give a lot of examples via screenshot, if desired.

Since the guideline was to tailor this pitch to the JavaFX community, I
thought I'd include mention of a few JavaFX projects that I thought would
benefit significantly. There were others that would benefit in less
significant ways, so I tried to keep it brief:
 - Fxyz <https://github.com/FXyz/FXyz>: Probably the most popular JavaFX 3D
project.
 - GameExtractor <https://github.com/wattostudios/GameExtractor/>: Capable
of showing 3D objects in many common formats (.obj, .3ds, Unity Format,
Unreal Engine 2/3 Format, etc), but is unable to show vertex colors due to
JavaFX's lack of support.
-  FrogLord <https://github.com/Kneesnap/FrogLord>: This is my project, but
every single game I support desperately needs this feature in order to
accurately preview the custom levels as they are edited, so the user can
see how they will appear in their game.

Pretty much any project which creates texture sheets containing
interpolated colors will benefit from this change as in many cases they
won't need to do that anymore.
Due to the reduced time and memory usage it will also become significantly
more feasible/performant to use meshes which change over time as well,
since fewer changes to the texture sheet will be required, if any at all.

I also imagine this fitting in very easily with the existing API, as pretty
much all of the public facing APIs could just have a few new methods in
them, without needing to change any pre-existing APIs at all.

In summary,
Vertex colors are a feature as ubiquitous in the 3D world as texture
coordinates, lighting, and materials, yet JavaFX doesn't have them.
Adding them will allow for a significant amount of detail for virtually no
performance or maintenance cost, and for some projects it will even improve
performance & simplify texture sheets.

Additional Note:
https://bugs.openjdk.org/browse/JDK-6586559
It looks like this feature may have already been planned at one point, but
was forgotten due to being low-priority? I don't know.

What does everyone think about this proposal? I eagerly await responses!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240819/921091b8/attachment-0001.htm>

From kcr at openjdk.org  Tue Aug 20 11:53:56 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 11:53:56 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <3lucsT81zLfOjlZjDSjX8wxq815zy1xst5SGWvQcgWQ=.14ac4664-e8f5-44d7-ba38-eec26a85ebda@github.com>

On Tue, 20 Aug 2024 02:59:00 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1539#issuecomment-2298668734

From kcr at openjdk.org  Tue Aug 20 12:05:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 12:05:54 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <N2LARysM9ibWAdHSIET8wvmh0QhDsKetvJEK1o1e69w=.3e98b4c6-0fc8-4ef2-9707-b6905006bf92@github.com>

On Tue, 20 Aug 2024 02:59:00 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

The gradle update looks good. You missed updating the boot JDK for Windows in the GHA build. Also, can you merge in the latest master?

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

PR Comment: https://git.openjdk.org/jfx/pull/1539#issuecomment-2298690438

From nlisker at openjdk.org  Tue Aug 20 13:44:54 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 20 Aug 2024 13:44:54 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <wX4sqNLRsJLelMqs1GHbuE5Te0QNOdfqcb9W7gUyHls=.7ec3632f-56a3-4f44-a4a3-82dde565c5e6@github.com>

On Tue, 20 Aug 2024 02:59:00 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

A few days ago I tested 8.9 and it worked well.

I would suggested in another PR to have a single constant with the Java version and not updated 12 places to the same version.

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

PR Comment: https://git.openjdk.org/jfx/pull/1539#issuecomment-2298895203

From hmeda at openjdk.org  Tue Aug 20 14:04:29 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 20 Aug 2024 14:04:29 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1 [v2]
In-Reply-To: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
Message-ID: <MC16lW-yT3kKO_Xtwvbh3rWyeLyj_5ezQdyjp5zesjI=.2d0aafb6-825b-4682-a907-573e9f7be9c5@github.com>

> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate call

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1538/files
  - new: https://git.openjdk.org/jfx/pull/1538/files/4a127528..7ef15ec2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1538&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1538&range=00-01

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

PR: https://git.openjdk.org/jfx/pull/1538

From hmeda at openjdk.org  Tue Aug 20 14:04:29 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 20 Aug 2024 14:04:29 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1 [v2]
In-Reply-To: <elYHF-qqOJXcJKNhhyqg68rs4jf1fgrsktojt7VdCoo=.b5692c11-79ba-482f-9380-b9d6ba119be9@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
 <elYHF-qqOJXcJKNhhyqg68rs4jf1fgrsktojt7VdCoo=.b5692c11-79ba-482f-9380-b9d6ba119be9@github.com>
Message-ID: <uGaaKfs-1muJNjCK-DNlVeOSnylhEBR-KHb5lsWSbEo=.d991dff4-5069-4c21-94b8-5ab4b49a0b82@github.com>

On Mon, 19 Aug 2024 18:14:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate call
>
> modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/WebPage.cpp line 2254:
> 
>> 2252:             return 0;
>> 2253:         case com_sun_webkit_WebPage_DND_DST_ENTER:
>> 2254:             return dragOperationToDragCursor(std::get<std::optional<WebCore::DragOperation>>(dc.dragEnteredOrUpdated(*localMainFrame, WTFMove(dragData))));
> 
> This is identical to the body of the two cases below. It might be clearer to remove this return statement (line 2254) to avoid duplication.
> 
> Speaking of which, I presume that it is intentional to call `dragOperationToDragCursor` for all three of `DND_DST_ENTER`, `DND_DST_OVER`, and `DND_DST_CHANGE`?

Yes, removed the duplicate call. In webkit-617.1, there were  calls to **dragEntered**  and **dragUpdated** for DND calls as follows:

      ` case com_sun_webkit_WebPage_DND_DST_ENTER:
            return dragOperationToDragCursor(dc.dragEntered(WTFMove(dragData)));`

       `case com_sun_webkit_WebPage_DND_DST_OVER:
        case com_sun_webkit_WebPage_DND_DST_CHANGE:
            return dragOperationToDragCursor(dc.dragUpdated(WTFMove(dragData)));`

In the current webkit-619.1 update, there has been refactoring and the apis **dragEntered**  and **dragUpdated** have been removed and instead **dragEnteredOrUpdated** has been used.  For our JAVA port adaptation, these changes have been missed and hence, the issue is observed. This fix addresses the issue.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1538#discussion_r1723371767

From dlemmermann at gmail.com  Tue Aug 20 14:09:03 2024
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Tue, 20 Aug 2024 16:09:03 +0200
Subject: Label Text Selection
In-Reply-To: <trinity-73509c63-f837-4402-ac38-0952c283e0c8-1724058133307@3c-app-webde-bap10>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
 <trinity-73509c63-f837-4402-ac38-0952c283e0c8-1724058133307@3c-app-webde-bap10>
Message-ID: <B01096D6-739D-4C24-9BB2-46D4B0AA0DFE@gmail.com>

I have taken quizynox approach and used it for the TextView control in GemsFX. After some additions the control now supports a text selection behaviour similar to the one found in TextArea (ctrl-c, ctrl-a, stylable ?highlight? properties, double click for word selection, triple click for paragraph selection, etc?). 

Dirk


> On 19 Aug 2024, at 11:02, Marius Hanl <mariushanl at web.de> wrote:
> 
> I also think this might be a good addition to the JFX Core.
> This behavior should be off by default, but can be turned on via CSS or Code.
> Another idea could be a new Control that extends from Label.
>  
> -- Marius
>  
>  
> Gesendet: Freitag, 16. August 2024 um 12:12 Uhr
> Von: "Dirk Lemmermann" <dlemmermann at gmail.com>
> An: "openjfx-dev" <openjfx-dev at openjdk.org>
> Betreff: Label Text Selection
> Hi everyone,
> 
> I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible?
> 
> I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.
> 
> Dirk
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/e7a60b53/attachment.htm>

From kcr at openjdk.org  Tue Aug 20 15:15:57 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 15:15:57 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1 [v2]
In-Reply-To: <MC16lW-yT3kKO_Xtwvbh3rWyeLyj_5ezQdyjp5zesjI=.2d0aafb6-825b-4682-a907-573e9f7be9c5@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
 <MC16lW-yT3kKO_Xtwvbh3rWyeLyj_5ezQdyjp5zesjI=.2d0aafb6-825b-4682-a907-573e9f7be9c5@github.com>
Message-ID: <txfNYQrxpSs05EsA7Q9u_vzyYHSvy3Dmd0k3HKwXU0M=.4531aa35-a66b-44a4-888a-5dcc9e14a37c@github.com>

On Tue, 20 Aug 2024 14:04:29 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate call

Thanks for the explanation. The updated fix looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1538#pullrequestreview-2248306055

From arapte at openjdk.org  Tue Aug 20 16:47:40 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 Aug 2024 16:47:40 GMT
Subject: RFR: 8336632: Update Gradle to 8.9 [v2]
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <dDB87HYKrkZ07Msun_8KUr5ALSm3r5DhejHdM2TbwvA=.696e0bab-1f7f-40bb-8a44-ed85c5281b64@github.com>

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  win bootjdk gha

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1539/files
  - new: https://git.openjdk.org/jfx/pull/1539/files/5f140034..a0715c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1539&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1539&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1539.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1539/head:pull/1539

PR: https://git.openjdk.org/jfx/pull/1539

From arapte at openjdk.org  Tue Aug 20 16:53:09 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 Aug 2024 16:53:09 GMT
Subject: RFR: 8336632: Update Gradle to 8.9 [v3]
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <p3DmtQepGkZv8A9khhgBt97OjZw8lxC9GfxghRGb-DM=.bd443eaf-f987-4b73-bb68-5f251b961609@github.com>

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

Ambarish Rapte has updated the pull request 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. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into gradle89-jdk2202
 - win bootjdk gha
 - chmod 644 gradlew
 - gradle 89, jdk 2202
 - revert gradle-wrapper.properties partially
 - gradle 8.9

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1539/files
  - new: https://git.openjdk.org/jfx/pull/1539/files/a0715c34..de6ff42a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1539&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1539&range=01-02

  Stats: 2742 lines in 69 files changed: 1283 ins; 894 del; 565 mod
  Patch: https://git.openjdk.org/jfx/pull/1539.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1539/head:pull/1539

PR: https://git.openjdk.org/jfx/pull/1539

From arapte at openjdk.org  Tue Aug 20 16:53:10 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 20 Aug 2024 16:53:10 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
In-Reply-To: <N2LARysM9ibWAdHSIET8wvmh0QhDsKetvJEK1o1e69w=.3e98b4c6-0fc8-4ef2-9707-b6905006bf92@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
 <N2LARysM9ibWAdHSIET8wvmh0QhDsKetvJEK1o1e69w=.3e98b4c6-0fc8-4ef2-9707-b6905006bf92@github.com>
Message-ID: <SwfMsANbo_mtaMvL80ru1xpZfD-JwMu_CFRwmjus19s=.45adf44d-e4a1-435a-860f-3f22db53bb2b@github.com>

On Tue, 20 Aug 2024 12:03:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The gradle update looks good. You missed updating the boot JDK for Windows in the GHA build. Also, can you merge in the latest master?

Thanks Kevin, Updated the GHA and merged with latest master.

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

PR Comment: https://git.openjdk.org/jfx/pull/1539#issuecomment-2299311188

From prr at openjdk.org  Tue Aug 20 17:04:21 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Aug 2024 17:04:21 GMT
Subject: [jfx23] RFR: 8338478: [macos] Crash in CoreText with certain strings
 using JDK 22 or later
Message-ID: <uT-IJsfT21KZ5INNqLTKV3Ah3iRPwvjIzd3VqeMWMks=.effc0b7f-d348-4efb-8938-613531d186a4@github.com>

Backport the fix for a crash

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

Commit messages:
 - Backport 269d6897e4d4e62beff3a2179dcdabe8a0bf0bc7

Changes: https://git.openjdk.org/jfx/pull/1540/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338478
  Stats: 87 lines in 1 file changed: 32 ins; 14 del; 41 mod
  Patch: https://git.openjdk.org/jfx/pull/1540.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1540/head:pull/1540

PR: https://git.openjdk.org/jfx/pull/1540

From kcr at openjdk.org  Tue Aug 20 17:04:21 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 17:04:21 GMT
Subject: [jfx23] RFR: 8338478: [macos] Crash in CoreText with certain
 strings using JDK 22 or later
In-Reply-To: <uT-IJsfT21KZ5INNqLTKV3Ah3iRPwvjIzd3VqeMWMks=.effc0b7f-d348-4efb-8938-613531d186a4@github.com>
References: <uT-IJsfT21KZ5INNqLTKV3Ah3iRPwvjIzd3VqeMWMks=.effc0b7f-d348-4efb-8938-613531d186a4@github.com>
Message-ID: <_8Szjfg1sXWRsEeXVcP3kjp7knSeCBIDda_q1q9SyMM=.0462aeee-ba90-47e8-8d57-d11a14ca54ff@github.com>

On Tue, 20 Aug 2024 16:34:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Backport the fix for a crash

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1540#pullrequestreview-2248568996

From prr at openjdk.org  Tue Aug 20 17:10:08 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Aug 2024 17:10:08 GMT
Subject: [jfx23] Integrated: 8338478: [macos] Crash in CoreText with certain
 strings using JDK 22 or later
In-Reply-To: <uT-IJsfT21KZ5INNqLTKV3Ah3iRPwvjIzd3VqeMWMks=.effc0b7f-d348-4efb-8938-613531d186a4@github.com>
References: <uT-IJsfT21KZ5INNqLTKV3Ah3iRPwvjIzd3VqeMWMks=.effc0b7f-d348-4efb-8938-613531d186a4@github.com>
Message-ID: <_7nG9KyDn7iyTgMMq8OWS90d4ncZ_cUGIZzquLBVHqA=.e7685d43-f804-44c4-b9dc-64fa886873f7@github.com>

On Tue, 20 Aug 2024 16:34:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Backport the fix for a crash

This pull request has now been integrated.

Changeset: 1094ee3f
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1094ee3f13f48a33bbfc858b2893daaf2cbe8f39
Stats:     87 lines in 1 file changed: 32 ins; 14 del; 41 mod

8338478: [macos] Crash in CoreText with certain strings using JDK 22 or later

Reviewed-by: kcr
Backport-of: 269d6897e4d4e62beff3a2179dcdabe8a0bf0bc7

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

PR: https://git.openjdk.org/jfx/pull/1540

From kcr at openjdk.org  Tue Aug 20 18:34:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 18:34:09 GMT
Subject: RFR: 8336632: Update Gradle to 8.9 [v3]
In-Reply-To: <p3DmtQepGkZv8A9khhgBt97OjZw8lxC9GfxghRGb-DM=.bd443eaf-f987-4b73-bb68-5f251b961609@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
 <p3DmtQepGkZv8A9khhgBt97OjZw8lxC9GfxghRGb-DM=.bd443eaf-f987-4b73-bb68-5f251b961609@github.com>
Message-ID: <sm1XIRbslLz5-saMebtEogtw3hHe9gUIEMp0VLsDFNY=.2af99602-8344-4be9-8f0b-0f76e8a1f414@github.com>

On Tue, 20 Aug 2024 16:53:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Gradle 8.8 released on May 31, 2024, supports JDK 22.
>> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
>> 
>> This gradle update is required in order to update the boot jdk to 22.0.2.
>> The changes are minimal, no source code changes were required.
>> 
>> This PR also includes the boot jdk update.
>
> Ambarish Rapte has updated the pull request 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. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into gradle89-jdk2202
>  - win bootjdk gha
>  - chmod 644 gradlew
>  - gradle 89, jdk 2202
>  - revert gradle-wrapper.properties partially
>  - gradle 8.9

Looks good. I've tested with gradle 8.9 and JDK 22.0.2.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1539#pullrequestreview-2248753101

From kcr at openjdk.org  Tue Aug 20 18:34:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Aug 2024 18:34:09 GMT
Subject: RFR: 8336632: Update Gradle to 8.9
In-Reply-To: <wX4sqNLRsJLelMqs1GHbuE5Te0QNOdfqcb9W7gUyHls=.7ec3632f-56a3-4f44-a4a3-82dde565c5e6@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
 <wX4sqNLRsJLelMqs1GHbuE5Te0QNOdfqcb9W7gUyHls=.7ec3632f-56a3-4f44-a4a3-82dde565c5e6@github.com>
Message-ID: <loi9g7EGLkG71mvuaTHacsaVnhUeiDpzAQ2MJVEXqJg=.fd54b00e-3e45-4489-b208-5b6acfff25cf@github.com>

On Tue, 20 Aug 2024 13:41:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I would suggested in another PR to have a single constant with the Java version and not updated 12 places to the same version.

This is tracked by https://bugs.openjdk.org/browse/JDK-8255712

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

PR Comment: https://git.openjdk.org/jfx/pull/1539#issuecomment-2299486307

From nlisker at gmail.com  Tue Aug 20 20:08:13 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 20 Aug 2024 23:08:13 +0300
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
Message-ID: <CA+0ynh8q1gA1rD1uOkED7CbR8YbS858z5dw5CUdjuuZPOwi5-w@mail.gmail.com>

When modern APIs agree on a feature, it makes sense to consider it for
JavaFX (that lacks a lot of standard features). If you can give links to
the API and docs of vertex coloring in D3D9, OpenGL, Metal and possibly
Vulkan and D3D11 for future-proofing, we could see what APIs they support
exactly and come up with a common one for JavaFX. Sometimes different
pipelines support the same features in different ways, which makes it
harder to provide a single API abstraction.

There are a couple of points I would look at when designing this feature:
1. Are there other closely related APIs that can come with this feature?
This is required to be able to plan ahead. For example, if an API provides
setting one of the modes A, B or C, and a user proposes an API that only
deals with A, you'd end up with a single method that sets or unsets A.
However, if you then want to evolve the API to support B and C, you would
have liked to model it in a different way that allows you set any of the
modes, and not end up with a single method for each. So, if vertex color is
part of a larger API context, we will need to plan accordingly.
2. The performance of 3D is already problematic in some aspects. Small
additions can drop the FPS considerably. More research should be done to
find out why. We will need to make sure performance isn't going to drop for
cases where this feature isn't used. Seeing as this is only vertex  shader
data, which tends to be cheap and the number of registers available for it
large, I don't foresee problems off the top of my head.

Implementing this will require simultaneous implementations for D3D9 and
OpenGL. Metal is still in the works, so I'm not sure about that one.

It will need the approval of Kevin or Johan.

- Nir

On Tue, Aug 20, 2024 at 9:08?AM Knee Snap <kneester77 at gmail.com> wrote:

> This is my first time attempting to submit a feature request so bear with
> me if I mess up the instructions, I'll do my best to rectify any issues if
> they occur and are pointed out.
>
> *Feature Proposal:* Vertex Colors on TriangleMesh
> Add a new ObservableIntegerArray to TriangleMesh which contains vertex
> colors in ARGB8888 integer format. (I'm open to the pixel format being
> flexible too, but this may be unnecessary).
> Operation of this array should be the same as the other mesh arrays, in
> the sense that the VertexFormat object configures how they should operate.
> Similarly to how normals currently work, the array is optional, and may
> not necessarily need to be included.
> Additionally, the face array will also work the same as usual, where the
> new color indices will be specified on a per-face-vertex basis. (Each
> vertex of each face will have an index specified)
> If the array is present/valid, the colors should be multiplied by 2x the
> diffuse/selfIllumination/specular textures when calculating the FragColor.
> (Clamp the color to the maximum color value of 1.0 when done)
> The reason we multiply by two is to allow the vertex colors to create
> color components larger than what was seen in the texture. So for example,
> a blue component of .75 will result in 1.5x the blue value from the
> material texture.
> This is the standard way of calculating vertex colors when there is a
> texture as I understand. If there were no texture, it would not be
> multiplied by 2.0
> The rasterization process should be responsible for interpolation colors,
> as seen in my examples below.
>
> Example without feature:
> https://i.imgur.com/Hg81LtU.png
>
>
> Example with feature:
> Notice how the lava stream & pipes are the same texture repeated many
> times, but once the vertex coloring feature is used it becomes
> significantly less apparent.
> It can also be used to add details like the rust on various
> metal surfaces, or how the lava fades to black towards the edges. JavaFX
> doesn't contain the appropriate tools to render this scene, but pretty much
> any other 3D library does.
>
>
>
>
> *Why adding this API to the core of JavaFX is a positive/useful addition
> for different applications.*Vertex coloring is a core 3D rendering
> feature supported by virtually every other 3D rendering system on the
> planet. It works on low-end systems, and has been part of 3D rendering
> since the beginning.
> This is true whether the 3D rendering library is high-level (SGI
> OpenInventor, Java3D, jmonkeyengine, etc), low-level (DirectX, Metal,
> Vulkan, OpenGL), or somewhere in-between (Unreal Engine, Unity, Blender,
> etc).
> The only library I could even find which did not support this was JavaFX.
>
> But, just because everyone else does it doesn't mean JavaFX should, right?
> Well, I'd actually like to argue that it should. If JavaFX wants to be
> reasonably compatible/interoperable with virtually any other 3D format,
> application, or tool, it needs to support this.
> Any tool with the capability of importing/exporting 3D models has only one
> for displaying vertex coloring right now: to generate their own texture
> sheet with vertex color shading baked in on a per-face basis.
> This can be a pretty slow process when there are a lot of different faces,
> since every single face with even a single polygon with a slightly
> different texture coordinate will need a new texture on the texture sheet.
> The above screenshot I've shown requires a 4096x4096 texture sheet in
> order to render in JavaFX, and it's a pretty small scene! I've got
> significantly larger scenes which I'm completely unable to render with
> shading because I need to generate a texture sheet more than a gigabyte
> large in order to shade it properly.
> And forget about any kind of common texCoord/UV animations. The CPU needs
> to be constantly redrawing shading textures onto the texture sheet in order
> to ensure animations have the correct shading.
> For the above example, trying to animate the lava to flow down the screen
> as it's supposed to brings my FPS below 30.
> This is despite the texture drawing process having run in parallel and
> extensive performance profiling on my part. I've concluded there's no way
> to get around having proper vertex color support as the main bottleneck is
> just sending such a massively large image to the GPU so frequently as well
> as having to actually shade the images still taking a pretty decent amount
> of time even when done in parallel. And remember, these performance issues
> are happening on one of my small scenes.
>
> Normally drawing vertex colors like this is extremely fast (even on 30
> year old hardware!) when done by the GPU/dedicated hardware, but JavaFX
> just doesn't provide a way to do it with the GPU.
> JavaFX is also the only mainstream 3D library I could find which lacks
> this feature.
> There are 3D environments I cannot even display with shading right now at
> all due to the sheer amount of large textures that need to have shading
> manually drawn onto them.
> This cannot be solved by using a project like Fxyz
> <https://github.com/FXyz/FXyz>, since it just comes down to the texture
> sheets being too large.
> These scenes aren't even particularly large either, having been made for
> game consoles in the range of 20-30 years ago.
>
> This will happen to anyone who needs to use vertex coloring with a
> significant number of textures, and requires writing a lot of code to
> manage texture sheets to ultimately just for it to only partially suffice.
>
> There are other reasons to want vertex coloring outside of compatibility
> with other software too.
> Vertex coloring can often be used to add significant mesh details.
> In the above example, I've already demonstrated how this can be used to
> add details such as rust, fade-outs, etc. But there are many more ways to
> include it too, such as using art styles with flat textures, such as for
> clouds, cartoon art-styles, etc. It's even possible to create shadows by
> using darker colors in areas obscured by others. There are so many clever
> ways this can be used, and I'd spend too much time on individual examples.
> The reason vertex colors have been so prevalent is specifically because of
> the payoff between how easy they are to add and how much can be achieved
> with them.
> I'm not enough of an artist to explain everything with words, but I can
> certainly give a lot of examples via screenshot, if desired.
>
> Since the guideline was to tailor this pitch to the JavaFX community, I
> thought I'd include mention of a few JavaFX projects that I thought would
> benefit significantly. There were others that would benefit in less
> significant ways, so I tried to keep it brief:
>  - Fxyz <https://github.com/FXyz/FXyz>: Probably the most popular JavaFX
> 3D project.
>  - GameExtractor <https://github.com/wattostudios/GameExtractor/>:
> Capable of showing 3D objects in many common formats (.obj, .3ds, Unity
> Format, Unreal Engine 2/3 Format, etc), but is unable to show vertex colors
> due to JavaFX's lack of support.
> -  FrogLord <https://github.com/Kneesnap/FrogLord>: This is my project,
> but every single game I support desperately needs this feature in order to
> accurately preview the custom levels as they are edited, so the user can
> see how they will appear in their game.
>
> Pretty much any project which creates texture sheets containing
> interpolated colors will benefit from this change as in many cases they
> won't need to do that anymore.
> Due to the reduced time and memory usage it will also become significantly
> more feasible/performant to use meshes which change over time as well,
> since fewer changes to the texture sheet will be required, if any at all.
>
> I also imagine this fitting in very easily with the existing API, as
> pretty much all of the public facing APIs could just have a few new methods
> in them, without needing to change any pre-existing APIs at all.
>
> In summary,
> Vertex colors are a feature as ubiquitous in the 3D world as texture
> coordinates, lighting, and materials, yet JavaFX doesn't have them.
> Adding them will allow for a significant amount of detail for virtually no
> performance or maintenance cost, and for some projects it will even improve
> performance & simplify texture sheets.
>
> Additional Note:
> https://bugs.openjdk.org/browse/JDK-6586559
> It looks like this feature may have already been planned at one point, but
> was forgotten due to being low-priority? I don't know.
>
> What does everyone think about this proposal? I eagerly await responses!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/c0ea3be1/attachment-0001.htm>

From angorya at openjdk.org  Tue Aug 20 21:40:29 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 Aug 2024 21:40:29 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v4]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <xdnIi4bI78hAfz7o1RCZ1-pImw3nSBe-jXjyqdILU6U=.03f3d66e-07f8-4e8e-ae6f-d8a5b845c2cf@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request 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. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - update + review comments
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - 8301121: RichTextArea Control (Incubator)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/3e55db8d..a4d7d709

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=02-03

  Stats: 1284 lines in 33 files changed: 552 ins; 392 del; 340 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

From angorya at openjdk.org  Tue Aug 20 21:48:28 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 Aug 2024 21:48:28 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v5]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <Vk5_WP2FZmeK3yWjdsmZ_83AWVz9Kf5_GAW82IbdtO4=.7cb03d80-3a11-4126-ae69-9c692fc5c0b1@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - cleanup
 - navigation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/a4d7d709..09a1637c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=03-04

  Stats: 372 lines in 6 files changed: 318 ins; 21 del; 33 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

From kevin.rushforth at oracle.com  Tue Aug 20 22:41:13 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Aug 2024 15:41:13 -0700
Subject: No Place for JEPs
In-Reply-To: <BL3PR10MB61850070D0037F6824C85FF8E5BA2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <BL3PR10MB618595435024348B39CEB480E5B82@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXTfoDVqmSBQZLjQtxo=v8DDO84ggO=n4KxiC__xduDE7g@mail.gmail.com>
 <BL3PR10MB61850070D0037F6824C85FF8E5BA2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <4c92f699-8efd-4617-8ef7-9ef5fee32f07@oracle.com>

As Andy mentioned, a JEP has value as documentation beyond the moment a 
feature is implemented. It describes a a medium to large feature, and is 
intended to be complete and accurate at the time that feature is 
delivered. In the JDK, each release has a list of JEPs that describe the 
feature set of that release. For example, here is the list for the 
soon-to-be-released JDK 23:

https://openjdk.org/projects/jdk/23/#Features

Typically, a feature JEP is not updated after the release in which the 
feature was delivered. If there are further refinements to a feature, 
that's fine; it doesn't invalidate the original JEP. Subsequent changes 
might or might? not need a new JEP, depending on how substantial the change.

So the question is: Where should we store and track JavaFX JEPs? I think 
we have three reasonable alternatives, with a couple variations of the 
second.

Alternative 1: In JBS, using the JEP issue type.

This is where the JDK stores their JEPs.

Pros:
-- Uses the same mechanisms as the JDK does
-- JEP issue can be easily linked to the Enhancement that will implement it.

Cons:
-- Cumbersome to evolve, review, and track changes
-- JIRA supports a more limited markdown than GitHub
-- Because we aren't bundled, all JEPs would remain in Draft mode, we 
would need other means (maybe labels) to indicate when a JEP was 
considered to be final


Alternative 2: In a git repository, using a markdown file

JEPs would be reviewed and eventually integrated in an openjdk 
repository. There are two variations we could consider:

A. In the mainline openjdk/jfx repo (e.g., under "doc-files/jeps")

B. In a separate "jfx-docs" repo

In either case, we would need to create a separate JBS issue, with a 
convention that would allow is to identify it as a JEP doc, to integrate 
the JEP markdown file, once it was "accepted". We would integrate that 
with a separate PR ahead of the implementation of that JEP; for 
variation A it would be possible for the JEP to accompany the 
implementation of the JEP in the same PR that implements it, but I don't 
think that's a best practice (and I'd still want a separate "JEP doc" 
issue). Having a separate repo (variation B) more closely tracks the 
idea of JEPs being a separate deliverable, but it's a little more 
overhead, and is perhaps less flexible.

Pros:
-- Easier to evolve, review and track changes: Use a PR to review the JEP
-- Richer markdown

Cons:
-- Divergent with what the JDK does
-- A PR in the same repo for the JEP and the feature itself could be 
confusing (need to develop some "best practices")


Alternative 3:? On a Wiki page

We could use a set of? pages in the OpenJDK Wiki, one per JEP plus an 
index page to organize them.

Pros:
-- A little easier to edit than a JBS issue, a little easier to track 
changes (Wiki history diffs are at least somewhat easier to read than 
raw JIRA diffs)

Cons:
-- Harder to organize
-- Yet another editing tool to learn
-- Harder to track the state without some conventions to cross-link the 
JEP page in the Wiki to the JBS enhancement
-- Harder to review than an MD file (no inline comments, although that's 
true of JBS as well)


Regardless of which alternative we choose, we will want to list the JEPs 
for each release on a Wiki page, along with the JEPs that are in 
progress. We should consider highlighting them in the release notes.

Comments?

-- Kevin


On 8/9/2024 8:28 AM, Andy Goryachev wrote:
>
> Michael:
>
> Yes, by design.? I think the JEPs still have value even after the 
> actual changes were made.? Also, nothing prevents us from creating an 
> index.html file that lists the JEPs in chronological order and 
> mentions the state of the implemented features and whether and how the 
> actual implementation differs from the JEP.
>
> Sorry, I did not quite understand what you mean by "documentation 
> colocated with the code" - isn't that what I am proposing?
>
> At the same time, I wanted to consider other possibilities, such as
>
> - wikis (same drawbacks as github PRs, even harder to review / keep 
> track of changes / lack of co-location)
>
> - separate doc repo (not co-located with the code)
>
> - ??
>
> What do you think?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Friday, August 9, 2024 at 07:31
> *To: *
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: No Place for JEPs
>
> Hi Andy,
>
> wouldn't these documents risk getting outdated when the codebase is
> evolved? JEPs seem to be most relevant at the time when a feature is
> proposed. I think I'd rather have documentation colocated with the
> code itself, this makes it easier to keep the documentation in sync
> with the actual implementation.
>
>
> On Wed, Aug 7, 2024 at 8:46?PM Andy Goryachev 
> <andy.goryachev at oracle.com> wrote:
> >
> > Dear fellow developers:
> >
> >
> >
> > We often create JEPs and JEP-formatted documents as we propose and 
> develop new features.? These help us during the review process and I 
> am sure are of some benefit for application developers as they try to 
> learn the new functionality in depth.? Presently, we've been creating 
> these files in personal repositories, or presented as descriptions for 
> pull requests, see for example [0].
> >
> >
> >
> > I think there is a value in making these documents a part of the 
> main repository, maybe under /doc-files.? Doing so would help with the 
> review process as the markdown files are both human-readable and 
> easily diff'ed.? Also, I think it might be more convenient to keep 
> them in the same repo as the code, as opposed to the some personal 
> repositories or wikis.
> >
> >
> >
> > What do you think?
> >
> >
> >
> > -andy
> >
> >
> >
> >
> >
> > References
> >
> >
> >
> > [0] https://github.com/openjdk/jfx/pull/1522
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/af18c9f8/attachment-0001.htm>

From almatvee at openjdk.org  Wed Aug 21 01:23:36 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 Aug 2024 01:23:36 GMT
Subject: [jfx23u] RFR: 8336938: Update libFFI to 3.4.6
Message-ID: <v_1S3EDV42O3Ee2-qFBitm6qph9B-vFUvaimfh06v6I=.26124aef-fae0-44a1-8b38-171e425d4d10@github.com>

- Clean backport of JDK-8336938.

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

Commit messages:
 - Backport f1bac5a829e1f2b75b863c4f0822bf418107a1fb

Changes: https://git.openjdk.org/jfx23u/pull/11/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336938
  Stats: 1056 lines in 26 files changed: 388 ins; 373 del; 295 mod
  Patch: https://git.openjdk.org/jfx23u/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/11/head:pull/11

PR: https://git.openjdk.org/jfx23u/pull/11

From kneester77 at gmail.com  Wed Aug 21 03:41:03 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Tue, 20 Aug 2024 20:41:03 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CA+0ynh8q1gA1rD1uOkED7CbR8YbS858z5dw5CUdjuuZPOwi5-w@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CA+0ynh8q1gA1rD1uOkED7CbR8YbS858z5dw5CUdjuuZPOwi5-w@mail.gmail.com>
Message-ID: <CAB9Lf7K49FGcUj6Hm1H0ZJ8+BXYrcJJ-EkB4bMX1vyUJ1EyNBw@mail.gmail.com>

Thanks for the reply!

*> If you can give links to the API and docs of vertex coloring in D3D9,
OpenGL, Metal and possibly Vulkan and D3D11 for future-proofing, we could
see what APIs they support exactly and come up with a common one for
JavaFX. Sometimes different pipelines support the same features in
different ways, which makes it harder to provide a single API abstraction.
D3D9, OpenGL, Metal and possibly Vulkan and D3D11*
I've laid out a very basic explanation of the API changes I imagine in the
first email, but I'll follow up in a bit with a more in-depth proposal once
the aforementioned Kevin or Johan give the OK on the proposal to continue
to the API discussion stage detailed in the contribution guide.


Fixed Rendering Pipeline Documentation Examples (PLEASE READ BELOW FOR MORE
CONTEXT FIRST):
 - Enable/Disable Per-Vertex Coloring
<https://learn.microsoft.com/en-us/windows/win32/direct3d9/per-vertex-color-state>
 (
https://learn.microsoft.com/en-us/windows/win32/direct3d9/per-vertex-color-state
)
 - Shows D3DFVF_DIFFUSE as the flag to use to enable vertex colors in the
vertex format.
<https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dfvf> (
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dfvf)

Providing documentation is a little hard to do, and I think I need to
explain/give a little more context , since JavaFX doesn't appear to use any
fixed rendering pipelines.
When I said "DirectX / OpenGL supports vertex colors", what I'm referring
to is two things: the fixed rendering pipeline which explicitly supports
vertex colors, and the shader-based pipeline capable of supporting
vertex colors.
The fixed rendering pipeline is the one where there would be a specific
library function call relating to vertex colors. I've included some links
above as examples.
However, fixed rendering pipelines aren't often used these days because
they're less flexible because shaders are actually akin to small embedded
programs that run in parallel, which the developer can write themselves.
Since JavaFX doesn't use fixed rendering pipelines and it wants to
anticipate the future, I don't see any reason to focus on the fixed
rendering pipeline, which makes it more difficult to give documentation on
how to do this.

I think I can still answer the spirit of the question though.
The reason there's no explicit API call when using shaders is because these
APIs aren't actually managing the color for us directly anymore.
Instead, JavaFX is responsible for creating/ordering/organizing
arrays/buffers itself, and giving the GPU a shader program configuring how
to render the contents of the buffer.
So in order to make vertex colors work under this paradigm, it's one of the
most simple operations out there, a simple multiplication. We'll put the
color in the buffer, then when drawing a vertex, the GPU shader will take
the color out of the buffer and perform a multiplication operation.
That's all it takes to make vertex colors work with the shader paradigm, so
it's very hard to imagine a future potential shader-based system which
cannot do this, as it's hard to imagine a shader which doesn't both have
even a single one of these three things:
 1) Access to arbitrary buffer data per-vertex supplied by the CPU
(otherwise how could it render anything?)
 2) Multiplication support (How could it do anything useful without this?)
 3) Ability to control the output color on a per-pixel basis,
using interpolated data from the vertiex buffer(s) used for the given
polygon. (This is the entire purpose of the pixel/fragment shader so it's
unfathomable for this to not exist, there would be almost no point to
shaders if this didn't exist.)

These are all super critical to shaders in general being useful, so it's
very difficult to imagine a scenario where JavaFX would be looking to
support a shader-based backend that didn't have even a single one of those
things.
I think this should hopefully answer that question, even if I didn't do
exactly the way you wanted.

But wait, if I'm not actually making major changes that involve any
Direct3D / OpenGL function calls, what would even get changed for this
feature?
Firstly, the shader(s) themselves. We've got to make it so the shaders
properly describe that they should receive vertex color data in a buffer,
and multiply that vertex color data as described previously.
(modules\src\main\resources\prism.es2.glsl\ and
modules\src\main\resources\native-prism-d3d\hlsl)
Secondly, JavaFX's buffer management code needs to be changed to include
vertex color data in the buffers, when applicable. (BaseMesh.java?)
Lastly, all of the code sitting between the previous steps and the public
user-facing API additions will need to be filled in. I think this is mostly
just the bridge between TriangleMesh.java and NGTriangleMesh.java.

*> 1. Are there other closely related APIs that can come with this feature?
This is required to be able to plan ahead. For example, if an API provides
setting one of the modes A, B or C, and a user proposes an API that only
deals with A, you'd end up with a single method that sets or unsets A.
However, if you then want to evolve the API to support B and C, you would
have liked to model it in a different way that allows you set any of the
modes, and not end up with a single method for each. So, if vertex color is
part of a larger API context, we will need to plan accordingly.*
I've thought of a few features which could be related, but I don't think
vertex colors impact these features in a way which adds difficulties which
aren't already present:
 - The ability to use custom shaders supplied by the user alongside
arbitrary buffers, textures, and globals. (This is probably never coming,
but if it does, good to plan ahead of time)
 - Deferred rendering to allow efficient implementation of more than 3
lights at a time. (Could even be thousands of lights)
 - Allowing the user to choose 3D scene axis orientations instead of always
defaulting to Y- being "up". (Perhaps this can be done just by messing with
the camera without a JavaFX feature, not sure.)
 - Allowing the user to choose between clockwise/counter-clockwise winding
order.
 - Allowing the user to choose whether mip-maps are enabled.
 - Allowing the user to choose the texture wrapping mode for a
PhongMaterial.

If anyone can think of any other features which it could conflict with, or
ways it could complicate the features I've mentioned, do share the concerns.


*> 2. The performance of 3D is already problematic in some aspects. Small
additions can drop the FPS considerably. More research should be done to
find out why. We will need to make sure performance isn't going to drop for
cases where this feature isn't used. Seeing as this is only vertex  shader
data, which tends to be cheap and the number of registers available for it
large, I don't foresee problems off the top of my head.*
The biggest thing for performance is going to be how the underlying
implementations work for each backend. If done using best practices, this
should have no meaningful performance impact. After all, this technique has
been used since before 3D hardware acceleration, so it should be very
performance friendly.
As for when the feature is disabled, this feature should be possible to
completely disable when not in use, ensuring it would have zero performance
impact. There's already code I see to allow compiling different versions of
shaders, we could compile a version without the vertex colors enabled. I'm
not sure if this would even be necessary, but the option is there.

*> Implementing this will require simultaneous implementations for D3D9 and
OpenGL. Metal is still in the works, so I'm not sure about that one.*
I see, is there someone/a group working on the Metal backend? If so, it'd
be nice to hear if they have any thoughts on this.


On Tue, Aug 20, 2024 at 1:08?PM Nir Lisker <nlisker at gmail.com> wrote:

> When modern APIs agree on a feature, it makes sense to consider it for
> JavaFX (that lacks a lot of standard features). If you can give links to
> the API and docs of vertex coloring in D3D9, OpenGL, Metal and possibly
> Vulkan and D3D11 for future-proofing, we could see what APIs they support
> exactly and come up with a common one for JavaFX. Sometimes different
> pipelines support the same features in different ways, which makes it
> harder to provide a single API abstraction.
>
> There are a couple of points I would look at when designing this feature:
> 1. Are there other closely related APIs that can come with this feature?
> This is required to be able to plan ahead. For example, if an API provides
> setting one of the modes A, B or C, and a user proposes an API that only
> deals with A, you'd end up with a single method that sets or unsets A.
> However, if you then want to evolve the API to support B and C, you would
> have liked to model it in a different way that allows you set any of the
> modes, and not end up with a single method for each. So, if vertex color is
> part of a larger API context, we will need to plan accordingly.
> 2. The performance of 3D is already problematic in some aspects. Small
> additions can drop the FPS considerably. More research should be done to
> find out why. We will need to make sure performance isn't going to drop for
> cases where this feature isn't used. Seeing as this is only vertex  shader
> data, which tends to be cheap and the number of registers available for it
> large, I don't foresee problems off the top of my head.
>
> Implementing this will require simultaneous implementations for D3D9 and
> OpenGL. Metal is still in the works, so I'm not sure about that one.
>
> It will need the approval of Kevin or Johan.
>
> - Nir
>
> On Tue, Aug 20, 2024 at 9:08?AM Knee Snap <kneester77 at gmail.com> wrote:
>
>> This is my first time attempting to submit a feature request so bear with
>> me if I mess up the instructions, I'll do my best to rectify any issues if
>> they occur and are pointed out.
>>
>> *Feature Proposal:* Vertex Colors on TriangleMesh
>> Add a new ObservableIntegerArray to TriangleMesh which contains vertex
>> colors in ARGB8888 integer format. (I'm open to the pixel format being
>> flexible too, but this may be unnecessary).
>> Operation of this array should be the same as the other mesh arrays, in
>> the sense that the VertexFormat object configures how they should operate.
>> Similarly to how normals currently work, the array is optional, and may
>> not necessarily need to be included.
>> Additionally, the face array will also work the same as usual, where the
>> new color indices will be specified on a per-face-vertex basis. (Each
>> vertex of each face will have an index specified)
>> If the array is present/valid, the colors should be multiplied by 2x the
>> diffuse/selfIllumination/specular textures when calculating the FragColor.
>> (Clamp the color to the maximum color value of 1.0 when done)
>> The reason we multiply by two is to allow the vertex colors to create
>> color components larger than what was seen in the texture. So for example,
>> a blue component of .75 will result in 1.5x the blue value from the
>> material texture.
>> This is the standard way of calculating vertex colors when there is a
>> texture as I understand. If there were no texture, it would not be
>> multiplied by 2.0
>> The rasterization process should be responsible for interpolation colors,
>> as seen in my examples below.
>>
>> Example without feature:
>> https://i.imgur.com/Hg81LtU.png
>>
>>
>> Example with feature:
>> Notice how the lava stream & pipes are the same texture repeated many
>> times, but once the vertex coloring feature is used it becomes
>> significantly less apparent.
>> It can also be used to add details like the rust on various
>> metal surfaces, or how the lava fades to black towards the edges. JavaFX
>> doesn't contain the appropriate tools to render this scene, but pretty much
>> any other 3D library does.
>>
>>
>>
>>
>> *Why adding this API to the core of JavaFX is a positive/useful addition
>> for different applications.*Vertex coloring is a core 3D rendering
>> feature supported by virtually every other 3D rendering system on the
>> planet. It works on low-end systems, and has been part of 3D rendering
>> since the beginning.
>> This is true whether the 3D rendering library is high-level (SGI
>> OpenInventor, Java3D, jmonkeyengine, etc), low-level (DirectX, Metal,
>> Vulkan, OpenGL), or somewhere in-between (Unreal Engine, Unity, Blender,
>> etc).
>> The only library I could even find which did not support this was JavaFX.
>>
>> But, just because everyone else does it doesn't mean JavaFX should, right?
>> Well, I'd actually like to argue that it should. If JavaFX wants to be
>> reasonably compatible/interoperable with virtually any other 3D format,
>> application, or tool, it needs to support this.
>> Any tool with the capability of importing/exporting 3D models has only
>> one for displaying vertex coloring right now: to generate their own texture
>> sheet with vertex color shading baked in on a per-face basis.
>> This can be a pretty slow process when there are a lot of different
>> faces, since every single face with even a single polygon with a slightly
>> different texture coordinate will need a new texture on the texture sheet.
>> The above screenshot I've shown requires a 4096x4096 texture sheet in
>> order to render in JavaFX, and it's a pretty small scene! I've got
>> significantly larger scenes which I'm completely unable to render with
>> shading because I need to generate a texture sheet more than a gigabyte
>> large in order to shade it properly.
>> And forget about any kind of common texCoord/UV animations. The CPU needs
>> to be constantly redrawing shading textures onto the texture sheet in order
>> to ensure animations have the correct shading.
>> For the above example, trying to animate the lava to flow down the screen
>> as it's supposed to brings my FPS below 30.
>> This is despite the texture drawing process having run in parallel and
>> extensive performance profiling on my part. I've concluded there's no way
>> to get around having proper vertex color support as the main bottleneck is
>> just sending such a massively large image to the GPU so frequently as well
>> as having to actually shade the images still taking a pretty decent amount
>> of time even when done in parallel. And remember, these performance issues
>> are happening on one of my small scenes.
>>
>> Normally drawing vertex colors like this is extremely fast (even on 30
>> year old hardware!) when done by the GPU/dedicated hardware, but JavaFX
>> just doesn't provide a way to do it with the GPU.
>> JavaFX is also the only mainstream 3D library I could find which lacks
>> this feature.
>> There are 3D environments I cannot even display with shading right now at
>> all due to the sheer amount of large textures that need to have shading
>> manually drawn onto them.
>> This cannot be solved by using a project like Fxyz
>> <https://github.com/FXyz/FXyz>, since it just comes down to the texture
>> sheets being too large.
>> These scenes aren't even particularly large either, having been made for
>> game consoles in the range of 20-30 years ago.
>>
>> This will happen to anyone who needs to use vertex coloring with a
>> significant number of textures, and requires writing a lot of code to
>> manage texture sheets to ultimately just for it to only partially suffice.
>>
>> There are other reasons to want vertex coloring outside of compatibility
>> with other software too.
>> Vertex coloring can often be used to add significant mesh details.
>> In the above example, I've already demonstrated how this can be used to
>> add details such as rust, fade-outs, etc. But there are many more ways to
>> include it too, such as using art styles with flat textures, such as for
>> clouds, cartoon art-styles, etc. It's even possible to create shadows by
>> using darker colors in areas obscured by others. There are so many clever
>> ways this can be used, and I'd spend too much time on individual examples.
>> The reason vertex colors have been so prevalent is specifically because of
>> the payoff between how easy they are to add and how much can be achieved
>> with them.
>> I'm not enough of an artist to explain everything with words, but I can
>> certainly give a lot of examples via screenshot, if desired.
>>
>> Since the guideline was to tailor this pitch to the JavaFX community, I
>> thought I'd include mention of a few JavaFX projects that I thought would
>> benefit significantly. There were others that would benefit in less
>> significant ways, so I tried to keep it brief:
>>  - Fxyz <https://github.com/FXyz/FXyz>: Probably the most popular JavaFX
>> 3D project.
>>  - GameExtractor <https://github.com/wattostudios/GameExtractor/>:
>> Capable of showing 3D objects in many common formats (.obj, .3ds, Unity
>> Format, Unreal Engine 2/3 Format, etc), but is unable to show vertex colors
>> due to JavaFX's lack of support.
>> -  FrogLord <https://github.com/Kneesnap/FrogLord>: This is my project,
>> but every single game I support desperately needs this feature in order to
>> accurately preview the custom levels as they are edited, so the user can
>> see how they will appear in their game.
>>
>> Pretty much any project which creates texture sheets containing
>> interpolated colors will benefit from this change as in many cases they
>> won't need to do that anymore.
>> Due to the reduced time and memory usage it will also become
>> significantly more feasible/performant to use meshes which change over time
>> as well, since fewer changes to the texture sheet will be required, if any
>> at all.
>>
>> I also imagine this fitting in very easily with the existing API, as
>> pretty much all of the public facing APIs could just have a few new methods
>> in them, without needing to change any pre-existing APIs at all.
>>
>> In summary,
>> Vertex colors are a feature as ubiquitous in the 3D world as texture
>> coordinates, lighting, and materials, yet JavaFX doesn't have them.
>> Adding them will allow for a significant amount of detail for virtually
>> no performance or maintenance cost, and for some projects it will even
>> improve performance & simplify texture sheets.
>>
>> Additional Note:
>> https://bugs.openjdk.org/browse/JDK-6586559
>> It looks like this feature may have already been planned at one point,
>> but was forgotten due to being low-priority? I don't know.
>>
>> What does everyone think about this proposal? I eagerly await responses!
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/03472115/attachment-0001.htm>

From kneester77 at gmail.com  Wed Aug 21 05:20:42 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Tue, 20 Aug 2024 22:20:42 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7K49FGcUj6Hm1H0ZJ8+BXYrcJJ-EkB4bMX1vyUJ1EyNBw@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CA+0ynh8q1gA1rD1uOkED7CbR8YbS858z5dw5CUdjuuZPOwi5-w@mail.gmail.com>
 <CAB9Lf7K49FGcUj6Hm1H0ZJ8+BXYrcJJ-EkB4bMX1vyUJ1EyNBw@mail.gmail.com>
Message-ID: <CAB9Lf7LXP2A9rEuZNKfc6UcbiuCN+DV2MzH7-X6X0QPYsWA5rA@mail.gmail.com>

In addition to my last email, here's the public API proposal.

*Mesh.java:*
buildGeometry(...) now accepts a vertex color array.

*NGTriangleMesh.java:*
+ void setUserDefinedColors(boolean)
+ boolean isUserDefinedColors()
+ void syncColors(IntegerArraySyncer)

*TriangleMesh.java:*
+ ObservableFloatArray getColors()
*NOTE*
Originally I wanted an ARGB8888 ObservableIntegerArray since that's the
standard color format and I didn't want to waste memory.
Upon further thought this doesn't make sense. In order to put a color into
the buffer it must be converted to floating point numbers anyways, since
"float[4]" is the recommended data type to represent colors in shaders.
Then I also considered how 0-255 is actually a bad way to represent the
range 0.0 to 2.0, since the max value of 255 is odd and cannot be divided
by two. For my personal situation this is fine, but I think in terms of a
general solution for everyone else a floating point number is more flexible.
Finally, when I started considering how others might use it, I realized
floating points had the additional advantage of not being capped at 2.0, so
someone could put in a vertex color modulation value of 3.0, where-as in
ARGB8888 they could not.
So I've concluded that ObservableFloatArray with four elements (R, G, B, A)
is preferable to ObservableIntegerArray with a single ARGB8888 element.

*VertexFormat.java:*
+ static final VertexFormat POINT_TEXCOORD_COLOR
+ static final VertexFormat POINT_NORMAL_TEXCOORD_COLOR
+ int getColorElementSize()
+ int getColorIndexOffset()

Any thoughts on this? My next goal is to create a draft PR with this
implemented, but I'm still looking for feedback.

On Tue, Aug 20, 2024 at 8:41?PM Knee Snap <kneester77 at gmail.com> wrote:

> Thanks for the reply!
>
> *> If you can give links to the API and docs of vertex coloring in D3D9,
> OpenGL, Metal and possibly Vulkan and D3D11 for future-proofing, we could
> see what APIs they support exactly and come up with a common one for
> JavaFX. Sometimes different pipelines support the same features in
> different ways, which makes it harder to provide a single API abstraction.
> D3D9, OpenGL, Metal and possibly Vulkan and D3D11*
> I've laid out a very basic explanation of the API changes I imagine in the
> first email, but I'll follow up in a bit with a more in-depth proposal once
> the aforementioned Kevin or Johan give the OK on the proposal to continue
> to the API discussion stage detailed in the contribution guide.
>
>
> Fixed Rendering Pipeline Documentation Examples (PLEASE READ BELOW FOR
> MORE CONTEXT FIRST):
>  - Enable/Disable Per-Vertex Coloring
> <https://learn.microsoft.com/en-us/windows/win32/direct3d9/per-vertex-color-state>
>  (
> https://learn.microsoft.com/en-us/windows/win32/direct3d9/per-vertex-color-state
> )
>  - Shows D3DFVF_DIFFUSE as the flag to use to enable vertex colors in the
> vertex format.
> <https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dfvf> (
> https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dfvf)
>
> Providing documentation is a little hard to do, and I think I need to
> explain/give a little more context , since JavaFX doesn't appear to use any
> fixed rendering pipelines.
> When I said "DirectX / OpenGL supports vertex colors", what I'm referring
> to is two things: the fixed rendering pipeline which explicitly supports
> vertex colors, and the shader-based pipeline capable of supporting
> vertex colors.
> The fixed rendering pipeline is the one where there would be a specific
> library function call relating to vertex colors. I've included some links
> above as examples.
> However, fixed rendering pipelines aren't often used these days because
> they're less flexible because shaders are actually akin to small embedded
> programs that run in parallel, which the developer can write themselves.
> Since JavaFX doesn't use fixed rendering pipelines and it wants to
> anticipate the future, I don't see any reason to focus on the fixed
> rendering pipeline, which makes it more difficult to give documentation on
> how to do this.
>
> I think I can still answer the spirit of the question though.
> The reason there's no explicit API call when using shaders is because
> these APIs aren't actually managing the color for us directly anymore.
> Instead, JavaFX is responsible for creating/ordering/organizing
> arrays/buffers itself, and giving the GPU a shader program configuring how
> to render the contents of the buffer.
> So in order to make vertex colors work under this paradigm, it's one of
> the most simple operations out there, a simple multiplication. We'll put
> the color in the buffer, then when drawing a vertex, the GPU shader will
> take the color out of the buffer and perform a multiplication operation.
> That's all it takes to make vertex colors work with the shader paradigm,
> so it's very hard to imagine a future potential shader-based system which
> cannot do this, as it's hard to imagine a shader which doesn't both have
> even a single one of these three things:
>  1) Access to arbitrary buffer data per-vertex supplied by the CPU
> (otherwise how could it render anything?)
>  2) Multiplication support (How could it do anything useful without this?)
>  3) Ability to control the output color on a per-pixel basis,
> using interpolated data from the vertiex buffer(s) used for the given
> polygon. (This is the entire purpose of the pixel/fragment shader so it's
> unfathomable for this to not exist, there would be almost no point to
> shaders if this didn't exist.)
>
> These are all super critical to shaders in general being useful, so it's
> very difficult to imagine a scenario where JavaFX would be looking to
> support a shader-based backend that didn't have even a single one of those
> things.
> I think this should hopefully answer that question, even if I didn't do
> exactly the way you wanted.
>
> But wait, if I'm not actually making major changes that involve any
> Direct3D / OpenGL function calls, what would even get changed for this
> feature?
> Firstly, the shader(s) themselves. We've got to make it so the shaders
> properly describe that they should receive vertex color data in a buffer,
> and multiply that vertex color data as described previously.
> (modules\src\main\resources\prism.es2.glsl\ and
> modules\src\main\resources\native-prism-d3d\hlsl)
> Secondly, JavaFX's buffer management code needs to be changed to include
> vertex color data in the buffers, when applicable. (BaseMesh.java?)
> Lastly, all of the code sitting between the previous steps and the public
> user-facing API additions will need to be filled in. I think this is mostly
> just the bridge between TriangleMesh.java and NGTriangleMesh.java.
>
> *> 1. Are there other closely related APIs that can come with this
> feature? This is required to be able to plan ahead. For example, if an API
> provides setting one of the modes A, B or C, and a user proposes an API
> that only deals with A, you'd end up with a single method that sets or
> unsets A. However, if you then want to evolve the API to support B and C,
> you would have liked to model it in a different way that allows you set any
> of the modes, and not end up with a single method for each. So, if vertex
> color is part of a larger API context, we will need to plan accordingly.*
> I've thought of a few features which could be related, but I don't think
> vertex colors impact these features in a way which adds difficulties which
> aren't already present:
>  - The ability to use custom shaders supplied by the user alongside
> arbitrary buffers, textures, and globals. (This is probably never coming,
> but if it does, good to plan ahead of time)
>  - Deferred rendering to allow efficient implementation of more than 3
> lights at a time. (Could even be thousands of lights)
>  - Allowing the user to choose 3D scene axis orientations instead of
> always defaulting to Y- being "up". (Perhaps this can be done just by
> messing with the camera without a JavaFX feature, not sure.)
>  - Allowing the user to choose between clockwise/counter-clockwise winding
> order.
>  - Allowing the user to choose whether mip-maps are enabled.
>  - Allowing the user to choose the texture wrapping mode for a
> PhongMaterial.
>
> If anyone can think of any other features which it could conflict with, or
> ways it could complicate the features I've mentioned, do share the concerns.
>
>
> *> 2. The performance of 3D is already problematic in some aspects. Small
> additions can drop the FPS considerably. More research should be done to
> find out why. We will need to make sure performance isn't going to drop for
> cases where this feature isn't used. Seeing as this is only vertex  shader
> data, which tends to be cheap and the number of registers available for it
> large, I don't foresee problems off the top of my head.*
> The biggest thing for performance is going to be how the underlying
> implementations work for each backend. If done using best practices, this
> should have no meaningful performance impact. After all, this technique has
> been used since before 3D hardware acceleration, so it should be very
> performance friendly.
> As for when the feature is disabled, this feature should be possible to
> completely disable when not in use, ensuring it would have zero performance
> impact. There's already code I see to allow compiling different versions of
> shaders, we could compile a version without the vertex colors enabled. I'm
> not sure if this would even be necessary, but the option is there.
>
> *> Implementing this will require simultaneous implementations for D3D9
> and OpenGL. Metal is still in the works, so I'm not sure about that one.*
> I see, is there someone/a group working on the Metal backend? If so, it'd
> be nice to hear if they have any thoughts on this.
>
>
> On Tue, Aug 20, 2024 at 1:08?PM Nir Lisker <nlisker at gmail.com> wrote:
>
>> When modern APIs agree on a feature, it makes sense to consider it for
>> JavaFX (that lacks a lot of standard features). If you can give links to
>> the API and docs of vertex coloring in D3D9, OpenGL, Metal and possibly
>> Vulkan and D3D11 for future-proofing, we could see what APIs they support
>> exactly and come up with a common one for JavaFX. Sometimes different
>> pipelines support the same features in different ways, which makes it
>> harder to provide a single API abstraction.
>>
>> There are a couple of points I would look at when designing this feature:
>> 1. Are there other closely related APIs that can come with this feature?
>> This is required to be able to plan ahead. For example, if an API provides
>> setting one of the modes A, B or C, and a user proposes an API that only
>> deals with A, you'd end up with a single method that sets or unsets A.
>> However, if you then want to evolve the API to support B and C, you would
>> have liked to model it in a different way that allows you set any of the
>> modes, and not end up with a single method for each. So, if vertex color is
>> part of a larger API context, we will need to plan accordingly.
>> 2. The performance of 3D is already problematic in some aspects. Small
>> additions can drop the FPS considerably. More research should be done to
>> find out why. We will need to make sure performance isn't going to drop for
>> cases where this feature isn't used. Seeing as this is only vertex  shader
>> data, which tends to be cheap and the number of registers available for it
>> large, I don't foresee problems off the top of my head.
>>
>> Implementing this will require simultaneous implementations for D3D9 and
>> OpenGL. Metal is still in the works, so I'm not sure about that one.
>>
>> It will need the approval of Kevin or Johan.
>>
>> - Nir
>>
>> On Tue, Aug 20, 2024 at 9:08?AM Knee Snap <kneester77 at gmail.com> wrote:
>>
>>> This is my first time attempting to submit a feature request so bear
>>> with me if I mess up the instructions, I'll do my best to rectify any
>>> issues if they occur and are pointed out.
>>>
>>> *Feature Proposal:* Vertex Colors on TriangleMesh
>>> Add a new ObservableIntegerArray to TriangleMesh which contains vertex
>>> colors in ARGB8888 integer format. (I'm open to the pixel format being
>>> flexible too, but this may be unnecessary).
>>> Operation of this array should be the same as the other mesh arrays, in
>>> the sense that the VertexFormat object configures how they should operate.
>>> Similarly to how normals currently work, the array is optional, and may
>>> not necessarily need to be included.
>>> Additionally, the face array will also work the same as usual, where the
>>> new color indices will be specified on a per-face-vertex basis. (Each
>>> vertex of each face will have an index specified)
>>> If the array is present/valid, the colors should be multiplied by 2x the
>>> diffuse/selfIllumination/specular textures when calculating the FragColor.
>>> (Clamp the color to the maximum color value of 1.0 when done)
>>> The reason we multiply by two is to allow the vertex colors to create
>>> color components larger than what was seen in the texture. So for example,
>>> a blue component of .75 will result in 1.5x the blue value from the
>>> material texture.
>>> This is the standard way of calculating vertex colors when there is a
>>> texture as I understand. If there were no texture, it would not be
>>> multiplied by 2.0
>>> The rasterization process should be responsible for interpolation
>>> colors, as seen in my examples below.
>>>
>>> Example without feature:
>>> https://i.imgur.com/Hg81LtU.png
>>>
>>>
>>> Example with feature:
>>> Notice how the lava stream & pipes are the same texture repeated many
>>> times, but once the vertex coloring feature is used it becomes
>>> significantly less apparent.
>>> It can also be used to add details like the rust on various
>>> metal surfaces, or how the lava fades to black towards the edges. JavaFX
>>> doesn't contain the appropriate tools to render this scene, but pretty much
>>> any other 3D library does.
>>>
>>>
>>>
>>>
>>> *Why adding this API to the core of JavaFX is a positive/useful addition
>>> for different applications.*Vertex coloring is a core 3D rendering
>>> feature supported by virtually every other 3D rendering system on the
>>> planet. It works on low-end systems, and has been part of 3D rendering
>>> since the beginning.
>>> This is true whether the 3D rendering library is high-level (SGI
>>> OpenInventor, Java3D, jmonkeyengine, etc), low-level (DirectX, Metal,
>>> Vulkan, OpenGL), or somewhere in-between (Unreal Engine, Unity, Blender,
>>> etc).
>>> The only library I could even find which did not support this was JavaFX.
>>>
>>> But, just because everyone else does it doesn't mean JavaFX should,
>>> right?
>>> Well, I'd actually like to argue that it should. If JavaFX wants to be
>>> reasonably compatible/interoperable with virtually any other 3D format,
>>> application, or tool, it needs to support this.
>>> Any tool with the capability of importing/exporting 3D models has only
>>> one for displaying vertex coloring right now: to generate their own texture
>>> sheet with vertex color shading baked in on a per-face basis.
>>> This can be a pretty slow process when there are a lot of different
>>> faces, since every single face with even a single polygon with a slightly
>>> different texture coordinate will need a new texture on the texture sheet.
>>> The above screenshot I've shown requires a 4096x4096 texture sheet in
>>> order to render in JavaFX, and it's a pretty small scene! I've got
>>> significantly larger scenes which I'm completely unable to render with
>>> shading because I need to generate a texture sheet more than a gigabyte
>>> large in order to shade it properly.
>>> And forget about any kind of common texCoord/UV animations. The CPU
>>> needs to be constantly redrawing shading textures onto the texture sheet in
>>> order to ensure animations have the correct shading.
>>> For the above example, trying to animate the lava to flow down the
>>> screen as it's supposed to brings my FPS below 30.
>>> This is despite the texture drawing process having run in parallel and
>>> extensive performance profiling on my part. I've concluded there's no way
>>> to get around having proper vertex color support as the main bottleneck is
>>> just sending such a massively large image to the GPU so frequently as well
>>> as having to actually shade the images still taking a pretty decent amount
>>> of time even when done in parallel. And remember, these performance issues
>>> are happening on one of my small scenes.
>>>
>>> Normally drawing vertex colors like this is extremely fast (even on 30
>>> year old hardware!) when done by the GPU/dedicated hardware, but JavaFX
>>> just doesn't provide a way to do it with the GPU.
>>> JavaFX is also the only mainstream 3D library I could find which lacks
>>> this feature.
>>> There are 3D environments I cannot even display with shading right now
>>> at all due to the sheer amount of large textures that need to have shading
>>> manually drawn onto them.
>>> This cannot be solved by using a project like Fxyz
>>> <https://github.com/FXyz/FXyz>, since it just comes down to the texture
>>> sheets being too large.
>>> These scenes aren't even particularly large either, having been made for
>>> game consoles in the range of 20-30 years ago.
>>>
>>> This will happen to anyone who needs to use vertex coloring with a
>>> significant number of textures, and requires writing a lot of code to
>>> manage texture sheets to ultimately just for it to only partially suffice.
>>>
>>> There are other reasons to want vertex coloring outside of compatibility
>>> with other software too.
>>> Vertex coloring can often be used to add significant mesh details.
>>> In the above example, I've already demonstrated how this can be used to
>>> add details such as rust, fade-outs, etc. But there are many more ways to
>>> include it too, such as using art styles with flat textures, such as for
>>> clouds, cartoon art-styles, etc. It's even possible to create shadows by
>>> using darker colors in areas obscured by others. There are so many clever
>>> ways this can be used, and I'd spend too much time on individual examples.
>>> The reason vertex colors have been so prevalent is specifically because of
>>> the payoff between how easy they are to add and how much can be achieved
>>> with them.
>>> I'm not enough of an artist to explain everything with words, but I can
>>> certainly give a lot of examples via screenshot, if desired.
>>>
>>> Since the guideline was to tailor this pitch to the JavaFX community, I
>>> thought I'd include mention of a few JavaFX projects that I thought would
>>> benefit significantly. There were others that would benefit in less
>>> significant ways, so I tried to keep it brief:
>>>  - Fxyz <https://github.com/FXyz/FXyz>: Probably the most popular
>>> JavaFX 3D project.
>>>  - GameExtractor <https://github.com/wattostudios/GameExtractor/>:
>>> Capable of showing 3D objects in many common formats (.obj, .3ds, Unity
>>> Format, Unreal Engine 2/3 Format, etc), but is unable to show vertex colors
>>> due to JavaFX's lack of support.
>>> -  FrogLord <https://github.com/Kneesnap/FrogLord>: This is my project,
>>> but every single game I support desperately needs this feature in order to
>>> accurately preview the custom levels as they are edited, so the user can
>>> see how they will appear in their game.
>>>
>>> Pretty much any project which creates texture sheets containing
>>> interpolated colors will benefit from this change as in many cases they
>>> won't need to do that anymore.
>>> Due to the reduced time and memory usage it will also become
>>> significantly more feasible/performant to use meshes which change over time
>>> as well, since fewer changes to the texture sheet will be required, if any
>>> at all.
>>>
>>> I also imagine this fitting in very easily with the existing API, as
>>> pretty much all of the public facing APIs could just have a few new methods
>>> in them, without needing to change any pre-existing APIs at all.
>>>
>>> In summary,
>>> Vertex colors are a feature as ubiquitous in the 3D world as texture
>>> coordinates, lighting, and materials, yet JavaFX doesn't have them.
>>> Adding them will allow for a significant amount of detail for virtually
>>> no performance or maintenance cost, and for some projects it will even
>>> improve performance & simplify texture sheets.
>>>
>>> Additional Note:
>>> https://bugs.openjdk.org/browse/JDK-6586559
>>> It looks like this feature may have already been planned at one point,
>>> but was forgotten due to being low-priority? I don't know.
>>>
>>> What does everyone think about this proposal? I eagerly await responses!
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/71708727/attachment-0001.htm>

From michaelstrau2 at gmail.com  Wed Aug 21 05:50:56 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 21 Aug 2024 07:50:56 +0200
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
Message-ID: <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>

Vertex colors usually refers to a technique where the vertex format is
enriched with an additional color component, and this color component is
then used in one of the shader stages to affect the computation in some way
(usually by combining it with the texture color).

As you correctly say, this technique is decades-old, it existed even back
in the days of fixed function pipelines.

However, with the introduction of programmable shaders, the structure of
vertices can be freely defined by developers. It seems to me that your
proposed API would pick just one (maybe useful) scenario, and eternally
bake it into JavaFX APIs. What if we get custom shaders one day? Then we
would need a way to customize the vertex format again.

Currently we have two predefined vertex formats:
VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD.
It doesn't seem obvious to me that the best way forward is to add more
bespoke formats here.

Have you thought about ways how we could allow deverlopers to define custom
formats? Maybe that would also require a new kind of Mesh that can accept
custom data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240821/c8feec61/attachment.htm>

From sykora at openjdk.org  Wed Aug 21 06:17:13 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 21 Aug 2024 06:17:13 GMT
Subject: RFR: 8338306: WebView Drag and Drop fails with WebKit 619.1 [v2]
In-Reply-To: <MC16lW-yT3kKO_Xtwvbh3rWyeLyj_5ezQdyjp5zesjI=.2d0aafb6-825b-4682-a907-573e9f7be9c5@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
 <MC16lW-yT3kKO_Xtwvbh3rWyeLyj_5ezQdyjp5zesjI=.2d0aafb6-825b-4682-a907-573e9f7be9c5@github.com>
Message-ID: <K6saoo0pI-gumMnwXO9wguB3hMzzzZNd_MtQcL6L8Hk=.da8d37b8-5d5c-4905-b444-9c28afc2ee0e@github.com>

On Tue, 20 Aug 2024 14:04:29 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate call

Looking good.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1538#pullrequestreview-2249809325

From hmeda at openjdk.org  Wed Aug 21 06:41:11 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 21 Aug 2024 06:41:11 GMT
Subject: Integrated: 8338306: WebView Drag and Drop fails with WebKit 619.1
In-Reply-To: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
References: <8CaOxQMBFbn8QzFw3wcLL3sKazKInvpIEfeTuLn1FWY=.fbb56149-29fe-4f24-9164-1bd4475ee9e4@github.com>
Message-ID: <ZcYdGFduIni3Ft4B72gTtYHT-kdg8fog6AmwZ03Bv0Q=.772c6300-d261-4cb2-bd68-82e789018e14@github.com>

On Mon, 19 Aug 2024 09:32:22 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This commit resolves drag and drop issue observed with Webkit-619.1. Verified build on all platforms. No issue seen

This pull request has now been integrated.

Changeset: 67ac9d78
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8338306: WebView Drag and Drop fails with WebKit 619.1

Reviewed-by: kcr, sykora

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

PR: https://git.openjdk.org/jfx/pull/1538

From kneester77 at gmail.com  Wed Aug 21 06:49:33 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Tue, 20 Aug 2024 23:49:33 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
Message-ID: <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>

Hi Michael,

Thanks for the response!

*> Have you thought about ways how we could allow deverlopers to define
custom formats? Maybe that would also require a new kind of Mesh that can
accept custom data.*
Yep, and while I'd very much like this eventually, this cannot occur before
user-supplied shaders are supported since otherwise there'd be nothing done
with any user-configured data. User-supplied shaders would be a very large
amount of work in many different aspects.
For example, there isn't even currently a way to tell if the 3D backend
JavaFX has running is OpenGL or Direct3D, let alone manage shaders.
I don't know that I'm qualified to even implement something so large for an
open-source immutable API yet. And, it would also ask more from
developers who utilize JavaFX, as they now need to write shaders for each
supported backend, and juggle a lot objects & concepts more when it comes
to rendering.
I still see value in keeping a platform-agnostic shader-free TriangleMesh
which has vertex coloring even after a hypothetical user-supplied shader
system, which could co-exist separate from the "TriangleMesh" as perhaps a
new "AdvancedTriangleMesh" class.
Now here's where I think you've brought up an interesting point and I'll
counter with a slight change to my design.

*> However, with the introduction of programmable shaders, the structure of
vertices can be freely defined by developers. It seems to me that your
proposed API would pick just one (maybe useful) scenario, and eternally
bake it into JavaFX APIs. What if we get custom shaders one day? Then we
would need a way to customize the vertex format again.*
Yes! It is just one scenario and shaders are the dream, but I still believe
it's worth baking into the JavaFX API due to how useful it is, I imagine
that this feature can co-exist separately from the hypothetical
user-supplied shader support.
I mentioned before in a previous email that I don't think having vertex
colors takes away from the ideal future where custom shaders are supported.
Since there seems to be a concern here, I'll expand upon what I meant by
that.

The current TriangleMesh.java is equivalent to a non-shader fixed rendering
pipeline, as it has an explicitly defined group of buffers. Some of which
(normals) are already optional.
The design of the future user-supplied shader system has not been made
worse by supporting vertex colors, as we already have the same exact
eternally baked API already inside TriangleMesh.java.

It's true though that TriangleMesh's existing buffers are mostly applicable
to pretty much every future shader, but it's not entirely the case.
Normals are also currently optional, and also might not be desired by
certain custom shaders when it's time. I'll concede that normals are
somewhat more common than vertex colors, but it's the same problem in the
same file.

Initially because of this observation about normals, my thought was that
TriangleMesh wouldn't be the parent class of any future mesh with shader
support. There would be two separate mesh base classes, TriangleMesh (fixed
capabilities), and something like AdvancedTriangleMesh (allowing
user-specified shaders).
Any solution which was good enough for normals is also good enough for
vertex colors right?

Well, after your critique, I've come up with another option, I'm curious if
you prefer this one.
Instead of modifying TriangleMesh.java and having an unrelated
AdvancedTriangleMesh class in the future, this one can consider that just
because normals are in TriangleMesh.java a bad thing doesn't mean vertex
colors need to clog it further.
So, I'd instead create "GouraudShadedTriangleMesh" which extends
TriangleMesh, and it's what would contain the vertex buffer, etc. So it can
have the coloring, and also allow a future AdvancedTriangleMesh to extend
the original TriangleMesh without having a hint of the vertex color buffer.

I believe this should adequately address why I think this is good to have
in the API forever.

*> Currently we have two predefined vertex formats:
VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD. It
doesn't seem obvious to me that the best way forward is to add more bespoke
formats here.*
I partially agree, and partially disagree. I agree that we should not be
adding VertexFormat options left and right. But the only other scenario I
can imagine as theoretically adding more VertexFormats is if it became time
to support quads. Either that or a new user-supplied shader system, but
that isn't really relevant.
Vertex colors feel to me like the final missing piece before the current
non-custom shader mesh support is fully featured, so I don't think it's
unreasonable to add new VertexFormat entries.
In theory it would be possible with the "GouraudShadedTriangleMesh" idea to
not actually create any new VertexFormat object/functionality, and keep
such functionality within the "GouraudShadedTriangleMesh" class itself.
Personally I think it depends entirely on the decision of "Would a
potential future user-supplied shader system extend TriangleMesh or should
it be its own thing?"

Thanks again for the feedback!


On Tue, Aug 20, 2024 at 10:51?PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> Vertex colors usually refers to a technique where the vertex format is
> enriched with an additional color component, and this color component is
> then used in one of the shader stages to affect the computation in some way
> (usually by combining it with the texture color).
>
> As you correctly say, this technique is decades-old, it existed even back
> in the days of fixed function pipelines.
>
> However, with the introduction of programmable shaders, the structure of
> vertices can be freely defined by developers. It seems to me that your
> proposed API would pick just one (maybe useful) scenario, and eternally
> bake it into JavaFX APIs. What if we get custom shaders one day? Then we
> would need a way to customize the vertex format again.
>
> Currently we have two predefined vertex formats:
> VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD.
> It doesn't seem obvious to me that the best way forward is to add more
> bespoke formats here.
>
> Have you thought about ways how we could allow deverlopers to define
> custom formats? Maybe that would also require a new kind of Mesh that can
> accept custom data.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240820/7c428a6e/attachment-0001.htm>

From sykora at openjdk.org  Wed Aug 21 08:05:10 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 21 Aug 2024 08:05:10 GMT
Subject: RFR: 8336632: Update Gradle to 8.9 [v3]
In-Reply-To: <p3DmtQepGkZv8A9khhgBt97OjZw8lxC9GfxghRGb-DM=.bd443eaf-f987-4b73-bb68-5f251b961609@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
 <p3DmtQepGkZv8A9khhgBt97OjZw8lxC9GfxghRGb-DM=.bd443eaf-f987-4b73-bb68-5f251b961609@github.com>
Message-ID: <NwuwhtZ4VpwERsa0Buacuyr_2kyVG9eJe4mb6kmlgQw=.c1b4d11f-5778-435f-bfc5-a2dcdb24f0c2@github.com>

On Tue, 20 Aug 2024 16:53:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Gradle 8.8 released on May 31, 2024, supports JDK 22.
>> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
>> 
>> This gradle update is required in order to update the boot jdk to 22.0.2.
>> The changes are minimal, no source code changes were required.
>> 
>> This PR also includes the boot jdk update.
>
> Ambarish Rapte has updated the pull request 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. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into gradle89-jdk2202
>  - win bootjdk gha
>  - chmod 644 gradlew
>  - gradle 89, jdk 2202
>  - revert gradle-wrapper.properties partially
>  - gradle 8.9

All builds succeeded with the newest gradle and JDK 22.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1539#pullrequestreview-2250075324

From arapte at openjdk.org  Wed Aug 21 09:32:14 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 21 Aug 2024 09:32:14 GMT
Subject: Integrated: 8336632: Update Gradle to 8.9
In-Reply-To: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
References: <mxO09g3gc8vbdRFGdMOqEXJ9WDkX83W1wui4bkswvLY=.f39e6356-7c7b-4424-85b0-90d4474cad50@github.com>
Message-ID: <iC6CiLnHCiiZYFvSQlLO0E20xieQpi258NqpGnqSd-E=.717af0ab-6a6c-463a-be92-4eac433c58e9@github.com>

On Tue, 20 Aug 2024 02:59:00 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Gradle 8.8 released on May 31, 2024, supports JDK 22.
> On Jul 11, 2024, gradle 8.9 was released too, so we can update to the latest gradle 8.9 
> 
> This gradle update is required in order to update the boot jdk to 22.0.2.
> The changes are minimal, no source code changes were required.
> 
> This PR also includes the boot jdk update.

This pull request has now been integrated.

Changeset: b8987310
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b8987310dfff28b7a1a3862868c2d2210063985d
Stats:     35 lines in 7 files changed: 5 ins; 0 del; 30 mod

8336632: Update Gradle to 8.9
8336633: Update boot JDK to 22.0.2

Reviewed-by: kcr, sykora

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

PR: https://git.openjdk.org/jfx/pull/1539

From tsayao at openjdk.org  Wed Aug 21 09:58:53 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 21 Aug 2024 09:58:53 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v22]
In-Reply-To: <AoaBb1Z_1_qsKNES4wvjk2TgqWbjmX6FSho4yV5ViNM=.c592d37e-7f6a-4224-ac30-be7ba55c4631@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com>
 <49JoG8Omv2OCPAZpeWwO4Q1c7K3WGzhGkgu6VBK50GE=.94972da3-3640-41ea-b983-b60d564b0f7b@github.com>
 <LEzMDkfq__OccvxP1rAjHqRChh-n4cmaR-eLNFnQWWY=.660302f2-2a6a-4deb-a5e2-a8f18866d657@github.com>
 <XiqyxBylC1tdYeLT_NVnDHkS6wBXwVUn7tiFwRBlZrw=.dd52fcb9-503d-4484-a6ee-b461a406a374@github.com>
 <ri9SFUBbOW8TU_sK1gbO8kd3i0Af7TazOYzySHrbvFk=.a9138b55-a26f-4acf-b6f8-5928895d2e90@github.com>
 <AoaBb1Z_1_qsKNES4wvjk2TgqWbjmX6FSho4yV5ViNM=.c592d37e-7f6a-4224-ac30-be7ba55c4631@github.com>
Message-ID: <HXefjnas7HwhrMaKBe-WeelACPxms-zUMCLO7A90Atk=.a3d67c15-db8b-456f-8535-5a63463bb633@github.com>

On Mon, 19 Aug 2024 17:39:38 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> on mac and windows the coordinates can be negative, depending on the screen arrangement.
>> 
>> why do we need to rely on the fact that `pos[]` values are positive anyway?
>
> I was able to set up a multiple monitor system. Linux does work differently than Mac or Windows but the X coordinate returned by View can still be negative if the window is partially off the left edge of the leftmost screen. But in that case the Window's X coordinate will also be negative so subtracting it out will generate the correct widget-relative location. So I suggest removing the conditional checks here.

Removed (the negative checks)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1724776588

From tsayao at openjdk.org  Wed Aug 21 09:58:53 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 21 Aug 2024 09:58:53 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v25]
In-Reply-To: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
Message-ID: <IoPDhdyO_OqkraxpObNmCbYAVTScdkSD3cgAXf8_l9Q=.44da8b2e-8392-4061-a561-0a15cdd84e6c@github.com>

> This replaces obsolete XIM and uses gtk api for IME.
> Gtk uses [ibus](https://github.com/ibus/ibus)
> 
> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`.
> 
> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remove negative checks

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1080/files
  - new: https://git.openjdk.org/jfx/pull/1080/files/1e990a62..42aa37ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=24
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=23-24

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

PR: https://git.openjdk.org/jfx/pull/1080

From dlemmermann at gmail.com  Wed Aug 21 10:26:50 2024
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 21 Aug 2024 12:26:50 +0200
Subject: Label Text Selection
In-Reply-To: <B01096D6-739D-4C24-9BB2-46D4B0AA0DFE@gmail.com>
References: <9CE10DA5-D59A-4B9F-AC5B-163F521341D4@gmail.com>
 <trinity-73509c63-f837-4402-ac38-0952c283e0c8-1724058133307@3c-app-webde-bap10>
 <B01096D6-739D-4C24-9BB2-46D4B0AA0DFE@gmail.com>
Message-ID: <BB5164D2-25FE-4C6A-93C5-229098632619@gmail.com>

Now that I have a text control with selection support I can solve many of my issues, but not all of them. I still feel like it would be extremely useful if ?Text? would support selection out of the box (off by default, enabled via API or CSS).

Dirk


> On 20 Aug 2024, at 16:09, Dirk Lemmermann <dlemmermann at gmail.com> wrote:
> 
> I have taken quizynox approach and used it for the TextView control in GemsFX. After some additions the control now supports a text selection behaviour similar to the one found in TextArea (ctrl-c, ctrl-a, stylable ?highlight? properties, double click for word selection, triple click for paragraph selection, etc?). 
> 
> Dirk
> 
> 
>> On 19 Aug 2024, at 11:02, Marius Hanl <mariushanl at web.de> wrote:
>> 
>> I also think this might be a good addition to the JFX Core.
>> This behavior should be off by default, but can be turned on via CSS or Code.
>> Another idea could be a new Control that extends from Label.
>>  
>> -- Marius
>>  
>>  
>> Gesendet: Freitag, 16. August 2024 um 12:12 Uhr
>> Von: "Dirk Lemmermann" <dlemmermann at gmail.com>
>> An: "openjfx-dev" <openjfx-dev at openjdk.org>
>> Betreff: Label Text Selection
>> Hi everyone,
>> 
>> I recently added a custom text control (called ?TextView") to the GemsFX project. It supports a somewhat limited text selection. Selection is only possible on a per-word basis. I received a bit of feedback on this control and I was wondering whether it would be worth thinking about adding a general text selection capability to labels. Is this something worth looking into? Is it even feasible?
>> 
>> I guess one of the reasons why this topic keeps popping up is the fact that users are so used to selecting any text in web pages, but they can?t do it in desktop apps.
>> 
>> Dirk
>>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240821/edb74a2c/attachment.htm>

From almatvee at openjdk.org  Wed Aug 21 21:18:56 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 Aug 2024 21:18:56 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6
Message-ID: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>

- Updated GStreamer to 1.24.6 and Glib to 2.80.4.
- Testing done on all platforms with all supported formats.
- Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
- Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
- No other changes or bug fixes are done.

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

Commit messages:
 - 8336940: Update GStreamer to 1.24.6 [v2]
 - 8336940: Update GStreamer to 1.24.6

Changes: https://git.openjdk.org/jfx/pull/1542/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336940
  Stats: 24626 lines in 329 files changed: 13058 ins; 6878 del; 4690 mod
  Patch: https://git.openjdk.org/jfx/pull/1542.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1542/head:pull/1542

PR: https://git.openjdk.org/jfx/pull/1542

From kcr at openjdk.org  Wed Aug 21 21:18:56 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Aug 2024 21:18:56 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6
In-Reply-To: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
Message-ID: <hjlSFllulvCdtSKzUtjU5HnuFIsNvZrC2QjwxYCkTyc=.d277edf0-87fb-409c-9463-4463b87f7bac@github.com>

On Wed, 21 Aug 2024 20:15:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
> - Testing done on all platforms with all supported formats.
> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
> - No other changes or bug fixes are done.

Reviewers: @kevinrushforth and @tiainen or @johanvos

I get a compilation error on my admittedly too-old Ubuntu 16.04 system. It might be worth adding the missing header file, in case other distros hit the same problem.


In file included from ../../../gstreamer-lite/gstreamer/gst/gstmeta.h:28,
                 from ../../../gstreamer-lite/gstreamer/gst/gstbuffer.h:43,
                 from ../../../gstreamer-lite/gstreamer/gst/gstpad.h:70,
                 from ../../../gstreamer-lite/gstreamer/gst/gstelement.h:223,
                 from ../../../gstreamer-lite/gstreamer/gst/gstbin.h:27,
                 from ../../../gstreamer-lite/gstreamer/gst/gst.h:35,
                 from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbitreader.h:24,
                 from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbitreader.c:26:
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h: In function 'gst_byte_array_interface_init':
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:66:3: error: implicit declaration of function 'memset' [-Werror=implicit-function-declaration]
   66 |   memset (self, 0, sizeof (GstByteArrayInterface));
      |   ^~~~~~
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:1:1: note: include '<string.h>' or provide a declaration of 'memset'
  +++ |+#include <string.h>
    1 | /* Copyright (C) 2023 Netflix Inc.
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:66:3: warning: incompatible implicit declaration of built-in function 'memset' [-Wbuiltin-declaration-mismatch]
   66 |   memset (self, 0, sizeof (GstByteArrayInterface));
      |   ^~~~~~
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:66:3: note: include '<string.h>' or provide a declaration of 'memset'
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h: In function 'gst_byte_array_interface_append_data':
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:125:3: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration]
  125 |   memcpy (ptr, data, size);
      |   ^~~~~~
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:125:3: note: include '<string.h>' or provide a declaration of 'memcpy'
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:125:3: warning: incompatible implicit declaration of built-in function 'memcpy' [-Wbuiltin-declaration-mismatch]
../../../gstreamer-lite/gstreamer/gst/gstbytearrayinterface.h:125:3: note: include '<string.h>' or provide a declaration of 'memcpy'
cc1: some warnings being treated as errors
Makefile:281: recipe for target 'modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gstreamer/libs/gst/base/gstbitreader.o' failed
make: *** [modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gstreamer/libs/gst/base/gstbitreader.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory 'modules/javafx.media/src/main/native/gstreamer/projects/linux/gstreamer-lite'

> Task :media:buildLinuxGStreamer FAILED

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

PR Comment: https://git.openjdk.org/jfx/pull/1542#issuecomment-2302940315
PR Comment: https://git.openjdk.org/jfx/pull/1542#issuecomment-2302994966

From almatvee at openjdk.org  Wed Aug 21 21:36:52 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 Aug 2024 21:36:52 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6 [v2]
In-Reply-To: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
Message-ID: <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>

> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
> - Testing done on all platforms with all supported formats.
> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
> - No other changes or bug fixes are done.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8336940: Update GStreamer to 1.24.6 [v3]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1542/files
  - new: https://git.openjdk.org/jfx/pull/1542/files/8d505f81..1e5499a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1542&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1542&range=00-01

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

PR: https://git.openjdk.org/jfx/pull/1542

From almatvee at openjdk.org  Wed Aug 21 21:48:08 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 Aug 2024 21:48:08 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6 [v2]
In-Reply-To: <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
 <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
Message-ID: <GX6Xy1fucPGQJ5hUh9A1pfp0kzgC84YKkbKrby8IqKg=.e1e61e7b-32d3-4b34-b5cf-d56e10dc1255@github.com>

On Wed, 21 Aug 2024 21:36:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
>> - Testing done on all platforms with all supported formats.
>> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
>> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
>> - No other changes or bug fixes are done.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336940: Update GStreamer to 1.24.6 [v3]

8336940: Update GStreamer to 1.24.6 [v2]
 - Fixed whitespace.

8336940: Update GStreamer to 1.24.6 [v3]
- Added missing header file.

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

PR Comment: https://git.openjdk.org/jfx/pull/1542#issuecomment-2303064728

From kcr at openjdk.org  Wed Aug 21 22:20:06 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Aug 2024 22:20:06 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6 [v2]
In-Reply-To: <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
 <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
Message-ID: <1r4tguBQ0ZCnq0ZOt6Bj9JmDilpGkgcTn2JsBYcdjow=.01686026-b9ac-4669-9bb3-45de0b7b32e1@github.com>

On Wed, 21 Aug 2024 21:36:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
>> - Testing done on all platforms with all supported formats.
>> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
>> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
>> - No other changes or bug fixes are done.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336940: Update GStreamer to 1.24.6 [v3]

Looks good. Built and tested on all three platforms.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1542#pullrequestreview-2252052131

From almatvee at openjdk.org  Wed Aug 21 22:20:10 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 21 Aug 2024 22:20:10 GMT
Subject: [jfx23u] Integrated: 8336938: Update libFFI to 3.4.6
In-Reply-To: <v_1S3EDV42O3Ee2-qFBitm6qph9B-vFUvaimfh06v6I=.26124aef-fae0-44a1-8b38-171e425d4d10@github.com>
References: <v_1S3EDV42O3Ee2-qFBitm6qph9B-vFUvaimfh06v6I=.26124aef-fae0-44a1-8b38-171e425d4d10@github.com>
Message-ID: <J_OpxTVP0DQQBTnSnPeR2to4cQHbFQRPX66657fbLuQ=.8bd554c1-8de3-4e08-97a8-42891478ff85@github.com>

On Wed, 21 Aug 2024 01:15:49 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Clean backport of JDK-8336938.

This pull request has now been integrated.

Changeset: 499fb77b
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/499fb77b16de1145cd0b8b5adad0995a8ba8f403
Stats:     1056 lines in 26 files changed: 388 ins; 373 del; 295 mod

8336938: Update libFFI to 3.4.6

Backport-of: f1bac5a829e1f2b75b863c4f0822bf418107a1fb

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

PR: https://git.openjdk.org/jfx23u/pull/11

From john.hendrikx at gmail.com  Thu Aug 22 03:24:49 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 22 Aug 2024 05:24:49 +0200
Subject: Accidentally reproduced NPE in synchronizeNodes in combination with
 enterNestedEventLoop
Message-ID: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>

Hi List,

This is a bit of a long post. I'm mainly wondering if I did something 
wrong that FX should detect early, or if I'm doing nothing unusual and 
FX should handle the case described below correctly.

I encountered the bug where an NPE occurs in 
Scene$ScenePulseListener#synchronizeNodes, and it is reproducable at the 
moment. I'm not sure it is the same one others sometimes see, but the 
version I encountered is prefaced with a failing assert (which may 
easily get lost as synchronizeNodes will spam NPE's in your log, as it 
doesn't recover).

In Parent#validatePG it prints:

 ??? *** pgnodes.size validatePG() [1] != children.size() [2]

And then throws an AssertionError with a long stacktrace.

 ??? java.lang.AssertionError: validation of PGGroup children failed
 ??????? (stack trace omitted)

Immediately after this, the NPE in synchronizeNodes starts to get 
spammed, and the application never recovers.

This seems to have something to do with nested event loops, as I 
introduced a new one in the code involved.? When I remove the nested 
event loop, there is no problem (it also initially works fine when the 
application is just starting, only in a different situation, when there 
is some user interaction via a keypress, does the bug trigger).

The nested event loop is entered from a ChangeListener, which may be a 
bit unusual.? The documentation of Platform#enterNestedEventLoop says:

* This method must either be called from an input event handler or

* from the run method of a Runnable passed to

* {@link javafx.application.Platform#runLater Platform.runLater}.

* It must not be called during animation or layout processing.

It is also documented to throw an IllegalStateException if used 
incorrectly.? That is however not happening, so I guess I'm using it 
correctly...?? On the other hand, I'm not in an input event 
handler....?the whole process is triggered by a keypress though, and 
deep down in the AssertionError trace you can see:

 ? ? at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
 ??? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
 ? ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
 ??? at javafx.event.Event.fireEvent(Event.java:198)
 ? ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
 ? ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
 ??? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
 ? ? at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)

So IMHO?technically I am in an input event handler...?

Now the code does a LOT of stuff, which is going to make this tough to 
analyze.? In short:

- I'm displaying a Scene
- The user indicates (with a keypress) they want to go to a different Pane
- The previous Pane is created, and added to the scene as a child to a 
TransitionPane that will cross-fade between the current Pane and the new 
Pane
- As soon as the new Pane becomes part of the Scene, lots of things get 
triggered because the Scene property goes from null to the active Scene:

 ? ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
 ? ? at javafx.scene.Node.setScenes(Node.java:1142) <-- the new Pane 
will get a Scene assigned to it
 ??? at javafx.scene.Parent$2.onChanged(Parent.java:372) <-- the new 
Pane has its Parent changed to the TransitionPane

- Several parts of the new Pane listen (directly or indirectly) to a 
change in Scene, as they only become "active" when the Node involved is 
displayed (this happens with a Scene listener)
- One of those things is some code that will create and populate a 
ListView; this code uses a relatively fast query, but I had marked it as 
something that should be done in the background as it sometimes does 
take a bit too much time on the FX thread

Now, how I normally do things in the background is to display an 
automatically closing "Please wait" dialog potentially with a progress 
bar on it (this dialog is actually invisible, unless sufficient time 
passes, so in 99% of the cases when things respond fast, the user never 
sees it, even though it was created and is there).? This involves 
starting a nested event loop.? This works marvelously throughout this 
application (and has done so for years), and it is used for almost every 
transition from one part of the application to the next.? In all cases 
so far however I did this directly from an event handler.

So the main difference is that I'm trying to enter a nested event loop 
from a ChangeListener (which deep down was triggered by an Event).? In 
the AssertionError stack trace (which I will include at the end), there 
is no layout or animation code **before** entering the nested loop, 
although there is some layout code **after** it was entered.

I can live with the fact that I may be using enterNestedEventLoop 
incorrectly here, but in that case it should probably also detect this 
incorrect use?and throw the IllegalStateException.

Technically, all this code is triggered while "adding" a Child to the 
TransitionPane, so I suspect that is what the AssertionError is about 
(it indicates the child count 1 != 2, which is what TransitionPane has, 
one active pane, and just added to cross fade to).? Still, is this 
really incorrect usage?

I've included an annotated stack trace below.

As it is quite reproducable, I can debug this further by adding 
breakpoints/prints -- I'm just unsure where to start looking.

--John

java.lang.AssertionError: validation of PGGroup children failed
 ? at javafx.scene.Parent.validatePG(Parent.java:243)
 ? at javafx.scene.Parent.doUpdatePeer(Parent.java:201)
 ? at javafx.scene.Parent$1.doUpdatePeer(Parent.java:109)
 ? at com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78)
 ? at 
com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72)
 ? at com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:104)
 ? at javafx.scene.Node.syncPeer(Node.java:721)
 ? at 
javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2396)
 ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
 ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
 ? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
 ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
 ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
 ? at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
 ? at 
com.sun.glass.ui.win.WinApplication._enterNestedEventLoopImpl(Native Method)
 ? at 
com.sun.glass.ui.win.WinApplication._enterNestedEventLoop(WinApplication.java:211)
 ? at 
com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:515)
 ? at com.sun.glass.ui.EventLoop.enter(EventLoop.java:107)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:631)
 ? at javafx.application.Platform.enterNestedEventLoop(Platform.java:301)
 ? at 
hs.mediasystem.util.javafx.SceneUtil.enterNestedEventLoop(SceneUtil.java:75) 
<-- just my wrapper to trace slow calls, it delegates to Platform
 ? at hs.mediasystem.runner.dialog.DialogPane.showDialog(DialogPane.java:78)
 ? at 
hs.mediasystem.runner.dialog.Dialogs.showProgressDialog(Dialogs.java:163)
 ? at hs.mediasystem.runner.dialog.Dialogs.runNested(Dialogs.java:103)
 ? at 
hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$1(HomeScreenNodeFactory.java:123) 


The above line is where the nested event loop is entered.? It starts to 
display a "busy" dialog. A background task (on a new thread) will create 
a ListView (this never actually happens, the AssertionError is thrown 
immediately even with an empty task that just sleeps 10 seconds).

 ? at 
com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at 
javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
 ? at 
javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
 ? at 
javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
 ? at 
javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
 ? at 
javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105)
 ? at 
javafx.scene.control.MultipleSelectionModelBase.lambda$new$0(MultipleSelectionModelBase.java:67)
 ? at 
com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at 
javafx.beans.property.ReadOnlyIntegerPropertyBase.fireValueChangedEvent(ReadOnlyIntegerPropertyBase.java:78)
 ? at 
javafx.beans.property.ReadOnlyIntegerWrapper.fireValueChangedEvent(ReadOnlyIntegerWrapper.java:102)
 ? at 
javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:114)
 ? at 
javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
 ? at 
javafx.scene.control.SelectionModel.setSelectedIndex(SelectionModel.java:69)
 ? at 
javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:424)
 ? at 
javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:456)
 ? at 
hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$3(HomeScreenNodeFactory.java:176) 
<-- triggers the creation of a ListView
 ? at javafx.beans.value.ObservableValue.lambda$0(ObservableValue.java:364)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at 
com.sun.javafx.binding.ConditionalBinding.conditionChanged(ConditionalBinding.java:53)
 ? at com.sun.javafx.binding.Subscription.lambda$2(Subscription.java:63)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at 
com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
 ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at 
com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
 ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
 ? at 
com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at 
javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
 ? at 
javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
 ? at 
javafx.scene.Node$ReadOnlyObjectWrapperManualFire.fireSuperValueChangedEvent(Node.java:1053) 
<-- there is a listener on a Scene property
 ? at javafx.scene.Node.invalidatedScenes(Node.java:1104)
 ? at javafx.scene.Node.setScenes(Node.java:1142)
 ? at javafx.scene.Parent.scenesChanged(Parent.java:772)??? <-- the new 
Pane has a few nested Panes, so you see multiple Parent assignments
 ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
 ? at javafx.scene.Node.setScenes(Node.java:1142)
 ? at javafx.scene.Parent.scenesChanged(Parent.java:772)
 ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
 ? at javafx.scene.Node.setScenes(Node.java:1142)??????????? <-- the 
Parent is part of a Scene, so this new Pane also gets the same Scene 
assigned
 ? at javafx.scene.Parent$2.onChanged(Parent.java:372)??? <-- the new 
Pane gets its parent assigned (TransitionPane)
 ? at 
com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:45)
 ? at 
com.sun.javafx.collections.ListListenerHelper$Generic.fireValueChangedEvent(ListListenerHelper.java:329)
 ? at 
com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:73)
 ? at 
javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:239)
 ? at 
javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
 ? at 
javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
 ? at 
javafx.collections.ObservableListBase.endChange(ObservableListBase.java:211)
 ? at 
javafx.collections.ModifiableObservableListBase.add(ModifiableObservableListBase.java:162)
 ? at 
com.sun.javafx.collections.VetoableListDecorator.add(VetoableListDecorator.java:319)
 ? at 
hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:94) 
<-- new Pane is added to a TransitionPane that handles cross fade 
between old and new Pane
 ? at 
hs.mediasystem.util.javafx.ui.transition.TransitionPane.addAtStart(TransitionPane.java:105)
 ? at 
hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:113)
 ? at 
hs.mediasystem.runner.presentation.ViewPort.updateChildNode(ViewPort.java:68) 
<-- here it installs the new Pane to display
 ? at hs.mediasystem.runner.presentation.ViewPort.lambda$0(ViewPort.java:39)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
 ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
 ? at 
com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
 ? at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
 ? at 
javafx.beans.property.ObjectPropertyBase.fireValueChangedEvent(ObjectPropertyBase.java:111)
 ? at 
javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
 ? at 
javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
 ? at 
hs.mediasystem.presentation.ParentPresentation.navigateBack(ParentPresentation.java:39) 
<-- this handles the keyPress (it was a "back" press)
 ? at hs.mediasystem.util.expose.Expose.lambda$3(Expose.java:55)
 ? at hs.mediasystem.util.expose.Trigger$1.run(Trigger.java:58)
 ? at 
hs.mediasystem.runner.RootPresentationHandler.tryRunAction(RootPresentationHandler.java:106)
 ? at 
hs.mediasystem.runner.RootPresentationHandler.handleActionEvent(RootPresentationHandler.java:81)
 ? at 
com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
 ? at 
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
 ? at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
 ? at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
 ? at 
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
 ? at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
 ? at hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) 
<-- this is just my Slow Event detection, and just delegates the event
 ? at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
 ? at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
 ? at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
 ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
 ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
 ? at hs.mediasystem.util.javafx.base.Events.dispatchEvent(Events.java:35)
 ? at 
hs.mediasystem.runner.action.InputActionHandler.handleKeyEvent(InputActionHandler.java:153) 
<-- just code that handles a?keypress that bubbled all the way to the top
 ? at 
hs.mediasystem.runner.action.InputActionHandler.onKeyPressed(InputActionHandler.java:138)
 ? at 
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
 ? at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
 ? at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
 ? at 
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
 ? at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
 ? at hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) 
<-- this is just my Slow Event detection, and just delegates the event
 ? at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
 ? at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
 ? at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
 ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
 ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
 ? at javafx.event.Event.fireEvent(Event.java:198)
 ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
 ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
 ? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
 ? at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)
 ? at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:150)
 ? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
 ? at 
com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleKeyEvent$1(GlassViewEventHandler.java:250)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
 ? at 
com.sun.javafx.tk.quantum.GlassViewEventHandler.handleKeyEvent(GlassViewEventHandler.java:249)
 ? at com.sun.glass.ui.View.handleKeyEvent(View.java:542)
 ? at com.sun.glass.ui.View.notifyKey(View.java:966)
 ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
 ? at 
com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
 ? at java.base/java.lang.Thread.run(Thread.java:1583)

And the NPE exception:

java.lang.NullPointerException: Cannot invoke 
"javafx.scene.Node.getScene()" because "<local2>" is null
 ?? ?at 
javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
 ?? ?at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
 ?? ?at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
 ?? ?at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
 ?? ?at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
 ??? (rest of trace identical to the AssertionError one)

And another variant of the NPE exception:

java.lang.NullPointerException: Cannot invoke 
"javafx.scene.Node.getScene()" because "<local2>" is null
 ? at 
javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
 ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
 ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
 ? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
 ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
 ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
 ? at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
 ? at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
 ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
 ? at 
com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
 ? at java.base/java.lang.Thread.run(Thread.java:1583)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/0b2d3a8b/attachment-0001.htm>

From pavelturk2000 at gmail.com  Thu Aug 22 06:33:54 2024
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Thu, 22 Aug 2024 09:33:54 +0300
Subject: It is not possible to create a new bug in Java Bug Database
Message-ID: <3a5b4bf3-95a7-42f6-b4f6-60321e7c5ffe@gmail.com>

Hello, all.

It is the second day I am trying to create a JavaFX bug - https://bugreport.java.com/bugreport/submit_start.

After I fill in all the fields and press the submit button I get 504 Gateway Time-out.

I even can't create a bug that Bug Database not working :)

Please inform your colleagues at Oracle about this.

Best regards, Pavel


From john.hendrikx at gmail.com  Thu Aug 22 07:37:52 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 22 Aug 2024 09:37:52 +0200
Subject: Accidentally reproduced NPE in synchronizeNodes in combination
 with enterNestedEventLoop
In-Reply-To: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>
References: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>
Message-ID: <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>

I think I figured out the reason why this fails.? The root cause lies in 
a misconception I've seen in a lot of FX code.

JavaFX uses a single event thread model, which ensures all structures 
are only ever accessed by a single thread.? This frees FX from having to 
do synchronization on almost every modification you make to properties 
or the scene graph.

However, in many areas it makes the assumption that such code will 
always run sequentially to completion without interruption, and uses 
instance fields judiciously to communicate things to deeper nested code 
or to code further down the line.? But code using instance fields in 
this way?is not safe to re-enter (it is not reentrant-safe) without 
precautions -- sharing instance fields in this way safely?can easily get 
as complicated as writing multi-threaded code.

A simple example that I saw in Parent's toFront code:

childrenTriggerPermutation= true;

try{

children.remove(node);

children.add(node);

} finally{

childrenTriggerPermutation= false;

}

The above code uses an instance field "childrenTriggerPermutation" to 
activate an optimization. The optimization will assume that the children 
are only re-arranged, and no new ones were added or removed.? However, 
"children" is an ObservableList, which means the user can register 
listeners on it, which do who knows what.? If such a listener modifies 
the children list in another way then the code is entered again, but the 
"childrenTriggerPermutation" optimization will still be enabled causing 
it to not notice the change the user did.

This problem is similar to the ChangeListener old value bug. When within 
a change listener you do another change (and so the same code is called 
**deeper** in the same stack), downstream change listeners will not 
receive the correct old values because the code is insufficiently 
reentrant-safe.? ExpressionHelper **tries** to mitigate some of these 
issues (for cases where listeners are added/removed reentrantly) by 
making copies of the listener list, but it does not handle this case.

Similarly, the bug I encountered in my original post is also such an 
issue.? While processing the children list changes, several 
**properties** are being manipulated.? Being properties, these can have 
listeners of their own that could trigger further modifications and, in 
complex enough programs, they?may even re-enter the same class's code 
that is sharing instance fields in an unsafe way.? And that's exactly 
what is happening:

1.?The children list change processing is registering the offset of the 
first changed child in the children list (called "startIdx") as an 
instance field -- this field is used as an optimization for updatePeer 
(so it doesn't have to check/copy all children).? It assumes the 
processing always finishes completely and it will get to the point where 
it sets "startIdx" but...

2. Before it sets "startIdx" but after the children list is already 
modified, it modifies several properties.? Being properties, these can 
have listeners, and as such this can trigger?a cascade of further calls 
in complicated applications.

3. In this case, the cascade of calls included an 
"enterNestedEventLoop".? Pulses (and things like Platform#runLater) can 
be handled on such a nested loop, and FX decides that now is as good a 
time as any to handle a new pulse.

4. The pulse triggers updatePeer calls, among which is the Parent that 
is still (higher in the stack) midway its children list processing code.

5. The updatePeer code looks at "startIdx", the shared instance field 
that Parent uses for its optimizations.? This field is NOT modified 
yet.? The field indicates the first child that was modified, and the 
field is normally set to "children.size()" when there are no changes.? 
That's also the case in this case still, and so updatePeer updates 
nothing at all.? An assertion later in this code then checks if 
children.size() == peer.children.size() which fails... a stack trace is 
thrown, and synchronizeSceneNodes() blows up with infinite NPE's.

I'm not entirely sure yet how to resolve this, and if it should be.

Perhaps the safest way would?be to undo some of the 
optimizations/assumptions, and perhaps reoptimize them if there's a 
pressing need.

Another option would be to somehow delay listener callbacks until the 
code in Parent is in a safe state.

The option I like the least is to introduce yet another instance flag 
("processingListChange") and throwing an early exception if other code 
is entered that doesn't expect it...

--John


On 22/08/2024 05:24, John Hendrikx wrote:
>
> Hi List,
>
> This is a bit of a long post. I'm mainly wondering if I did something 
> wrong that FX should detect early, or if I'm doing nothing unusual and 
> FX should handle the case described below correctly.
>
> I encountered the bug where an NPE occurs in 
> Scene$ScenePulseListener#synchronizeNodes, and it is reproducable at 
> the moment. I'm not sure it is the same one others sometimes see, but 
> the version I encountered is prefaced with a failing assert (which may 
> easily get lost as synchronizeNodes will spam NPE's in your log, as it 
> doesn't recover).
>
> In Parent#validatePG it prints:
>
> ??? *** pgnodes.size validatePG() [1] != children.size() [2]
>
> And then throws an AssertionError with a long stacktrace.
>
> ??? java.lang.AssertionError: validation of PGGroup children failed
> ??????? (stack trace omitted)
>
> Immediately after this, the NPE in synchronizeNodes starts to get 
> spammed, and the application never recovers.
>
> This seems to have something to do with nested event loops, as I 
> introduced a new one in the code involved.? When I remove the nested 
> event loop, there is no problem (it also initially works fine when the 
> application is just starting, only in a different situation, when 
> there is some user interaction via a keypress, does the bug trigger).
>
> The nested event loop is entered from a ChangeListener, which may be a 
> bit unusual.? The documentation of Platform#enterNestedEventLoop says:
>
> * This method must either be called from an input event handler or
>
> * from the run method of a Runnable passed to
>
> * {@link javafx.application.Platform#runLater Platform.runLater}.
>
> * It must not be called during animation or layout processing.
>
> It is also documented to throw an IllegalStateException if used 
> incorrectly.? That is however not happening, so I guess I'm using it 
> correctly...?? On the other hand, I'm not in an input event 
> handler....?the whole process is triggered by a keypress though, and 
> deep down in the AssertionError trace you can see:
>
> ? ? at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> ??? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> ? ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
> ??? at javafx.event.Event.fireEvent(Event.java:198)
> ? ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
> ? ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
> ??? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
> ? ? at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)
>
> So IMHO?technically I am in an input event handler...?
>
> Now the code does a LOT of stuff, which is going to make this tough to 
> analyze.? In short:
>
> - I'm displaying a Scene
> - The user indicates (with a keypress) they want to go to a different Pane
> - The previous Pane is created, and added to the scene as a child to a 
> TransitionPane that will cross-fade between the current Pane and the 
> new Pane
> - As soon as the new Pane becomes part of the Scene, lots of things 
> get triggered because the Scene property goes from null to the active 
> Scene:
>
> ? ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
> ? ? at javafx.scene.Node.setScenes(Node.java:1142) <-- the new Pane 
> will get a Scene assigned to it
> ??? at javafx.scene.Parent$2.onChanged(Parent.java:372) <-- the new 
> Pane has its Parent changed to the TransitionPane
>
> - Several parts of the new Pane listen (directly or indirectly) to a 
> change in Scene, as they only become "active" when the Node involved 
> is displayed (this happens with a Scene listener)
> - One of those things is some code that will create and populate a 
> ListView; this code uses a relatively fast query, but I had marked it 
> as something that should be done in the background as it sometimes 
> does take a bit too much time on the FX thread
>
> Now, how I normally do things in the background is to display an 
> automatically closing "Please wait" dialog potentially with a progress 
> bar on it (this dialog is actually invisible, unless sufficient time 
> passes, so in 99% of the cases when things respond fast, the user 
> never sees it, even though it was created and is there).? This 
> involves starting a nested event loop. This works marvelously 
> throughout this application (and has done so for years), and it is 
> used for almost every transition from one part of the application to 
> the next.? In all cases so far however I did this directly from an 
> event handler.
>
> So the main difference is that I'm trying to enter a nested event loop 
> from a ChangeListener (which deep down was triggered by an Event).? In 
> the AssertionError stack trace (which I will include at the end), 
> there is no layout or animation code **before** entering the nested 
> loop, although there is some layout code **after** it was entered.
>
> I can live with the fact that I may be using enterNestedEventLoop 
> incorrectly here, but in that case it should probably also detect this 
> incorrect use?and throw the IllegalStateException.
>
> Technically, all this code is triggered while "adding" a Child to the 
> TransitionPane, so I suspect that is what the AssertionError is about 
> (it indicates the child count 1 != 2, which is what TransitionPane 
> has, one active pane, and just added to cross fade to).? Still, is 
> this really incorrect usage?
>
> I've included an annotated stack trace below.
>
> As it is quite reproducable, I can debug this further by adding 
> breakpoints/prints -- I'm just unsure where to start looking.
>
> --John
>
> java.lang.AssertionError: validation of PGGroup children failed
> ? at javafx.scene.Parent.validatePG(Parent.java:243)
> ? at javafx.scene.Parent.doUpdatePeer(Parent.java:201)
> ? at javafx.scene.Parent$1.doUpdatePeer(Parent.java:109)
> ? at 
> com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78)
> ? at 
> com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72)
> ? at com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:104)
> ? at javafx.scene.Node.syncPeer(Node.java:721)
> ? at 
> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2396)
> ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
> ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
> ? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
> ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
> ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
> ? at 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> ? at 
> com.sun.glass.ui.win.WinApplication._enterNestedEventLoopImpl(Native 
> Method)
> ? at 
> com.sun.glass.ui.win.WinApplication._enterNestedEventLoop(WinApplication.java:211)
> ? at 
> com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:515)
> ? at com.sun.glass.ui.EventLoop.enter(EventLoop.java:107)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:631)
> ? at javafx.application.Platform.enterNestedEventLoop(Platform.java:301)
> ? at 
> hs.mediasystem.util.javafx.SceneUtil.enterNestedEventLoop(SceneUtil.java:75) 
> <-- just my wrapper to trace slow calls, it delegates to Platform
> ? at 
> hs.mediasystem.runner.dialog.DialogPane.showDialog(DialogPane.java:78)
> ? at 
> hs.mediasystem.runner.dialog.Dialogs.showProgressDialog(Dialogs.java:163)
> ? at hs.mediasystem.runner.dialog.Dialogs.runNested(Dialogs.java:103)
> ? at 
> hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$1(HomeScreenNodeFactory.java:123) 
>
>
> The above line is where the nested event loop is entered.? It starts 
> to display a "busy" dialog. A background task (on a new thread) will 
> create a ListView (this never actually happens, the AssertionError is 
> thrown immediately even with an empty task that just sleeps 10 seconds).
>
> ? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at 
> javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
> ? at 
> javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
> ? at 
> javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
> ? at 
> javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
> ? at 
> javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105)
> ? at 
> javafx.scene.control.MultipleSelectionModelBase.lambda$new$0(MultipleSelectionModelBase.java:67)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at 
> javafx.beans.property.ReadOnlyIntegerPropertyBase.fireValueChangedEvent(ReadOnlyIntegerPropertyBase.java:78)
> ? at 
> javafx.beans.property.ReadOnlyIntegerWrapper.fireValueChangedEvent(ReadOnlyIntegerWrapper.java:102)
> ? at 
> javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:114)
> ? at 
> javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
> ? at 
> javafx.scene.control.SelectionModel.setSelectedIndex(SelectionModel.java:69)
> ? at 
> javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:424)
> ? at 
> javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:456)
> ? at 
> hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$3(HomeScreenNodeFactory.java:176) 
> <-- triggers the creation of a ListView
> ? at javafx.beans.value.ObservableValue.lambda$0(ObservableValue.java:364)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at 
> com.sun.javafx.binding.ConditionalBinding.conditionChanged(ConditionalBinding.java:53)
> ? at com.sun.javafx.binding.Subscription.lambda$2(Subscription.java:63)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at 
> com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at 
> com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at 
> javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
> ? at 
> javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
> ? at 
> javafx.scene.Node$ReadOnlyObjectWrapperManualFire.fireSuperValueChangedEvent(Node.java:1053) 
> <-- there is a listener on a Scene property
> ? at javafx.scene.Node.invalidatedScenes(Node.java:1104)
> ? at javafx.scene.Node.setScenes(Node.java:1142)
> ? at javafx.scene.Parent.scenesChanged(Parent.java:772) <-- the new 
> Pane has a few nested Panes, so you see multiple Parent assignments
> ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
> ? at javafx.scene.Node.setScenes(Node.java:1142)
> ? at javafx.scene.Parent.scenesChanged(Parent.java:772)
> ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
> ? at javafx.scene.Node.setScenes(Node.java:1142) <-- the Parent is 
> part of a Scene, so this new Pane also gets the same Scene assigned
> ? at javafx.scene.Parent$2.onChanged(Parent.java:372)??? <-- the new 
> Pane gets its parent assigned (TransitionPane)
> ? at 
> com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:45)
> ? at 
> com.sun.javafx.collections.ListListenerHelper$Generic.fireValueChangedEvent(ListListenerHelper.java:329)
> ? at 
> com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:73)
> ? at 
> javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:239)
> ? at 
> javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
> ? at 
> javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
> ? at 
> javafx.collections.ObservableListBase.endChange(ObservableListBase.java:211)
> ? at 
> javafx.collections.ModifiableObservableListBase.add(ModifiableObservableListBase.java:162)
> ? at 
> com.sun.javafx.collections.VetoableListDecorator.add(VetoableListDecorator.java:319)
> ? at 
> hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:94) 
> <-- new Pane is added to a TransitionPane that handles cross fade 
> between old and new Pane
> ? at 
> hs.mediasystem.util.javafx.ui.transition.TransitionPane.addAtStart(TransitionPane.java:105)
> ? at 
> hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:113)
> ? at 
> hs.mediasystem.runner.presentation.ViewPort.updateChildNode(ViewPort.java:68) 
> <-- here it installs the new Pane to display
> ? at 
> hs.mediasystem.runner.presentation.ViewPort.lambda$0(ViewPort.java:39)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
> ? at 
> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
> ? at 
> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
> ? at 
> javafx.beans.property.ObjectPropertyBase.fireValueChangedEvent(ObjectPropertyBase.java:111)
> ? at 
> javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
> ? at 
> javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
> ? at 
> hs.mediasystem.presentation.ParentPresentation.navigateBack(ParentPresentation.java:39) 
> <-- this handles the keyPress (it was a "back" press)
> ? at hs.mediasystem.util.expose.Expose.lambda$3(Expose.java:55)
> ? at hs.mediasystem.util.expose.Trigger$1.run(Trigger.java:58)
> ? at 
> hs.mediasystem.runner.RootPresentationHandler.tryRunAction(RootPresentationHandler.java:106)
> ? at 
> hs.mediasystem.runner.RootPresentationHandler.handleActionEvent(RootPresentationHandler.java:81)
> ? at 
> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
> ? at 
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
> ? at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> ? at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> ? at 
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> ? at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> ? at hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) 
> <-- this is just my Slow Event detection, and just delegates the event
> ? at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> ? at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> ? at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> ? at hs.mediasystem.util.javafx.base.Events.dispatchEvent(Events.java:35)
> ? at 
> hs.mediasystem.runner.action.InputActionHandler.handleKeyEvent(InputActionHandler.java:153) 
> <-- just code that handles a?keypress that bubbled all the way to the top
> ? at 
> hs.mediasystem.runner.action.InputActionHandler.onKeyPressed(InputActionHandler.java:138)
> ? at 
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
> ? at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> ? at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> ? at 
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> ? at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> ? at hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) 
> <-- this is just my Slow Event detection, and just delegates the event
> ? at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> ? at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> ? at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
> ? at javafx.event.Event.fireEvent(Event.java:198)
> ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
> ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
> ? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
> ? at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)
> ? at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:150)
> ? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
> ? at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleKeyEvent$1(GlassViewEventHandler.java:250)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
> ? at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleKeyEvent(GlassViewEventHandler.java:249)
> ? at com.sun.glass.ui.View.handleKeyEvent(View.java:542)
> ? at com.sun.glass.ui.View.notifyKey(View.java:966)
> ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> ? at 
> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
> ? at java.base/java.lang.Thread.run(Thread.java:1583)
>
> And the NPE exception:
>
> java.lang.NullPointerException: Cannot invoke 
> "javafx.scene.Node.getScene()" because "<local2>" is null
> ?? ?at 
> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
> ?? ?at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
> ?? ?at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
> ?? ?at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
> ?? ?at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
> ??? (rest of trace identical to the AssertionError one)
>
> And another variant of the NPE exception:
>
> java.lang.NullPointerException: Cannot invoke 
> "javafx.scene.Node.getScene()" because "<local2>" is null
> ? at 
> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
> ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
> ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
> ? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
> ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
> ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
> ? at 
> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
> ? at 
> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
> ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> ? at 
> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
> ? at java.base/java.lang.Thread.run(Thread.java:1583)
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/32c2ee5d/attachment-0001.htm>

From sykora at openjdk.org  Thu Aug 22 07:51:11 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 22 Aug 2024 07:51:11 GMT
Subject: RFR: 8336940: Update GStreamer to 1.24.6 [v2]
In-Reply-To: <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
 <Z4OTU9ylLC2T_ZBRCGmJo3PWst6xW8ccKG4IPqb9ja8=.c6c7e780-1f33-49ce-8338-c3033ac50232@github.com>
Message-ID: <eHDvCpc1rZms4USF3VY5HAkIIyEXI2EjlwF340rsOgk=.75b79c46-3863-4458-9d23-c5cb1c962661@github.com>

On Wed, 21 Aug 2024 21:36:52 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
>> - Testing done on all platforms with all supported formats.
>> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
>> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
>> - No other changes or bug fixes are done.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336940: Update GStreamer to 1.24.6 [v3]

Builds and tests ran fine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1542#pullrequestreview-2253749840

From hmeda at openjdk.org  Thu Aug 22 12:40:20 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 22 Aug 2024 12:40:20 GMT
Subject: [jfx23u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
Message-ID: <JR0LCHgaym9O7S7iZDTR1F1TX2QvnqoF-lPbcwNNDaU=.c78de76c-9c4f-4bc1-8782-2d7b773a21eb@github.com>

Clean Backport

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

Commit messages:
 - Backport 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

Changes: https://git.openjdk.org/jfx23u/pull/12/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=12&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338306
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx23u/pull/12.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/12/head:pull/12

PR: https://git.openjdk.org/jfx23u/pull/12

From hmeda at openjdk.org  Thu Aug 22 12:40:20 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 22 Aug 2024 12:40:20 GMT
Subject: [jfx23u] Integrated: 8338306: WebView Drag and Drop fails with WebKit
 619.1
In-Reply-To: <JR0LCHgaym9O7S7iZDTR1F1TX2QvnqoF-lPbcwNNDaU=.c78de76c-9c4f-4bc1-8782-2d7b773a21eb@github.com>
References: <JR0LCHgaym9O7S7iZDTR1F1TX2QvnqoF-lPbcwNNDaU=.c78de76c-9c4f-4bc1-8782-2d7b773a21eb@github.com>
Message-ID: <Gxxc0ht2_2uD6yV7JEsC1XfIFVFHYfafzhqvfwzy9PQ=.d4423596-65f8-4148-b7f1-c3552704ebe5@github.com>

On Thu, 22 Aug 2024 12:35:07 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 82110a38
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/82110a38b2895c607d6d33109c95fb5c8bd9bfec
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8338306: WebView Drag and Drop fails with WebKit 619.1

Backport-of: 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb

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

PR: https://git.openjdk.org/jfx23u/pull/12

From hmeda at openjdk.org  Thu Aug 22 14:30:25 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 22 Aug 2024 14:30:25 GMT
Subject: RFR: 8338307 : Additional WebKit 619.1 fixes from WebKitGTK 2.44.3
Message-ID: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>

Updated additonal fixes from webkit-2.44.3. Verified build on all platforms. No issue seen.

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

Commit messages:
 - correct spaces
 - Update changes related to webkit-2.44.3

Changes: https://git.openjdk.org/jfx/pull/1541/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338307
  Stats: 1276 lines in 181 files changed: 721 ins; 113 del; 442 mod
  Patch: https://git.openjdk.org/jfx/pull/1541.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1541/head:pull/1541

PR: https://git.openjdk.org/jfx/pull/1541

From angorya at openjdk.org  Thu Aug 22 14:38:14 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Aug 2024 14:38:14 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <udGO7WD93SZDpZ_YgJNLe_9SKSBHF9D4j1siTu-kQLA=.1d85494c-c47b-4fbf-b4e9-3ad447d02d2c@github.com>

On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

@kevinrushforth please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2304835020

From kcr at openjdk.org  Thu Aug 22 15:32:14 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 15:32:14 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <oWgU3R_83FRKAaSpO02mWCbsISTZ3QFYsl8kpOPVz6Q=.f1aa881f-5090-4c85-9e8e-325dc8fba584@github.com>

On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

It's on  my list to review, but at a low priority. I have concerns over the proposed solution, specifically around the creation and use of the (not public) snapInnerSpace method.

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

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2305026637

From arapte at openjdk.org  Thu Aug 22 16:13:19 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 22 Aug 2024 16:13:19 GMT
Subject: RFR: 8338849: Update copyright header for files modified in 2024
Message-ID: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>

Update copyright year in files updated in year 2024.
This update is done specifically to update the year in webkit files, so that the webkit source shows no diff.

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

Commit messages:
 - copyright year 2024

Changes: https://git.openjdk.org/jfx/pull/1543/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338849
  Stats: 39 lines in 39 files changed: 0 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jfx/pull/1543.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1543/head:pull/1543

PR: https://git.openjdk.org/jfx/pull/1543

From kcr at openjdk.org  Thu Aug 22 16:54:12 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 16:54:12 GMT
Subject: RFR: 8338307 : Additional WebKit 619.1 fixes from WebKitGTK 2.44.3
In-Reply-To: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
References: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
Message-ID: <zuwEI3CNiok0szZMNpRiwGpZ4cZqIQFIjAY5EMDLfBU=.f8fada52-d26d-4409-ae1c-fcd5e971718c@github.com>

On Wed, 21 Aug 2024 09:53:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated additonal fixes from webkit-2.44.3. Verified build on all platforms. No issue seen.

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1541#issuecomment-2305217262

From kcr at openjdk.org  Thu Aug 22 17:12:08 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 17:12:08 GMT
Subject: RFR: 8338849: Update copyright header for files modified in 2024
In-Reply-To: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
References: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
Message-ID: <RQ0fzb3VMAgm9mJhJ9j9CJjFmuyeSMS8FuGRcM3R7zQ=.74f06935-e3ce-4080-9ef0-4b9d96f506e6@github.com>

On Thu, 22 Aug 2024 16:09:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in year 2024.
> This update is done specifically to update the year in webkit files, so that the webkit source shows no diff.

Looks good except for two media files. One definitely must be reverted (the legal file) and the other probably should be.

modules/javafx.media/src/main/legal/libffi.md line 38:

> 36: Copyright (C) 2002-2007  Bo Thorsen <bo at suse.de>
> 37: Copyright (C) 2021  Microsoft, Inc.
> 38: Copyright (c) 2022, 2024, Oracle and/or its affiliates.

Please revert this (we should not update `.md` files in `/src/main/legal`).

modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/prep_cif.c line 4:

> 2:    prep_cif.c - Copyright (c) 2011, 2012, 2021  Anthony Green
> 3:                 Copyright (c) 1996, 1998, 2007  Red Hat, Inc.
> 4:                 Copyright (c) 2022, 2024, Oracle and/or its affiliates.

I'm not sure that we should modify this either. It seems best to revert it.

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

PR Review: https://git.openjdk.org/jfx/pull/1543#pullrequestreview-2255182188
PR Review Comment: https://git.openjdk.org/jfx/pull/1543#discussion_r1727502994
PR Review Comment: https://git.openjdk.org/jfx/pull/1543#discussion_r1727518491

From arapte at openjdk.org  Thu Aug 22 17:37:28 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 22 Aug 2024 17:37:28 GMT
Subject: RFR: 8338849: Update copyright header for files modified in 2024
 [v2]
In-Reply-To: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
References: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
Message-ID: <rMk43UZcAEczAF0gW_bXV1liIx2COXi99On8CtZkaB8=.d954bd56-e2e0-4f07-8a99-a9a1a662b328@github.com>

> Update copyright year in files updated in year 2024.
> This update is done specifically to update the year in webkit files, so that the webkit source shows no diff.

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  revert unrequired changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1543/files
  - new: https://git.openjdk.org/jfx/pull/1543/files/3b4e7c8e..bd72cc52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1543&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1543&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1543.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1543/head:pull/1543

PR: https://git.openjdk.org/jfx/pull/1543

From arapte at openjdk.org  Thu Aug 22 17:41:10 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 22 Aug 2024 17:41:10 GMT
Subject: RFR: 8338849: Update copyright header for files modified in 2024
 [v2]
In-Reply-To: <RQ0fzb3VMAgm9mJhJ9j9CJjFmuyeSMS8FuGRcM3R7zQ=.74f06935-e3ce-4080-9ef0-4b9d96f506e6@github.com>
References: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
 <RQ0fzb3VMAgm9mJhJ9j9CJjFmuyeSMS8FuGRcM3R7zQ=.74f06935-e3ce-4080-9ef0-4b9d96f506e6@github.com>
Message-ID: <IvzHYm9hCNVIfSFtRZn_9SYkXRzOzC23ahDQGhxjago=.e283ec8d-08d0-46e4-ab23-ce36b526c9f5@github.com>

On Thu, 22 Aug 2024 17:09:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Looks good except for two media files. One definitely must be reverted (the legal file) and the other probably should be.

Thanks Kevin, Reverted both the files.

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

PR Comment: https://git.openjdk.org/jfx/pull/1543#issuecomment-2305301084

From kcr at openjdk.org  Thu Aug 22 17:51:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 17:51:10 GMT
Subject: RFR: 8338849: Update copyright header for files modified in 2024
 [v2]
In-Reply-To: <rMk43UZcAEczAF0gW_bXV1liIx2COXi99On8CtZkaB8=.d954bd56-e2e0-4f07-8a99-a9a1a662b328@github.com>
References: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
 <rMk43UZcAEczAF0gW_bXV1liIx2COXi99On8CtZkaB8=.d954bd56-e2e0-4f07-8a99-a9a1a662b328@github.com>
Message-ID: <N5j-uKCnbEVrkF_pGgEZowdb04dm2k4pmsJokkI72Lg=.6fb72b3e-d2e8-44a4-881a-56051bf85d7f@github.com>

On Thu, 22 Aug 2024 17:37:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Update copyright year in files updated in year 2024.
>> This update is done specifically to update the year in webkit files, so that the webkit source shows no diff.
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unrequired changes

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1543#pullrequestreview-2255286281

From kcr at openjdk.org  Thu Aug 22 18:13:13 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 18:13:13 GMT
Subject: [jfx23u] RFR: Merge jfx:jfx23
Message-ID: <lggQM2hL_RWLqafP5sQ6QRKHQPBv2cFMsMpmq0QsslQ=.6c0e4635-a316-44ae-86cf-dd8118eedeaa@github.com>

Clean merge from `jfx:jfx23` to `jfx23u:master`.

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

Commit messages:
 - Merge
 - 8338478: [macos] Crash in CoreText with certain strings using JDK 22 or later

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx23u/pull/13/files
  Stats: 87 lines in 1 file changed: 32 ins; 14 del; 41 mod
  Patch: https://git.openjdk.org/jfx23u/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/13/head:pull/13

PR: https://git.openjdk.org/jfx23u/pull/13

From kcr at openjdk.org  Thu Aug 22 18:21:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 18:21:09 GMT
Subject: [jfx23u] Integrated: Merge jfx:jfx23
In-Reply-To: <lggQM2hL_RWLqafP5sQ6QRKHQPBv2cFMsMpmq0QsslQ=.6c0e4635-a316-44ae-86cf-dd8118eedeaa@github.com>
References: <lggQM2hL_RWLqafP5sQ6QRKHQPBv2cFMsMpmq0QsslQ=.6c0e4635-a316-44ae-86cf-dd8118eedeaa@github.com>
Message-ID: <znExYZjHqte7ciR9Xymh131BXcupQvfAg8qoPruwDtI=.9602bf21-b9a7-4a49-ab80-0cf14ee35dec@github.com>

On Thu, 22 Aug 2024 18:08:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge from `jfx:jfx23` to `jfx23u:master`.

This pull request has now been integrated.

Changeset: faf4c287
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/faf4c287890d805781e6d5b621cb32729b93d563
Stats:     87 lines in 1 file changed: 32 ins; 14 del; 41 mod

Merge

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

PR: https://git.openjdk.org/jfx23u/pull/13

From angorya at openjdk.org  Thu Aug 22 19:03:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Aug 2024 19:03:45 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v2]
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <MCPDmtO1tqDlyWC7g3zFqWrRRZSXHSCTefGTR04DyBg=.41f78e5d-ccc5-4b56-bf1c-5ac115e4e044@github.com>

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - ... and 25 more: https://git.openjdk.org/jfx/compare/b8987310...19827de5

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

Changes: https://git.openjdk.org/jfx/pull/1156/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=01
  Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod
  Patch: https://git.openjdk.org/jfx/pull/1156.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156

PR: https://git.openjdk.org/jfx/pull/1156

From kcr at openjdk.org  Thu Aug 22 22:02:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 22 Aug 2024 22:02:09 GMT
Subject: RFR: 8338307 : Additional WebKit 619.1 fixes from WebKitGTK 2.44.3
In-Reply-To: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
References: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
Message-ID: <cbvWWgV4jYDTj7G05JzVvRsULw573erDKBRlbU77PsU=.e0ff8ff4-d99d-480c-9e93-da3d38e6838e@github.com>

On Wed, 21 Aug 2024 09:53:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated additonal fixes from webkit-2.44.3. Verified build on all platforms. No issue seen.

Looks good. The code changes match those in the upstream `webkitgtk-2.44.3` tag. I did a build and sanity test. All good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1541#pullrequestreview-2255871487

From kneester77 at gmail.com  Thu Aug 22 22:14:41 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Thu, 22 Aug 2024 15:14:41 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
Message-ID: <CAB9Lf7LoD9drvpaMkKBDaAy+QDaTCJr2EQFpxbtMYYYxctk0HA@mail.gmail.com>

Hi all, just sending an update on the proposal since I'm hoping to start
work on a draft PR for this, but I'd like feedback on the proposed API
(with & without the changes mentioned in the previous email).

Thanks!

On Tue, Aug 20, 2024 at 11:49?PM Knee Snap <kneester77 at gmail.com> wrote:

> Hi Michael,
>
> Thanks for the response!
>
> *> Have you thought about ways how we could allow deverlopers to define
> custom formats? Maybe that would also require a new kind of Mesh that can
> accept custom data.*
> Yep, and while I'd very much like this eventually, this cannot occur
> before user-supplied shaders are supported since otherwise there'd be
> nothing done with any user-configured data. User-supplied shaders would be
> a very large amount of work in many different aspects.
> For example, there isn't even currently a way to tell if the 3D backend
> JavaFX has running is OpenGL or Direct3D, let alone manage shaders.
> I don't know that I'm qualified to even implement something so large for
> an open-source immutable API yet. And, it would also ask more from
> developers who utilize JavaFX, as they now need to write shaders for each
> supported backend, and juggle a lot objects & concepts more when it comes
> to rendering.
> I still see value in keeping a platform-agnostic shader-free TriangleMesh
> which has vertex coloring even after a hypothetical user-supplied shader
> system, which could co-exist separate from the "TriangleMesh" as perhaps a
> new "AdvancedTriangleMesh" class.
> Now here's where I think you've brought up an interesting point and I'll
> counter with a slight change to my design.
>
> *> However, with the introduction of programmable shaders, the structure
> of vertices can be freely defined by developers. It seems to me that your
> proposed API would pick just one (maybe useful) scenario, and eternally
> bake it into JavaFX APIs. What if we get custom shaders one day? Then we
> would need a way to customize the vertex format again.*
> Yes! It is just one scenario and shaders are the dream, but I still
> believe it's worth baking into the JavaFX API due to how useful it is, I
> imagine that this feature can co-exist separately from the hypothetical
> user-supplied shader support.
> I mentioned before in a previous email that I don't think having vertex
> colors takes away from the ideal future where custom shaders are supported.
> Since there seems to be a concern here, I'll expand upon what I meant by
> that.
>
> The current TriangleMesh.java is equivalent to a non-shader fixed
> rendering pipeline, as it has an explicitly defined group of buffers. Some
> of which (normals) are already optional.
> The design of the future user-supplied shader system has not been made
> worse by supporting vertex colors, as we already have the same exact
> eternally baked API already inside TriangleMesh.java.
>
> It's true though that TriangleMesh's existing buffers are mostly
> applicable to pretty much every future shader, but it's not entirely the
> case.
> Normals are also currently optional, and also might not be desired by
> certain custom shaders when it's time. I'll concede that normals are
> somewhat more common than vertex colors, but it's the same problem in the
> same file.
>
> Initially because of this observation about normals, my thought was that
> TriangleMesh wouldn't be the parent class of any future mesh with shader
> support. There would be two separate mesh base classes, TriangleMesh (fixed
> capabilities), and something like AdvancedTriangleMesh (allowing
> user-specified shaders).
> Any solution which was good enough for normals is also good enough for
> vertex colors right?
>
> Well, after your critique, I've come up with another option, I'm curious
> if you prefer this one.
> Instead of modifying TriangleMesh.java and having an unrelated
> AdvancedTriangleMesh class in the future, this one can consider that just
> because normals are in TriangleMesh.java a bad thing doesn't mean vertex
> colors need to clog it further.
> So, I'd instead create "GouraudShadedTriangleMesh" which extends
> TriangleMesh, and it's what would contain the vertex buffer, etc. So it can
> have the coloring, and also allow a future AdvancedTriangleMesh to extend
> the original TriangleMesh without having a hint of the vertex color buffer.
>
> I believe this should adequately address why I think this is good to have
> in the API forever.
>
> *> Currently we have two predefined vertex formats:
> VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD. It
> doesn't seem obvious to me that the best way forward is to add more bespoke
> formats here.*
> I partially agree, and partially disagree. I agree that we should not be
> adding VertexFormat options left and right. But the only other scenario I
> can imagine as theoretically adding more VertexFormats is if it became time
> to support quads. Either that or a new user-supplied shader system, but
> that isn't really relevant.
> Vertex colors feel to me like the final missing piece before the current
> non-custom shader mesh support is fully featured, so I don't think it's
> unreasonable to add new VertexFormat entries.
> In theory it would be possible with the "GouraudShadedTriangleMesh" idea
> to not actually create any new VertexFormat object/functionality, and keep
> such functionality within the "GouraudShadedTriangleMesh" class itself.
> Personally I think it depends entirely on the decision of "Would a
> potential future user-supplied shader system extend TriangleMesh or should
> it be its own thing?"
>
> Thanks again for the feedback!
>
>
> On Tue, Aug 20, 2024 at 10:51?PM Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
>
>> Vertex colors usually refers to a technique where the vertex format is
>> enriched with an additional color component, and this color component is
>> then used in one of the shader stages to affect the computation in some way
>> (usually by combining it with the texture color).
>>
>> As you correctly say, this technique is decades-old, it existed even back
>> in the days of fixed function pipelines.
>>
>> However, with the introduction of programmable shaders, the structure of
>> vertices can be freely defined by developers. It seems to me that your
>> proposed API would pick just one (maybe useful) scenario, and eternally
>> bake it into JavaFX APIs. What if we get custom shaders one day? Then we
>> would need a way to customize the vertex format again.
>>
>> Currently we have two predefined vertex formats:
>> VertexFormat.POINT_TEXCOORD and VertexFormat.POINT_NORMAL_TEXCOORD.
>> It doesn't seem obvious to me that the best way forward is to add more
>> bespoke formats here.
>>
>> Have you thought about ways how we could allow deverlopers to define
>> custom formats? Maybe that would also require a new kind of Mesh that can
>> accept custom data.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/cc23b61f/attachment.htm>

From angorya at openjdk.org  Thu Aug 22 22:39:25 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Aug 2024 22:39:25 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v3]
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <qErA5T1GXgAGrBWT08qLGGwCGPaph3ifS-mfaSGi19g=.15d1aa18-f069-451a-b15d-07c2df624384@github.com>

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  in case of hitting min max

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1156/files
  - new: https://git.openjdk.org/jfx/pull/1156/files/19827de5..26e9fd54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=01-02

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

PR: https://git.openjdk.org/jfx/pull/1156

From angorya at openjdk.org  Thu Aug 22 22:51:16 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Aug 2024 22:51:16 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale
In-Reply-To: <oWgU3R_83FRKAaSpO02mWCbsISTZ3QFYsl8kpOPVz6Q=.f1aa881f-5090-4c85-9e8e-325dc8fba584@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <oWgU3R_83FRKAaSpO02mWCbsISTZ3QFYsl8kpOPVz6Q=.f1aa881f-5090-4c85-9e8e-325dc8fba584@github.com>
Message-ID: <uG3L9TTtZLzBa8l3n33Q84J26Vgy7TkniGzu78VviT4=.71aaa2ba-760b-4894-a48b-e33ab007ffa1@github.com>

On Thu, 22 Aug 2024 15:29:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> snapInnerSpace method.

The main idea is to handle the case when computing snapped coordinates within the unsnapped container.  Granted, this is somewhat unusual case, so I am ok with using simple rounding here.

FYI, I've added Page -> Snapped Split Panes menu option to the monkey tester to test exactly this case.  I don't think I see much difference on Windows with fractional scale.

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

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2305874676

From michaelstrau2 at gmail.com  Fri Aug 23 01:27:56 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 23 Aug 2024 03:27:56 +0200
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
Message-ID: <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>

> Any solution which was good enough for normals is also good enough for vertex colors right?

Not necessarily. Designing APIs is hard, and one should try to start
from a point of asking "how would the API look like if we had
considered all of the things we know now from the beginning".

An idea that might be worth exploring is the following. Instead of
storing positions, normals, texture coordinates, etc. in separate
buffers as it is currently done in TriangleMesh, we could have a
CustomMesh<TVertex>, where TVertex is a structure that stores all
relevant components in the same place. This could be a sealed
interface that only allows a limited set of implementations (because
we don't have the option of user-defined vertex structures at the
moment), but could allow for future extension with user-defined vertex
structures.

From john.hendrikx at gmail.com  Fri Aug 23 01:38:26 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 23 Aug 2024 03:38:26 +0200
Subject: Accidentally reproduced NPE in synchronizeNodes in combination
 with enterNestedEventLoop
In-Reply-To: <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>
References: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>
 <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>
Message-ID: <fffa192a-27b5-4d65-b4ed-04e4ecba7593@gmail.com>

Small sample program that triggers an assert in Parent:

@Override

publicvoidstart(Stage primaryStage) {

HBox hbox = newHBox();

Scene scene = newScene(hbox);

Button button1 = newButton("Hi");

Button button2 = newButton("World");

Button button3 = newButton("!");

hbox.getChildren().addAll(button1, button2);

hbox.getChildren().addListener(newInvalidationListener() {

@Override

publicvoidinvalidated(Observable observable) {

if(!hbox.getChildren().contains(button3)) {

hbox.getChildren().addAll(button3, button3);

}

}

});

button1.toFront();

primaryStage.setScene(scene);

primaryStage.show();

}

--John

On 22/08/2024 09:37, John Hendrikx wrote:
>
> I think I figured out the reason why this fails.? The root cause lies 
> in a misconception I've seen in a lot of FX code.
>
> JavaFX uses a single event thread model, which ensures all structures 
> are only ever accessed by a single thread.? This frees FX from having 
> to do synchronization on almost every modification you make to 
> properties or the scene graph.
>
> However, in many areas it makes the assumption that such code will 
> always run sequentially to completion without interruption, and uses 
> instance fields judiciously to communicate things to deeper nested 
> code or to code further down the line.? But code using instance fields 
> in this way?is not safe to re-enter (it is not reentrant-safe) without 
> precautions -- sharing instance fields in this way safely?can easily 
> get as complicated as writing multi-threaded code.
>
> A simple example that I saw in Parent's toFront code:
>
> childrenTriggerPermutation= true;
>
> try{
>
> children.remove(node);
>
> children.add(node);
>
> } finally{
>
> childrenTriggerPermutation= false;
>
> }
>
> The above code uses an instance field "childrenTriggerPermutation" to 
> activate an optimization. The optimization will assume that the 
> children are only re-arranged, and no new ones were added or removed.? 
> However, "children" is an ObservableList, which means the user can 
> register listeners on it, which do who knows what.? If such a listener 
> modifies the children list in another way then the code is entered 
> again, but the "childrenTriggerPermutation" optimization will still be 
> enabled causing it to not notice the change the user did.
>
> This problem is similar to the ChangeListener old value bug. When 
> within a change listener you do another change (and so the same code 
> is called **deeper** in the same stack), downstream change listeners 
> will not receive the correct old values because the code is 
> insufficiently reentrant-safe.? ExpressionHelper **tries** to mitigate 
> some of these issues (for cases where listeners are added/removed 
> reentrantly) by making copies of the listener list, but it does not 
> handle this case.
>
> Similarly, the bug I encountered in my original post is also such an 
> issue.? While processing the children list changes, several 
> **properties** are being manipulated.? Being properties, these can 
> have listeners of their own that could trigger further modifications 
> and, in complex enough programs, they?may even re-enter the same 
> class's code that is sharing instance fields in an unsafe way.? And 
> that's exactly what is happening:
>
> 1.?The children list change processing is registering the offset of 
> the first changed child in the children list (called "startIdx") as an 
> instance field -- this field is used as an optimization for updatePeer 
> (so it doesn't have to check/copy all children).? It assumes the 
> processing always finishes completely and it will get to the point 
> where it sets "startIdx" but...
>
> 2. Before it sets "startIdx" but after the children list is already 
> modified, it modifies several properties.? Being properties, these can 
> have listeners, and as such this can trigger?a cascade of further 
> calls in complicated applications.
>
> 3. In this case, the cascade of calls included an 
> "enterNestedEventLoop".? Pulses (and things like Platform#runLater) 
> can be handled on such a nested loop, and FX decides that now is as 
> good a time as any to handle a new pulse.
>
> 4. The pulse triggers updatePeer calls, among which is the Parent that 
> is still (higher in the stack) midway its children list processing code.
>
> 5. The updatePeer code looks at "startIdx", the shared instance field 
> that Parent uses for its optimizations.? This field is NOT modified 
> yet.? The field indicates the first child that was modified, and the 
> field is normally set to "children.size()" when there are no changes.? 
> That's also the case in this case still, and so updatePeer updates 
> nothing at all.? An assertion later in this code then checks if 
> children.size() == peer.children.size() which fails... a stack trace 
> is thrown, and synchronizeSceneNodes() blows up with infinite NPE's.
>
> I'm not entirely sure yet how to resolve this, and if it should be.
>
> Perhaps the safest way would?be to undo some of the 
> optimizations/assumptions, and perhaps reoptimize them if there's a 
> pressing need.
>
> Another option would be to somehow delay listener callbacks until the 
> code in Parent is in a safe state.
>
> The option I like the least is to introduce yet another instance flag 
> ("processingListChange") and throwing an early exception if other code 
> is entered that doesn't expect it...
>
> --John
>
>
> On 22/08/2024 05:24, John Hendrikx wrote:
>>
>> Hi List,
>>
>> This is a bit of a long post. I'm mainly wondering if I did something 
>> wrong that FX should detect early, or if I'm doing nothing unusual 
>> and FX should handle the case described below correctly.
>>
>> I encountered the bug where an NPE occurs in 
>> Scene$ScenePulseListener#synchronizeNodes, and it is reproducable at 
>> the moment. I'm not sure it is the same one others sometimes see, but 
>> the version I encountered is prefaced with a failing assert (which 
>> may easily get lost as synchronizeNodes will spam NPE's in your log, 
>> as it doesn't recover).
>>
>> In Parent#validatePG it prints:
>>
>> ??? *** pgnodes.size validatePG() [1] != children.size() [2]
>>
>> And then throws an AssertionError with a long stacktrace.
>>
>> ??? java.lang.AssertionError: validation of PGGroup children failed
>> ??????? (stack trace omitted)
>>
>> Immediately after this, the NPE in synchronizeNodes starts to get 
>> spammed, and the application never recovers.
>>
>> This seems to have something to do with nested event loops, as I 
>> introduced a new one in the code involved.? When I remove the nested 
>> event loop, there is no problem (it also initially works fine when 
>> the application is just starting, only in a different situation, when 
>> there is some user interaction via a keypress, does the bug trigger).
>>
>> The nested event loop is entered from a ChangeListener, which may be 
>> a bit unusual.? The documentation of Platform#enterNestedEventLoop says:
>>
>> * This method must either be called from an input event handler or
>>
>> * from the run method of a Runnable passed to
>>
>> * {@link javafx.application.Platform#runLater Platform.runLater}.
>>
>> * It must not be called during animation or layout processing.
>>
>> It is also documented to throw an IllegalStateException if used 
>> incorrectly.? That is however not happening, so I guess I'm using it 
>> correctly...?? On the other hand, I'm not in an input event 
>> handler....?the whole process is triggered by a keypress though, and 
>> deep down in the AssertionError trace you can see:
>>
>> ? ? at 
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> ??? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>> ? ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
>> ??? at javafx.event.Event.fireEvent(Event.java:198)
>> ? ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
>> ? ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
>> ??? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
>> ? ? at 
>> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)
>>
>> So IMHO?technically I am in an input event handler...?
>>
>> Now the code does a LOT of stuff, which is going to make this tough 
>> to analyze.? In short:
>>
>> - I'm displaying a Scene
>> - The user indicates (with a keypress) they want to go to a different 
>> Pane
>> - The previous Pane is created, and added to the scene as a child to 
>> a TransitionPane that will cross-fade between the current Pane and 
>> the new Pane
>> - As soon as the new Pane becomes part of the Scene, lots of things 
>> get triggered because the Scene property goes from null to the active 
>> Scene:
>>
>> ? ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
>> ? ? at javafx.scene.Node.setScenes(Node.java:1142) ? <-- the new Pane 
>> will get a Scene assigned to it
>> ??? at javafx.scene.Parent$2.onChanged(Parent.java:372) <-- the new 
>> Pane has its Parent changed to the TransitionPane
>>
>> - Several parts of the new Pane listen (directly or indirectly) to a 
>> change in Scene, as they only become "active" when the Node involved 
>> is displayed (this happens with a Scene listener)
>> - One of those things is some code that will create and populate a 
>> ListView; this code uses a relatively fast query, but I had marked it 
>> as something that should be done in the background as it sometimes 
>> does take a bit too much time on the FX thread
>>
>> Now, how I normally do things in the background is to display an 
>> automatically closing "Please wait" dialog potentially with a 
>> progress bar on it (this dialog is actually invisible, unless 
>> sufficient time passes, so in 99% of the cases when things respond 
>> fast, the user never sees it, even though it was created and is 
>> there).? This involves starting a nested event loop.? This works 
>> marvelously throughout this application (and has done so for years), 
>> and it is used for almost every transition from one part of the 
>> application to the next.? In all cases so far however I did this 
>> directly from an event handler.
>>
>> So the main difference is that I'm trying to enter a nested event 
>> loop from a ChangeListener (which deep down was triggered by an 
>> Event).? In the AssertionError stack trace (which I will include at 
>> the end), there is no layout or animation code **before** entering 
>> the nested loop, although there is some layout code **after** it was 
>> entered.
>>
>> I can live with the fact that I may be using enterNestedEventLoop 
>> incorrectly here, but in that case it should probably also detect 
>> this incorrect use?and throw the IllegalStateException.
>>
>> Technically, all this code is triggered while "adding" a Child to the 
>> TransitionPane, so I suspect that is what the AssertionError is about 
>> (it indicates the child count 1 != 2, which is what TransitionPane 
>> has, one active pane, and just added to cross fade to).? Still, is 
>> this really incorrect usage?
>>
>> I've included an annotated stack trace below.
>>
>> As it is quite reproducable, I can debug this further by adding 
>> breakpoints/prints -- I'm just unsure where to start looking.
>>
>> --John
>>
>> java.lang.AssertionError: validation of PGGroup children failed
>> ? at javafx.scene.Parent.validatePG(Parent.java:243)
>> ? at javafx.scene.Parent.doUpdatePeer(Parent.java:201)
>> ? at javafx.scene.Parent$1.doUpdatePeer(Parent.java:109)
>> ? at 
>> com.sun.javafx.scene.ParentHelper.updatePeerImpl(ParentHelper.java:78)
>> ? at 
>> com.sun.javafx.scene.layout.RegionHelper.updatePeerImpl(RegionHelper.java:72)
>> ? at com.sun.javafx.scene.NodeHelper.updatePeer(NodeHelper.java:104)
>> ? at javafx.scene.Node.syncPeer(Node.java:721)
>> ? at 
>> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2396)
>> ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
>> ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
>> ? at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
>> ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
>> ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
>> ? at 
>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
>> ? at 
>> com.sun.glass.ui.win.WinApplication._enterNestedEventLoopImpl(Native 
>> Method)
>> ? at 
>> com.sun.glass.ui.win.WinApplication._enterNestedEventLoop(WinApplication.java:211)
>> ? at 
>> com.sun.glass.ui.Application.enterNestedEventLoop(Application.java:515)
>> ? at com.sun.glass.ui.EventLoop.enter(EventLoop.java:107)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:631)
>> ? at javafx.application.Platform.enterNestedEventLoop(Platform.java:301)
>> ? at 
>> hs.mediasystem.util.javafx.SceneUtil.enterNestedEventLoop(SceneUtil.java:75) 
>> <-- just my wrapper to trace slow calls, it delegates to Platform
>> ? at 
>> hs.mediasystem.runner.dialog.DialogPane.showDialog(DialogPane.java:78)
>> ? at 
>> hs.mediasystem.runner.dialog.Dialogs.showProgressDialog(Dialogs.java:163)
>> ? at hs.mediasystem.runner.dialog.Dialogs.runNested(Dialogs.java:103)
>> ? at 
>> hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$1(HomeScreenNodeFactory.java:123) 
>>
>>
>> The above line is where the nested event loop is entered.? It starts 
>> to display a "busy" dialog. A background task (on a new thread) will 
>> create a ListView (this never actually happens, the AssertionError is 
>> thrown immediately even with an empty task that just sleeps 10 seconds).
>>
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
>> ? at 
>> javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
>> ? at 
>> javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
>> ? at 
>> javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
>> ? at 
>> javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:105)
>> ? at 
>> javafx.scene.control.MultipleSelectionModelBase.lambda$new$0(MultipleSelectionModelBase.java:67)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.property.ReadOnlyIntegerPropertyBase.fireValueChangedEvent(ReadOnlyIntegerPropertyBase.java:78)
>> ? at 
>> javafx.beans.property.ReadOnlyIntegerWrapper.fireValueChangedEvent(ReadOnlyIntegerWrapper.java:102)
>> ? at 
>> javafx.beans.property.IntegerPropertyBase.markInvalid(IntegerPropertyBase.java:114)
>> ? at 
>> javafx.beans.property.IntegerPropertyBase.set(IntegerPropertyBase.java:148)
>> ? at 
>> javafx.scene.control.SelectionModel.setSelectedIndex(SelectionModel.java:69)
>> ? at 
>> javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:424)
>> ? at 
>> javafx.scene.control.MultipleSelectionModelBase.select(MultipleSelectionModelBase.java:456)
>> ? at 
>> hs.mediasystem.plugin.home.HomeScreenNodeFactory.lambda$3(HomeScreenNodeFactory.java:176) 
>> <-- triggers the creation of a ListView
>> ? at 
>> javafx.beans.value.ObservableValue.lambda$0(ObservableValue.java:364)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at 
>> com.sun.javafx.binding.ConditionalBinding.conditionChanged(ConditionalBinding.java:53)
>> ? at com.sun.javafx.binding.Subscription.lambda$2(Subscription.java:63)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at 
>> com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
>> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at 
>> com.sun.javafx.binding.FlatMappedBinding.invalidateAll(FlatMappedBinding.java:102)
>> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:348)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
>> ? at 
>> javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:102)
>> ? at 
>> javafx.scene.Node$ReadOnlyObjectWrapperManualFire.fireSuperValueChangedEvent(Node.java:1053) 
>> <-- there is a listener on a Scene property
>> ? at javafx.scene.Node.invalidatedScenes(Node.java:1104)
>> ? at javafx.scene.Node.setScenes(Node.java:1142)
>> ? at javafx.scene.Parent.scenesChanged(Parent.java:772) <-- the new 
>> Pane has a few nested Panes, so you see multiple Parent assignments
>> ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
>> ? at javafx.scene.Node.setScenes(Node.java:1142)
>> ? at javafx.scene.Parent.scenesChanged(Parent.java:772)
>> ? at javafx.scene.Node.invalidatedScenes(Node.java:1075)
>> ? at javafx.scene.Node.setScenes(Node.java:1142) <-- the Parent is 
>> part of a Scene, so this new Pane also gets the same Scene assigned
>> ? at javafx.scene.Parent$2.onChanged(Parent.java:372) <-- the new 
>> Pane gets its parent assigned (TransitionPane)
>> ? at 
>> com.sun.javafx.collections.TrackableObservableList.lambda$new$0(TrackableObservableList.java:45)
>> ? at 
>> com.sun.javafx.collections.ListListenerHelper$Generic.fireValueChangedEvent(ListListenerHelper.java:329)
>> ? at 
>> com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:73)
>> ? at 
>> javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:239)
>> ? at 
>> javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
>> ? at 
>> javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
>> ? at 
>> javafx.collections.ObservableListBase.endChange(ObservableListBase.java:211)
>> ? at 
>> javafx.collections.ModifiableObservableListBase.add(ModifiableObservableListBase.java:162)
>> ? at 
>> com.sun.javafx.collections.VetoableListDecorator.add(VetoableListDecorator.java:319)
>> ? at 
>> hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:94) 
>> <-- new Pane is added to a TransitionPane that handles cross fade 
>> between old and new Pane
>> ? at 
>> hs.mediasystem.util.javafx.ui.transition.TransitionPane.addAtStart(TransitionPane.java:105)
>> ? at 
>> hs.mediasystem.util.javafx.ui.transition.TransitionPane.add(TransitionPane.java:113)
>> ? at 
>> hs.mediasystem.runner.presentation.ViewPort.updateChildNode(ViewPort.java:68) 
>> <-- here it installs the new Pane to display
>> ? at 
>> hs.mediasystem.runner.presentation.ViewPort.lambda$0(ViewPort.java:39)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.binding.ObjectBinding.invalidate(ObjectBinding.java:192)
>> ? at com.sun.javafx.binding.Subscription.lambda$4(Subscription.java:83)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:136)
>> ? at 
>> com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80)
>> ? at 
>> javafx.beans.property.ObjectPropertyBase.fireValueChangedEvent(ObjectPropertyBase.java:111)
>> ? at 
>> javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:118)
>> ? at 
>> javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:172)
>> ? at 
>> hs.mediasystem.presentation.ParentPresentation.navigateBack(ParentPresentation.java:39) 
>> <-- this handles the keyPress (it was a "back" press)
>> ? at hs.mediasystem.util.expose.Expose.lambda$3(Expose.java:55)
>> ? at hs.mediasystem.util.expose.Trigger$1.run(Trigger.java:58)
>> ? at 
>> hs.mediasystem.runner.RootPresentationHandler.tryRunAction(RootPresentationHandler.java:106)
>> ? at 
>> hs.mediasystem.runner.RootPresentationHandler.handleActionEvent(RootPresentationHandler.java:81)
>> ? at 
>> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
>> ? at 
>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
>> ? at 
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>> ? at 
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>> ? at 
>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>> ? at 
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>> ? at 
>> hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) <-- 
>> this is just my Slow Event detection, and just delegates the event
>> ? at 
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> ? at 
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> ? at 
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>> ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
>> ? at hs.mediasystem.util.javafx.base.Events.dispatchEvent(Events.java:35)
>> ? at 
>> hs.mediasystem.runner.action.InputActionHandler.handleKeyEvent(InputActionHandler.java:153) 
>> <-- just code that handles a?keypress that bubbled all the way to the top
>> ? at 
>> hs.mediasystem.runner.action.InputActionHandler.onKeyPressed(InputActionHandler.java:138)
>> ? at 
>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
>> ? at 
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>> ? at 
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>> ? at 
>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>> ? at 
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>> ? at 
>> hs.mediasystem.util.javafx.SceneUtil.lambda$1(SceneUtil.java:101) <-- 
>> this is just my Slow Event detection, and just delegates the event
>> ? at 
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> ? at 
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> ? at 
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> ? at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>> ? at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
>> ? at javafx.event.Event.fireEvent(Event.java:198)
>> ? at javafx.scene.Scene$KeyHandler.process(Scene.java:4113)
>> ? at javafx.scene.Scene.processKeyEvent(Scene.java:2159)
>> ? at javafx.scene.Scene$ScenePeerListener.keyEvent(Scene.java:2627)
>> ? at 
>> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:218)
>> ? at 
>> com.sun.javafx.tk.quantum.GlassViewEventHandler$KeyEventNotification.run(GlassViewEventHandler.java:150)
>> ? at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
>> ? at 
>> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleKeyEvent$1(GlassViewEventHandler.java:250)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
>> ? at 
>> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleKeyEvent(GlassViewEventHandler.java:249)
>> ? at com.sun.glass.ui.View.handleKeyEvent(View.java:542)
>> ? at com.sun.glass.ui.View.notifyKey(View.java:966)
>> ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>> ? at 
>> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
>> ? at java.base/java.lang.Thread.run(Thread.java:1583)
>>
>> And the NPE exception:
>>
>> java.lang.NullPointerException: Cannot invoke 
>> "javafx.scene.Node.getScene()" because "<local2>" is null
>> ?? ?at 
>> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
>> ?? ?at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
>> ?? ?at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
>> ?? ?at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
>> ?? ?at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
>> ??? (rest of trace identical to the AssertionError one)
>>
>> And another variant of the NPE exception:
>>
>> java.lang.NullPointerException: Cannot invoke 
>> "javafx.scene.Node.getScene()" because "<local2>" is null
>> ? at 
>> javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2395)
>> ? at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2542)
>> ? at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:407)
>> ? at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
>> ? at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:406)
>> ? at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:436)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:575)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:555)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:548)
>> ? at 
>> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352)
>> ? at 
>> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
>> ? at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>> ? at 
>> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
>> ? at java.base/java.lang.Thread.run(Thread.java:1583)
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240823/795b48f9/attachment-0001.htm>

From michaelstrau2 at gmail.com  Fri Aug 23 02:31:37 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 23 Aug 2024 04:31:37 +0200
Subject: Accidentally reproduced NPE in synchronizeNodes in combination
 with enterNestedEventLoop
In-Reply-To: <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>
References: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>
 <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>
Message-ID: <CAJEpuXSn0ac==c1K7syDfO14U+42XTSPHjuy+nVKkmgELu_-ug@mail.gmail.com>

That seems to be a tough one.

Delaying the invocation of listeners sounds interesting, as it might
allow using a pattern like the following:

    childrenTriggerPermutation = true;

    try (var scope = new DelayedEventScope(children)) {
        children.remove(node);
        children.add(node);
    } finally {
        childrenTriggerPermutation = false;
    }

The semantics would be that the property implementation will still
receive notifications with their invalidated() method as the property
is being modified, but events will only be fired at the end of the
scope.
List properties will need a new listChanged() method to allow for the
same pattern of overriding the method instead of adding a change
listener.

Of course, the implementation will be challenging. We'd need to keep
track of all modifications, and then aggregate those modifications
into a single event. In this particular example, the two "add" and
"remove" events would probably be consolidated into a "permutation"
event.

In general, delayed notification scopes for properties could also be
very useful for application developers.


On Thu, Aug 22, 2024 at 9:59?AM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> I think I figured out the reason why this fails.  The root cause lies in a misconception I've seen in a lot of FX code.
>
> JavaFX uses a single event thread model, which ensures all structures are only ever accessed by a single thread.  This frees FX from having to do synchronization on almost every modification you make to properties or the scene graph.
>
> However, in many areas it makes the assumption that such code will always run sequentially to completion without interruption, and uses instance fields judiciously to communicate things to deeper nested code or to code further down the line.  But code using instance fields in this way is not safe to re-enter (it is not reentrant-safe) without precautions -- sharing instance fields in this way safely can easily get as complicated as writing multi-threaded code.
>
> A simple example that I saw in Parent's toFront code:
>
> childrenTriggerPermutation = true;
>
> try {
>
> children.remove(node);
>
> children.add(node);
>
> } finally {
>
> childrenTriggerPermutation = false;
>
> }
>
> The above code uses an instance field "childrenTriggerPermutation" to activate an optimization. The optimization will assume that the children are only re-arranged, and no new ones were added or removed.  However, "children" is an ObservableList, which means the user can register listeners on it, which do who knows what.  If such a listener modifies the children list in another way then the code is entered again, but the "childrenTriggerPermutation" optimization will still be enabled causing it to not notice the change the user did.
>
> This problem is similar to the ChangeListener old value bug.  When within a change listener you do another change (and so the same code is called **deeper** in the same stack), downstream change listeners will not receive the correct old values because the code is insufficiently reentrant-safe.  ExpressionHelper **tries** to mitigate some of these issues (for cases where listeners are added/removed reentrantly) by making copies of the listener list, but it does not handle this case.
>
> Similarly, the bug I encountered in my original post is also such an issue.  While processing the children list changes, several **properties** are being manipulated.  Being properties, these can have listeners of their own that could trigger further modifications and, in complex enough programs, they may even re-enter the same class's code that is sharing instance fields in an unsafe way.  And that's exactly what is happening:
>
> 1. The children list change processing is registering the offset of the first changed child in the children list (called "startIdx") as an instance field -- this field is used as an optimization for updatePeer (so it doesn't have to check/copy all children).  It assumes the processing always finishes completely and it will get to the point where it sets "startIdx" but...
>
> 2. Before it sets "startIdx" but after the children list is already modified, it modifies several properties.  Being properties, these can have listeners, and as such this can trigger a cascade of further calls in complicated applications.
>
> 3. In this case, the cascade of calls included an "enterNestedEventLoop".  Pulses (and things like Platform#runLater) can be handled on such a nested loop, and FX decides that now is as good a time as any to handle a new pulse.
>
> 4. The pulse triggers updatePeer calls, among which is the Parent that is still (higher in the stack) midway its children list processing code.
>
> 5. The updatePeer code looks at "startIdx", the shared instance field that Parent uses for its optimizations.  This field is NOT modified yet.  The field indicates the first child that was modified, and the field is normally set to "children.size()" when there are no changes.  That's also the case in this case still, and so updatePeer updates nothing at all.  An assertion later in this code then checks if children.size() == peer.children.size() which fails... a stack trace is thrown, and synchronizeSceneNodes() blows up with infinite NPE's.
>
> I'm not entirely sure yet how to resolve this, and if it should be.
>
> Perhaps the safest way would be to undo some of the optimizations/assumptions, and perhaps reoptimize them if there's a pressing need.
>
> Another option would be to somehow delay listener callbacks until the code in Parent is in a safe state.
>
> The option I like the least is to introduce yet another instance flag ("processingListChange") and throwing an early exception if other code is entered that doesn't expect it...
>
> --John

From kneester77 at gmail.com  Fri Aug 23 02:44:59 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Thu, 22 Aug 2024 19:44:59 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
Message-ID: <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>

Was hoping to get feedback on my suggestion instead, but another suggestion
doesn't work.

The idea of a CustomMesh<TVertex> is impossible to implement until after we
have fully user-supplied shader support, which I've already addressed as
being not the scope of this change (but instead it is a separate future
change which is not impacted by this) it also feels like this point may
have been missed as well.

On Thu, Aug 22, 2024, 6:28?PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> > Any solution which was good enough for normals is also good enough for
> vertex colors right?
>
> Not necessarily. Designing APIs is hard, and one should try to start
> from a point of asking "how would the API look like if we had
> considered all of the things we know now from the beginning".
>
> An idea that might be worth exploring is the following. Instead of
> storing positions, normals, texture coordinates, etc. in separate
> buffers as it is currently done in TriangleMesh, we could have a
> CustomMesh<TVertex>, where TVertex is a structure that stores all
> relevant components in the same place. This could be a sealed
> interface that only allows a limited set of implementations (because
> we don't have the option of user-defined vertex structures at the
> moment), but could allow for future extension with user-defined vertex
> structures.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/559922c6/attachment.htm>

From kneester77 at gmail.com  Fri Aug 23 02:48:39 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Thu, 22 Aug 2024 19:48:39 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
Message-ID: <CAB9Lf7Ld1FXT2zonSzja0ePMRMS96pRS16T8DtjjZFKtTdwABA@mail.gmail.com>

Sorry want to reword the first paragraph since it didn't make sense.

I don't feel like my email was understood, because I explained how a
solution like the one you've just suggested is one we should eventually
add, but that regardless of that eventual feature, my current suggestion is
still a worthwhile feature to add on its own which does not conflict with
the future user-shader support.

On Thu, Aug 22, 2024, 7:44?PM Knee Snap <kneester77 at gmail.com> wrote:

> Was hoping to get feedback on my suggestion instead, but another
> suggestion doesn't work.
>
> The idea of a CustomMesh<TVertex> is impossible to implement until after
> we have fully user-supplied shader support, which I've already addressed as
> being not the scope of this change (but instead it is a separate future
> change which is not impacted by this) it also feels like this point may
> have been missed as well.
>
> On Thu, Aug 22, 2024, 6:28?PM Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
>
>> > Any solution which was good enough for normals is also good enough for
>> vertex colors right?
>>
>> Not necessarily. Designing APIs is hard, and one should try to start
>> from a point of asking "how would the API look like if we had
>> considered all of the things we know now from the beginning".
>>
>> An idea that might be worth exploring is the following. Instead of
>> storing positions, normals, texture coordinates, etc. in separate
>> buffers as it is currently done in TriangleMesh, we could have a
>> CustomMesh<TVertex>, where TVertex is a structure that stores all
>> relevant components in the same place. This could be a sealed
>> interface that only allows a limited set of implementations (because
>> we don't have the option of user-defined vertex structures at the
>> moment), but could allow for future extension with user-defined vertex
>> structures.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/2797355a/attachment-0001.htm>

From michaelstrau2 at gmail.com  Fri Aug 23 03:07:32 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 23 Aug 2024 05:07:32 +0200
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
Message-ID: <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>

I understand that you propose to add a special-purpose mesh
(GouraudShadedTriangleMesh) instead of adding yet another buffer to
the existing TriangleMesh. That might be a valid idea if the goal is
to not overload the TriangleMesh class with special-purpose stuff.

However, I still feel that the solution space in terms of API isn't
explored in enough detail here. It might be the case that
CustomMesh<TVertex> is not implementable (and it might also be the
case that CustomMesh<TVertex> isn't a good idea to begin with). But at
this point, none of this is obvious to me.

Usually, when you propose a new feature, you should explain the
motivation, goals and non-goals, alternatives, and so on (you can use
a JEP template for that if you like). You adequately addressed the
motivation for your proposed enhancement, but I feel that the
discussion of different approaches should be expanded upon. I'm not
convinced that CustomMesh<TVertex> is impossible to implement: if
TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
enforced, for example using sealed interfaces), then why wouldn't we
be able to connect this to our existing shaders?

Again, I'm not saying that this is a good idea; it might not work for
any number of reasons. But I think these alternative approaches should
at least be explored a little bit before dismissing them. Maybe it
will be GouraudShadedTriangleMesh in the end.


On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com> wrote:
>
> Was hoping to get feedback on my suggestion instead, but another suggestion doesn't work.
>
> The idea of a CustomMesh<TVertex> is impossible to implement until after we have fully user-supplied shader support, which I've already addressed as being not the scope of this change (but instead it is a separate future change which is not impacted by this) it also feels like this point may have been missed as well.

From arapte at openjdk.org  Fri Aug 23 04:40:10 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 23 Aug 2024 04:40:10 GMT
Subject: Integrated: 8338849: Update copyright header for files modified in
 2024
In-Reply-To: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
References: <Az3RjkY7p-8UjLQeH6FdxI7hd0kG1RrC6yZ1UrjwJuo=.0b87c4c8-ea4b-411b-9367-89b07d7ea83e@github.com>
Message-ID: <1h3lPezoscSXDuiAHzbQ3H3aja1hTK7XkERdKKdf_DM=.eb608591-ae1b-4581-81a9-969b0afa4616@github.com>

On Thu, 22 Aug 2024 16:09:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in year 2024.
> This update is done specifically to update the year in webkit files, so that the webkit source shows no diff.

This pull request has now been integrated.

Changeset: fac1c2ab
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/fac1c2abae822fbfa60057565a941a09ec51ffdd
Stats:     37 lines in 37 files changed: 0 ins; 0 del; 37 mod

8338849: Update copyright header for files modified in 2024

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1543

From kneester77 at gmail.com  Fri Aug 23 04:48:49 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Thu, 22 Aug 2024 21:48:49 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
Message-ID: <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>

Gottcha,

That helps give the context I need to better elaborate. And to be clear I'm
not suggesting you've done anything wrong, I realized maybe I had implied
that I was upset, so I just wanted to say explicitly that is not the case.

Anywho, regarding CustomMesh<TVertex> it would be impossible to inherit
from TriangleMesh.java without breaking the existing API specification. At
least, when I assume TVertex is the representation of a single vertex. If
this assumption was wrong, and it intended to be the definition of the
vertex, that scenario will also be addressed.

TriangleMesh.java does not currently use vertex objects, and making such a
TVertex to represent each individual vertex is incompatible without
changing the current public TriangleMesh API specification. If the idea of
a vertex object only exists within CustomMesh<TVertex> and not
TriangleMesh, then it's a second-class way of writing to mesh data since it
would only work on a subset of available mesh types, whereas writing
directly to the buffers (as it works now) would have worked in all cases.
If I (someone using JavaFX) want to make utilities for creating meshes, it
rules out using TVertex unless I commit to never using the base
TriangleMesh.

Additionally, using individual vertex objects provides no utility, but
requires a  decent amount of added code complexity, as now there needs to
be a way to correlate vertex objects with buffer positions, and keep them
up to date as the buffer also changes. (What does it mean when a vertex is
moved in the buffer, but the ObservableFloatArray wasn't told that and it
was just given a new full array replacement? This is currently the only way
to update an ObservableFloatArray. Let's consider this vertex object for a
second. What is it? Is it a wrapper around the underlying buffer? If so,
every single time the array changes, all vertex objects would become
invalidated as there's no way to ensure the objects point to the correct
data in the array, or even to know if that data even exists anymore. If
it's not a wrapper around the array then we'd need to make changes to the
array backport to the object. Which has the same problem since the main way
to update the array is to provide a fully new array, meaning we would have
no way to associate the new array contents with the old objects. The only
solution would be to break the API spec and make these new vertex objects
the authoritative data source and not the arrays, which breaks existing
code.

But I'd like to drive home the final nail. There's pretty much no benefit
to be had by having vertices as objects anyways. The 3D/GPU paradigm is
easiest to work with when treating vertex data as arrays and not individual
vertex objects. (Can refer to OpenInventor, Ogre, etc, to confirm this
design choice is standard across other object-oriented 3D frameworks). This
is because at the end of the day, this is what gets passed directly to the
GPU. Adding layers of abstraction is helpful for creating/modifying the
array, but not for representing it in memory.

In other words, while TVertex might intuitively make sense from a general
object-oriented perspective, array buffers are almost always preferable to
vertex objects, even in object-oriented projects. And when individual
objects are desired, they can exist / act as wrappers in user-code, which
benefits of objects we cannot provide automatically, as it requires
information only the user knows about the organization of the arrays.

But what about if TVertex is not a vertex,  but instead a definition of
what buffers the mesh has? Well, we already have that, and it's called
VertexFormat. Making it a generic parameter also wouldn't really provide
any benefit anyways. Instead of making CustomMesh<TriangleMesh>, I propose
expanding VertexFormat to allow for additional arbitrarily defined buffers.
However, I do not think we need to expose this functionality publicly yet,
which is why I've not documented it after the suggestion. We can keep it as
internal implementation details until it's time to add user-supplied
shaders. Doing so will give us maximum flexibility when it is time to make
it public.

This way also has the benefit of us being able to retroactively include
TriangleMesh's points/texCoords/normals arrays in the shader system with
very little complexity, as they are already part of VertexFormat.

Also thanks for the suggestion about the JEPs, I'll keep this in mind
making future proposals, and it sounds like I should follow-up discussing
various different implementation options and why I've chosen the one I've
chosen instead. I suspect the reason this feels somewhat underdeveloped
from the API perspective is because it's the simplest option I came up with
that had the best API outcome and I didn't elaborate as much as I could
have on why others I thought about weren't satisfactory.

Thanks again for the feedback, I look forward to hearing back again ?

On Thu, Aug 22, 2024, 8:08?PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> I understand that you propose to add a special-purpose mesh
> (GouraudShadedTriangleMesh) instead of adding yet another buffer to
> the existing TriangleMesh. That might be a valid idea if the goal is
> to not overload the TriangleMesh class with special-purpose stuff.
>
> However, I still feel that the solution space in terms of API isn't
> explored in enough detail here. It might be the case that
> CustomMesh<TVertex> is not implementable (and it might also be the
> case that CustomMesh<TVertex> isn't a good idea to begin with). But at
> this point, none of this is obvious to me.
>
> Usually, when you propose a new feature, you should explain the
> motivation, goals and non-goals, alternatives, and so on (you can use
> a JEP template for that if you like). You adequately addressed the
> motivation for your proposed enhancement, but I feel that the
> discussion of different approaches should be expanded upon. I'm not
> convinced that CustomMesh<TVertex> is impossible to implement: if
> TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
> PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
> enforced, for example using sealed interfaces), then why wouldn't we
> be able to connect this to our existing shaders?
>
> Again, I'm not saying that this is a good idea; it might not work for
> any number of reasons. But I think these alternative approaches should
> at least be explored a little bit before dismissing them. Maybe it
> will be GouraudShadedTriangleMesh in the end.
>
>
> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com> wrote:
> >
> > Was hoping to get feedback on my suggestion instead, but another
> suggestion doesn't work.
> >
> > The idea of a CustomMesh<TVertex> is impossible to implement until after
> we have fully user-supplied shader support, which I've already addressed as
> being not the scope of this change (but instead it is a separate future
> change which is not impacted by this) it also feels like this point may
> have been missed as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240822/0cacd8ad/attachment-0001.htm>

From jbhaskar at openjdk.org  Fri Aug 23 05:25:40 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 23 Aug 2024 05:25:40 GMT
Subject: RFR: 8338886: JavaFX debug builds fail on macOS
Message-ID: <Y0nV2K6uCJabJie_OfT_akCs_1AXWF4m5ChUHsmXzlg=.3707772c-2327-4dd5-9d93-6c274570a852@github.com>

Issue: ASSERT Statement: The ASSERT macro or function seems to be used to check if a condition involving ExceptionCode is true, but it's failing to compile.
Solution: The expression for ASSERT should be checked with type.

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

Commit messages:
 - 8338886: JavaFX debug builds fail on macOS

Changes: https://git.openjdk.org/jfx/pull/1544/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338886
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1544.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1544/head:pull/1544

PR: https://git.openjdk.org/jfx/pull/1544

From kizune at openjdk.org  Fri Aug 23 06:47:12 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 23 Aug 2024 06:47:12 GMT
Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText
 protocol [v3]
In-Reply-To: <bE40Pyuzo0RS4cfB-xcU2HtpBDc0FgMsSTLWUEOADnU=.3eb99a7d-398c-49d9-bd06-95bd2160d073@github.com>
References: <tNAv19HlBCz8rqrU71IOWeTvW8i6IAldDW3eK3PnYCM=.2ebdbe8a-b56b-4419-9b25-7c9945194ff0@github.com>
 <s8l7eZLklNqbIaCdcGHHt2PYdv2Y6ijPv70lJ8_aGX4=.30494879-0eab-41cd-be72-c2c5bb86c651@github.com>
 <0GI4R1bj5Vakx1Be1TIqGX_WhIIaa8y8VnkUuyQccLY=.8a707cac-1263-4186-9617-425881982e77@github.com>
 <aiXugd1DUEfTkgwzssjo5SNjXR8wxAPKJOGUU2B4iEU=.84f5e670-b0b6-4729-8a2b-0bcdea091fb8@github.com>
 <bE40Pyuzo0RS4cfB-xcU2HtpBDc0FgMsSTLWUEOADnU=.3eb99a7d-398c-49d9-bd06-95bd2160d073@github.com>
Message-ID: <2pDwkjWtcyaSRZtpop5g8e65Sb3fWWPHHop8fOSr-Rw=.8a274b60-b89f-4aa8-9ad2-5f1985325391@github.com>

On Tue, 6 Aug 2024 17:17:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Item 4 seems to have been introduced by this PR - don't see the issue with the master branch. Also, notice that we don't get a stack trace but a bunch of concatenated messages.

I can not reproduce this on my build - probably because i use Ensemble to test WebView, i will try again with MonkeyTester - but with Ensemble even without my fix i see a bunch of exceptions just by scrolling with my trackpad (without VoiceOver so not caused by the a11y code) that look like this:

SEVERE: RenderJob error
java.util.concurrent.ExecutionException: java.lang.NullPointerException: Cannot invoke "com.sun.prism.RTTexture.contentsUseful()" because "this.txt" is null
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at javafx.web at 24-internal/com.sun.javafx.webkit.prism.PrismInvoker.runOnRenderThread(PrismInvoker.java:93)
...

so i just wonder if there is something with github site which WebView can not load or parse which leads to the displayed structure being not correct hence errors when a11y code fetches properties of the text elements.

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

PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2306401192

From michaelstrau2 at gmail.com  Fri Aug 23 07:53:20 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 23 Aug 2024 09:53:20 +0200
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
 <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
Message-ID: <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>

I've created a rough prototype to illustrate what I mean:
https://github.com/mstr2/jfx/tree/experiments/vertexmesh

This is how you would use VertexMesh in an application:

    var mesh = new VertexMesh<>(Vertex.PositionTexCoord.class);

    mesh.getVertices().addAll(
        new Vertex.PositionTexCoord(
            new Point3D(0, 0, 0),
            new Point2D(0, 0)),

        new Vertex.PositionTexCoord(
            new Point3D(100, 0, 0),
            new Point2D(1, 0)),

        new Vertex.PositionTexCoord(
            new Point3D(0, 100, 0),
            new Point2D(0, 1))
    );

    mesh.getIndices().addAll(0, 2, 1);

    var meshView = new MeshView(mesh);
    meshView.setMaterial(new PhongMaterial(Color.RED));
    meshView.setCullFace(CullFace.NONE);

    stage.setScene(new Scene(new Group(meshView)));
    stage.show();


In addition to PositionTexCoord, we could then also offer
PositionNormal, PositionNormalTexCoord, PositionColor,
PositionNormalColor, and PositionNormalColorTexCoord. These objects
are supposed to be data carriers for vertices, and could be
user-definable in the future.

Note that this is by no means a well thought-out proposal, it's just a
rough sketch to get the basic idea across. Most likely, this API is
deficient in many ways, so take it as a discussion point rather than a
serious API proposal.



On Fri, Aug 23, 2024 at 6:49?AM Knee Snap <kneester77 at gmail.com> wrote:
>
> Gottcha,
>
> That helps give the context I need to better elaborate. And to be clear I'm not suggesting you've done anything wrong, I realized maybe I had implied that I was upset, so I just wanted to say explicitly that is not the case.
>
> Anywho, regarding CustomMesh<TVertex> it would be impossible to inherit from TriangleMesh.java without breaking the existing API specification. At least, when I assume TVertex is the representation of a single vertex. If this assumption was wrong, and it intended to be the definition of the vertex, that scenario will also be addressed.
>
> TriangleMesh.java does not currently use vertex objects, and making such a TVertex to represent each individual vertex is incompatible without changing the current public TriangleMesh API specification. If the idea of a vertex object only exists within CustomMesh<TVertex> and not TriangleMesh, then it's a second-class way of writing to mesh data since it would only work on a subset of available mesh types, whereas writing directly to the buffers (as it works now) would have worked in all cases. If I (someone using JavaFX) want to make utilities for creating meshes, it rules out using TVertex unless I commit to never using the base TriangleMesh.
>
> Additionally, using individual vertex objects provides no utility, but requires a  decent amount of added code complexity, as now there needs to be a way to correlate vertex objects with buffer positions, and keep them up to date as the buffer also changes. (What does it mean when a vertex is moved in the buffer, but the ObservableFloatArray wasn't told that and it was just given a new full array replacement? This is currently the only way to update an ObservableFloatArray. Let's consider this vertex object for a second. What is it? Is it a wrapper around the underlying buffer? If so, every single time the array changes, all vertex objects would become invalidated as there's no way to ensure the objects point to the correct data in the array, or even to know if that data even exists anymore. If it's not a wrapper around the array then we'd need to make changes to the array backport to the object. Which has the same problem since the main way to update the array is to provide a fully new array, meaning we would have no way to associate the new array contents with the old objects. The only solution would be to break the API spec and make these new vertex objects the authoritative data source and not the arrays, which breaks existing code.
>
> But I'd like to drive home the final nail. There's pretty much no benefit to be had by having vertices as objects anyways. The 3D/GPU paradigm is easiest to work with when treating vertex data as arrays and not individual vertex objects. (Can refer to OpenInventor, Ogre, etc, to confirm this design choice is standard across other object-oriented 3D frameworks). This is because at the end of the day, this is what gets passed directly to the GPU. Adding layers of abstraction is helpful for creating/modifying the array, but not for representing it in memory.
>
> In other words, while TVertex might intuitively make sense from a general object-oriented perspective, array buffers are almost always preferable to vertex objects, even in object-oriented projects. And when individual objects are desired, they can exist / act as wrappers in user-code, which benefits of objects we cannot provide automatically, as it requires information only the user knows about the organization of the arrays.
>
> But what about if TVertex is not a vertex,  but instead a definition of what buffers the mesh has? Well, we already have that, and it's called VertexFormat. Making it a generic parameter also wouldn't really provide any benefit anyways. Instead of making CustomMesh<TriangleMesh>, I propose expanding VertexFormat to allow for additional arbitrarily defined buffers. However, I do not think we need to expose this functionality publicly yet, which is why I've not documented it after the suggestion. We can keep it as internal implementation details until it's time to add user-supplied shaders. Doing so will give us maximum flexibility when it is time to make it public.
>
> This way also has the benefit of us being able to retroactively include TriangleMesh's points/texCoords/normals arrays in the shader system with very little complexity, as they are already part of VertexFormat.
>
> Also thanks for the suggestion about the JEPs, I'll keep this in mind making future proposals, and it sounds like I should follow-up discussing various different implementation options and why I've chosen the one I've chosen instead. I suspect the reason this feels somewhat underdeveloped from the API perspective is because it's the simplest option I came up with that had the best API outcome and I didn't elaborate as much as I could have on why others I thought about weren't satisfactory.
>
> Thanks again for the feedback, I look forward to hearing back again ?
>
> On Thu, Aug 22, 2024, 8:08?PM Michael Strau? <michaelstrau2 at gmail.com> wrote:
>>
>> I understand that you propose to add a special-purpose mesh
>> (GouraudShadedTriangleMesh) instead of adding yet another buffer to
>> the existing TriangleMesh. That might be a valid idea if the goal is
>> to not overload the TriangleMesh class with special-purpose stuff.
>>
>> However, I still feel that the solution space in terms of API isn't
>> explored in enough detail here. It might be the case that
>> CustomMesh<TVertex> is not implementable (and it might also be the
>> case that CustomMesh<TVertex> isn't a good idea to begin with). But at
>> this point, none of this is obvious to me.
>>
>> Usually, when you propose a new feature, you should explain the
>> motivation, goals and non-goals, alternatives, and so on (you can use
>> a JEP template for that if you like). You adequately addressed the
>> motivation for your proposed enhancement, but I feel that the
>> discussion of different approaches should be expanded upon. I'm not
>> convinced that CustomMesh<TVertex> is impossible to implement: if
>> TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
>> PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
>> enforced, for example using sealed interfaces), then why wouldn't we
>> be able to connect this to our existing shaders?
>>
>> Again, I'm not saying that this is a good idea; it might not work for
>> any number of reasons. But I think these alternative approaches should
>> at least be explored a little bit before dismissing them. Maybe it
>> will be GouraudShadedTriangleMesh in the end.
>>
>>
>> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com> wrote:
>> >
>> > Was hoping to get feedback on my suggestion instead, but another suggestion doesn't work.
>> >
>> > The idea of a CustomMesh<TVertex> is impossible to implement until after we have fully user-supplied shader support, which I've already addressed as being not the scope of this change (but instead it is a separate future change which is not impacted by this) it also feels like this point may have been missed as well.

From sykora at openjdk.org  Fri Aug 23 12:16:10 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Fri, 23 Aug 2024 12:16:10 GMT
Subject: RFR: 8338307 : Additional WebKit 619.1 fixes from WebKitGTK 2.44.3
In-Reply-To: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
References: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
Message-ID: <O0AGleDZhq2wOZPy6aFv3ZhnsDiNgnnIlh_D_ihz1kY=.bef7b59b-d9c4-430b-8ed8-27b0abcb5d25@github.com>

On Wed, 21 Aug 2024 09:53:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated additonal fixes from webkit-2.44.3. Verified build on all platforms. No issue seen.

Builds and tests were successful on our infrastructure.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1541#pullrequestreview-2257085624

From john.hendrikx at gmail.com  Fri Aug 23 12:49:01 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 23 Aug 2024 14:49:01 +0200
Subject: Accidentally reproduced NPE in synchronizeNodes in combination
 with enterNestedEventLoop
In-Reply-To: <CAJEpuXSn0ac==c1K7syDfO14U+42XTSPHjuy+nVKkmgELu_-ug@mail.gmail.com>
References: <efc29c6d-9b12-408b-9328-af181c42ba5d@gmail.com>
 <a255c77d-3bac-48c2-ae4e-20b9053812ad@gmail.com>
 <CAJEpuXSn0ac==c1K7syDfO14U+42XTSPHjuy+nVKkmgELu_-ug@mail.gmail.com>
Message-ID: <fd530a2f-c3da-4b34-bb64-dcf4fd7d8731@gmail.com>

I haven't got anything concrete yet, but I did look into "transactional" 
properties before for a similar reason.

The "when" fluent method on ObservableValue does something similar.? 
When its condition is false, it doesn't communicate changes downstream, 
but when it is set to true, it will do so immediately (if there was a 
change).? In other words, you could do this:

 ?????? // define public observables like this:
 ?????? x.when(finishedUpdating);
 ?????? y.when(finishedUpdating);

 ?????? // In code that must be executed as a block that sets properties do:
 ?????? finishedUpdating.set(false);

 ?????? // modify x/y
 ?????? // do other reentrant unsafe stuff

 ?????? // finally allow callbacks again:
 ?????? finishedUpdating.set(true);? // this triggers the events

Of course, this only works with observables, and not with writable 
properties, so we need to invent something new here...

I also now don't think other solutions are going to work for the 
children list problem.? Setting "startIdx" after each child update would 
leave updatePeer potentially with children that don't have their Scene 
or Parent set correctly yet... the same goes for de-optimizing 
updatePeer and just letting it sync the entire children list; it would 
encounter children that have no parent or scene set yet if it is 
triggered halfway during the children list update.

The whole process of adding a child to a Parent is supposed to be atomic:

- There should never be a child that is part of two Parents (or is used 
as clip, etc)
- There should be no duplicate children in a single Parent
- Child.scene always equals Parent.scene
- etc...

Yet you can violate some of these by attaching listeners to the 
properties/lists it is manipulating because the process is not atomic.

> Of course, the implementation will be challenging. We'd need to keep
> track of all modifications, and then aggregate those modifications
> into a single event. In this particular example, the two "add" and
> "remove" events would probably be consolidated into a "permutation"
> event.

Yeah, for ObservableLists the problem will be harder then for 
properties.? Properties can track an old value to compare with a bit 
easier.? Keeping a copy of a large list to calculate differences with is 
a bit more annoying.? However, Lists are documented to not allow further 
changes:

* <b>Warning:</b>This class directly accesses the source list to acquire 
information about the changes.

* <br>This effectively makes the Change object invalid when another 
change occurs on the list.

* <br>For this reason it is <b>not safe to use this class on a different 
thread</b>.

* <br>It also means <b>the source list cannot be modified inside the 
listener</b>since that would invalidate this Change object

* for all subsequent listeners.

This means that for Lists we could get away with simply signalling this 
problem with a "ConcurrentModificationException". I added such an 
exception in ObservableListBase and it is effective at stopping the problem:

protectedfinalvoidbeginChange() {

if(inChangeFire) {

thrownewConcurrentModificationException();

}

changeBuilder.beginChange();

}

protectedfinalvoidfireChange(ListChangeListener.Change<? extendsE> change) {

inChangeFire= true;

try{

ListListenerHelper.fireValueChangedEvent(listenerHelper, change);

}

finally{

inChangeFire= false;

}

}

For?property classes, I like the idea of a thread scoped type object -- 
the properties are after all being manipulated on a single thread, and a 
thread local check to see if a transactional scope is active could be 
relatively cheap to built into existing properties.? Something like:

 ????? Transaction tx = TX_THREAD_LOCAL.get();

 ????? if (tx == null) {
 ?????????? invalidate();
 ????? }
 ????? else {
 ????????? // in transaction, register listener to invalidate when it ends
 ????????? tx.subscribe(this::invalidate);
 ????? }

The Transaction class could also somehow be used to support tracking 
list/set changes and consolidate these changes.

--John


On 23/08/2024 04:31, Michael Strau? wrote:
> That seems to be a tough one.
>
> Delaying the invocation of listeners sounds interesting, as it might
> allow using a pattern like the following:
>
>      childrenTriggerPermutation = true;
>
>      try (var scope = new DelayedEventScope(children)) {
>          children.remove(node);
>          children.add(node);
>      } finally {
>          childrenTriggerPermutation = false;
>      }
>
> The semantics would be that the property implementation will still
> receive notifications with their invalidated() method as the property
> is being modified, but events will only be fired at the end of the
> scope.
> List properties will need a new listChanged() method to allow for the
> same pattern of overriding the method instead of adding a change
> listener.
>
> Of course, the implementation will be challenging. We'd need to keep
> track of all modifications, and then aggregate those modifications
> into a single event. In this particular example, the two "add" and
> "remove" events would probably be consolidated into a "permutation"
> event.
>
> In general, delayed notification scopes for properties could also be
> very useful for application developers.
>
>
> On Thu, Aug 22, 2024 at 9:59?AM John Hendrikx<john.hendrikx at gmail.com>  wrote:
>> I think I figured out the reason why this fails.  The root cause lies in a misconception I've seen in a lot of FX code.
>>
>> JavaFX uses a single event thread model, which ensures all structures are only ever accessed by a single thread.  This frees FX from having to do synchronization on almost every modification you make to properties or the scene graph.
>>
>> However, in many areas it makes the assumption that such code will always run sequentially to completion without interruption, and uses instance fields judiciously to communicate things to deeper nested code or to code further down the line.  But code using instance fields in this way is not safe to re-enter (it is not reentrant-safe) without precautions -- sharing instance fields in this way safely can easily get as complicated as writing multi-threaded code.
>>
>> A simple example that I saw in Parent's toFront code:
>>
>> childrenTriggerPermutation = true;
>>
>> try {
>>
>> children.remove(node);
>>
>> children.add(node);
>>
>> } finally {
>>
>> childrenTriggerPermutation = false;
>>
>> }
>>
>> The above code uses an instance field "childrenTriggerPermutation" to activate an optimization. The optimization will assume that the children are only re-arranged, and no new ones were added or removed.  However, "children" is an ObservableList, which means the user can register listeners on it, which do who knows what.  If such a listener modifies the children list in another way then the code is entered again, but the "childrenTriggerPermutation" optimization will still be enabled causing it to not notice the change the user did.
>>
>> This problem is similar to the ChangeListener old value bug.  When within a change listener you do another change (and so the same code is called **deeper** in the same stack), downstream change listeners will not receive the correct old values because the code is insufficiently reentrant-safe.  ExpressionHelper **tries** to mitigate some of these issues (for cases where listeners are added/removed reentrantly) by making copies of the listener list, but it does not handle this case.
>>
>> Similarly, the bug I encountered in my original post is also such an issue.  While processing the children list changes, several **properties** are being manipulated.  Being properties, these can have listeners of their own that could trigger further modifications and, in complex enough programs, they may even re-enter the same class's code that is sharing instance fields in an unsafe way.  And that's exactly what is happening:
>>
>> 1. The children list change processing is registering the offset of the first changed child in the children list (called "startIdx") as an instance field -- this field is used as an optimization for updatePeer (so it doesn't have to check/copy all children).  It assumes the processing always finishes completely and it will get to the point where it sets "startIdx" but...
>>
>> 2. Before it sets "startIdx" but after the children list is already modified, it modifies several properties.  Being properties, these can have listeners, and as such this can trigger a cascade of further calls in complicated applications.
>>
>> 3. In this case, the cascade of calls included an "enterNestedEventLoop".  Pulses (and things like Platform#runLater) can be handled on such a nested loop, and FX decides that now is as good a time as any to handle a new pulse.
>>
>> 4. The pulse triggers updatePeer calls, among which is the Parent that is still (higher in the stack) midway its children list processing code.
>>
>> 5. The updatePeer code looks at "startIdx", the shared instance field that Parent uses for its optimizations.  This field is NOT modified yet.  The field indicates the first child that was modified, and the field is normally set to "children.size()" when there are no changes.  That's also the case in this case still, and so updatePeer updates nothing at all.  An assertion later in this code then checks if children.size() == peer.children.size() which fails... a stack trace is thrown, and synchronizeSceneNodes() blows up with infinite NPE's.
>>
>> I'm not entirely sure yet how to resolve this, and if it should be.
>>
>> Perhaps the safest way would be to undo some of the optimizations/assumptions, and perhaps reoptimize them if there's a pressing need.
>>
>> Another option would be to somehow delay listener callbacks until the code in Parent is in a safe state.
>>
>> The option I like the least is to introduce yet another instance flag ("processingListChange") and throwing an early exception if other code is entered that doesn't expect it...
>>
>> --John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240823/ae670a18/attachment-0001.htm>

From hmeda at openjdk.org  Fri Aug 23 13:44:10 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Fri, 23 Aug 2024 13:44:10 GMT
Subject: Integrated: 8338307 : Additional WebKit 619.1 fixes from WebKitGTK
 2.44.3
In-Reply-To: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
References: <EtdAASlijff4dUeD-LGDuaUcEcy1tG4LND15rDHBX08=.97e06c91-4d7e-4de7-8d73-660e50dcd39d@github.com>
Message-ID: <lp_DRZoD7ZSJrY8HzkjeV9ar2rLDV03hDeauL9nfx54=.2f927270-0832-4b69-b249-83c0855ebdf3@github.com>

On Wed, 21 Aug 2024 09:53:24 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated additonal fixes from webkit-2.44.3. Verified build on all platforms. No issue seen.

This pull request has now been integrated.

Changeset: aa52f7ef
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/aa52f7efc370a4c55ff7a05a6903988871436d64
Stats:     1276 lines in 181 files changed: 721 ins; 113 del; 442 mod

8338307: Additional WebKit 619.1 fixes from WebKitGTK 2.44.3

Reviewed-by: kcr, sykora

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

PR: https://git.openjdk.org/jfx/pull/1541

From kcr at openjdk.org  Fri Aug 23 16:20:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 23 Aug 2024 16:20:09 GMT
Subject: RFR: 8338886: JavaFX debug builds fail on macOS
In-Reply-To: <Y0nV2K6uCJabJie_OfT_akCs_1AXWF4m5ChUHsmXzlg=.3707772c-2327-4dd5-9d93-6c274570a852@github.com>
References: <Y0nV2K6uCJabJie_OfT_akCs_1AXWF4m5ChUHsmXzlg=.3707772c-2327-4dd5-9d93-6c274570a852@github.com>
Message-ID: <vMnzqv6y4SvVx8yhSjyJ11nHsVdZz3ObRrXTkOOhu08=.9245563d-1d4c-4c59-9749-451b9b6cf9d8@github.com>

On Fri, 23 Aug 2024 05:21:21 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: ASSERT Statement: The ASSERT macro or function seems to be used to check if a condition involving ExceptionCode is true, but it's failing to compile.
> Solution: The expression for ASSERT should be checked with type.

This is a trivial fix that only affects a debug build. It does not affect production builds or ordinary developer builds. A single reviewer is sufficient.

The fix looks good. I can now build in debug mode using: `gradle -PCONF=DebugNative`

Running the debug build on my M1 Mac and loading a non-trivial web page crashes after a short time with a call to "abort()", but that's unrelated to this build failure and should be handled as a follow-on bug.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1544#pullrequestreview-2257612449

From jbhaskar at openjdk.org  Fri Aug 23 16:37:13 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 23 Aug 2024 16:37:13 GMT
Subject: Integrated: 8338886: JavaFX debug builds fail on macOS
In-Reply-To: <Y0nV2K6uCJabJie_OfT_akCs_1AXWF4m5ChUHsmXzlg=.3707772c-2327-4dd5-9d93-6c274570a852@github.com>
References: <Y0nV2K6uCJabJie_OfT_akCs_1AXWF4m5ChUHsmXzlg=.3707772c-2327-4dd5-9d93-6c274570a852@github.com>
Message-ID: <AJTJF89aoxz7kLJvo8QMa4P21-Szg9th86H_NLIROnA=.aea91de8-66fa-44e1-9975-3e1ef11a169e@github.com>

On Fri, 23 Aug 2024 05:21:21 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: ASSERT Statement: The ASSERT macro or function seems to be used to check if a condition involving ExceptionCode is true, but it's failing to compile.
> Solution: The expression for ASSERT should be checked with type.

This pull request has now been integrated.

Changeset: 48497168
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/48497168892f5625f77936eccf19e836a6c1971e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338886: JavaFX debug builds fail on macOS

Reviewed-by: kcr

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

PR: https://git.openjdk.org/jfx/pull/1544

From almatvee at openjdk.org  Fri Aug 23 18:22:13 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 23 Aug 2024 18:22:13 GMT
Subject: Integrated: 8336940: Update GStreamer to 1.24.6
In-Reply-To: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
References: <gSo0zUPAGjmxGqVXjchGclabNc2Fwlgd5i_ZioglzqM=.c53941d7-64ef-4633-b636-c6d5290a28f4@github.com>
Message-ID: <OP_vLEAQL_5-TEQloFBCoory5LCcwQ2MOfcl6foiLI0=.82257bf8-4c28-422a-8475-3faa78b75733@github.com>

On Wed, 21 Aug 2024 20:15:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Updated GStreamer to 1.24.6 and Glib to 2.80.4.
> - Testing done on all platforms with all supported formats.
> - Removed gstpluginloader.c. This file contains additional plugin loading mechanism which we do not use. Latest GStreamer modified it heavily and it did not compile without pulling additional dependency from GLib, but since we do not use it anyway it was removed. Corresponding calls to gstpluginloader.c from gstregistry.c were disabled as well.
> - Removed DSD support from Alsa audio sink. Latest GStreamer added support for Alsa DSD (Direct Stream Digital), but we do not use it so it was removed. Also, such support requires newer libasound2 (ALSA) which is not available on older Linux distributions.
> - No other changes or bug fixes are done.

This pull request has now been integrated.

Changeset: b88ac049
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b88ac0495650bd033ba11e3131e9bffc517872eb
Stats:     24630 lines in 329 files changed: 13062 ins; 6878 del; 4690 mod

8336940: Update GStreamer to 1.24.6
8336939: Update Glib to 2.80.4

Reviewed-by: kcr, sykora

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

PR: https://git.openjdk.org/jfx/pull/1542

From dalibor.topic at oracle.com  Fri Aug 23 20:32:05 2024
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 23 Aug 2024 22:32:05 +0200
Subject: It is not possible to create a new bug in Java Bug Database
In-Reply-To: <3a5b4bf3-95a7-42f6-b4f6-60321e7c5ffe@gmail.com>
References: <3a5b4bf3-95a7-42f6-b4f6-60321e7c5ffe@gmail.com>
Message-ID: <b19dd403-2be1-4a02-b75d-bcc9e8098937@oracle.com>



On 22.08.2024 08:33, PavelTurk wrote:
> Hello, all.
> 
> It is the second day I am trying to create a JavaFX bug - 
> https://bugreport.java.com/bugreport/submit_start.
> 
> After I fill in all the fields and press the submit button I get 504 
> Gateway Time-out.
> 
> Please inform your colleagues at Oracle about this.

Thanks, Pavel, I've passed it on.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From kneester77 at gmail.com  Fri Aug 23 21:03:37 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Fri, 23 Aug 2024 14:03:37 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
 <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
 <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>
Message-ID: <CAB9Lf7+Nu0TTNpxuqHgqV4yUP3N3sYOXy=C0PyqCkzeSoXrpWA@mail.gmail.com>

Thanks for the clarification on how the design would work.

However, this design is separate/unrelated to the goal of this feature
proposal.
Instead of extending TriangleMesh, you imagine a new separate mesh which
can eventually be used to support user-supplied shaders.
I do hope to propose such a feature at a future date (support user-defined
shaders), but until such a proposal this system isn't super relevant /
doesn't have much relation to the current proposal.


*The future we both see for the future of working with meshes is a scenario
with two (or potentially more) mesh classes:*
*#1) *TriangleMesh (No dealing with shaders, buffers, and other advanced
capabilities)
*#2) *VertexMesh (or name it ShaderMesh, etc), which allows the user to do
more advanced capabilities and lets the user define their own
buffers, which could end up looking like the design you've shown.

But critical to this design is understanding that only TriangleMesh needs
explicit vertex color support.
VertexMesh/ShaderMesh/etc would be able to support vertex colors implicitly
due to its ability to have the user supply arbitrary buffers and shaders.
So the whole purpose of my proposal is that this feature belongs in
TriangleMesh (or an extension of TriangleMesh), but is currently missing.
The example you've linked however does not extend TriangleMesh, instead
it's starting work on the future proposal, ignoring the need for this
feature in the existing TriangleMesh.

I hope this helps clarify!

On Fri, Aug 23, 2024 at 12:53?AM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> I've created a rough prototype to illustrate what I mean:
> https://github.com/mstr2/jfx/tree/experiments/vertexmesh
>
> This is how you would use VertexMesh in an application:
>
>     var mesh = new VertexMesh<>(Vertex.PositionTexCoord.class);
>
>     mesh.getVertices().addAll(
>         new Vertex.PositionTexCoord(
>             new Point3D(0, 0, 0),
>             new Point2D(0, 0)),
>
>         new Vertex.PositionTexCoord(
>             new Point3D(100, 0, 0),
>             new Point2D(1, 0)),
>
>         new Vertex.PositionTexCoord(
>             new Point3D(0, 100, 0),
>             new Point2D(0, 1))
>     );
>
>     mesh.getIndices().addAll(0, 2, 1);
>
>     var meshView = new MeshView(mesh);
>     meshView.setMaterial(new PhongMaterial(Color.RED));
>     meshView.setCullFace(CullFace.NONE);
>
>     stage.setScene(new Scene(new Group(meshView)));
>     stage.show();
>
>
> In addition to PositionTexCoord, we could then also offer
> PositionNormal, PositionNormalTexCoord, PositionColor,
> PositionNormalColor, and PositionNormalColorTexCoord. These objects
> are supposed to be data carriers for vertices, and could be
> user-definable in the future.
>
> Note that this is by no means a well thought-out proposal, it's just a
> rough sketch to get the basic idea across. Most likely, this API is
> deficient in many ways, so take it as a discussion point rather than a
> serious API proposal.
>
>
>
> On Fri, Aug 23, 2024 at 6:49?AM Knee Snap <kneester77 at gmail.com> wrote:
> >
> > Gottcha,
> >
> > That helps give the context I need to better elaborate. And to be clear
> I'm not suggesting you've done anything wrong, I realized maybe I had
> implied that I was upset, so I just wanted to say explicitly that is not
> the case.
> >
> > Anywho, regarding CustomMesh<TVertex> it would be impossible to inherit
> from TriangleMesh.java without breaking the existing API specification. At
> least, when I assume TVertex is the representation of a single vertex. If
> this assumption was wrong, and it intended to be the definition of the
> vertex, that scenario will also be addressed.
> >
> > TriangleMesh.java does not currently use vertex objects, and making such
> a TVertex to represent each individual vertex is incompatible without
> changing the current public TriangleMesh API specification. If the idea of
> a vertex object only exists within CustomMesh<TVertex> and not
> TriangleMesh, then it's a second-class way of writing to mesh data since it
> would only work on a subset of available mesh types, whereas writing
> directly to the buffers (as it works now) would have worked in all cases.
> If I (someone using JavaFX) want to make utilities for creating meshes, it
> rules out using TVertex unless I commit to never using the base
> TriangleMesh.
> >
> > Additionally, using individual vertex objects provides no utility, but
> requires a  decent amount of added code complexity, as now there needs to
> be a way to correlate vertex objects with buffer positions, and keep them
> up to date as the buffer also changes. (What does it mean when a vertex is
> moved in the buffer, but the ObservableFloatArray wasn't told that and it
> was just given a new full array replacement? This is currently the only way
> to update an ObservableFloatArray. Let's consider this vertex object for a
> second. What is it? Is it a wrapper around the underlying buffer? If so,
> every single time the array changes, all vertex objects would become
> invalidated as there's no way to ensure the objects point to the correct
> data in the array, or even to know if that data even exists anymore. If
> it's not a wrapper around the array then we'd need to make changes to the
> array backport to the object. Which has the same problem since the main way
> to update the array is to provide a fully new array, meaning we would have
> no way to associate the new array contents with the old objects. The only
> solution would be to break the API spec and make these new vertex objects
> the authoritative data source and not the arrays, which breaks existing
> code.
> >
> > But I'd like to drive home the final nail. There's pretty much no
> benefit to be had by having vertices as objects anyways. The 3D/GPU
> paradigm is easiest to work with when treating vertex data as arrays and
> not individual vertex objects. (Can refer to OpenInventor, Ogre, etc, to
> confirm this design choice is standard across other object-oriented 3D
> frameworks). This is because at the end of the day, this is what gets
> passed directly to the GPU. Adding layers of abstraction is helpful for
> creating/modifying the array, but not for representing it in memory.
> >
> > In other words, while TVertex might intuitively make sense from a
> general object-oriented perspective, array buffers are almost always
> preferable to vertex objects, even in object-oriented projects. And when
> individual objects are desired, they can exist / act as wrappers in
> user-code, which benefits of objects we cannot provide automatically, as it
> requires information only the user knows about the organization of the
> arrays.
> >
> > But what about if TVertex is not a vertex,  but instead a definition of
> what buffers the mesh has? Well, we already have that, and it's called
> VertexFormat. Making it a generic parameter also wouldn't really provide
> any benefit anyways. Instead of making CustomMesh<TriangleMesh>, I propose
> expanding VertexFormat to allow for additional arbitrarily defined buffers.
> However, I do not think we need to expose this functionality publicly yet,
> which is why I've not documented it after the suggestion. We can keep it as
> internal implementation details until it's time to add user-supplied
> shaders. Doing so will give us maximum flexibility when it is time to make
> it public.
> >
> > This way also has the benefit of us being able to retroactively include
> TriangleMesh's points/texCoords/normals arrays in the shader system with
> very little complexity, as they are already part of VertexFormat.
> >
> > Also thanks for the suggestion about the JEPs, I'll keep this in mind
> making future proposals, and it sounds like I should follow-up discussing
> various different implementation options and why I've chosen the one I've
> chosen instead. I suspect the reason this feels somewhat underdeveloped
> from the API perspective is because it's the simplest option I came up with
> that had the best API outcome and I didn't elaborate as much as I could
> have on why others I thought about weren't satisfactory.
> >
> > Thanks again for the feedback, I look forward to hearing back again ?
> >
> > On Thu, Aug 22, 2024, 8:08?PM Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
> >>
> >> I understand that you propose to add a special-purpose mesh
> >> (GouraudShadedTriangleMesh) instead of adding yet another buffer to
> >> the existing TriangleMesh. That might be a valid idea if the goal is
> >> to not overload the TriangleMesh class with special-purpose stuff.
> >>
> >> However, I still feel that the solution space in terms of API isn't
> >> explored in enough detail here. It might be the case that
> >> CustomMesh<TVertex> is not implementable (and it might also be the
> >> case that CustomMesh<TVertex> isn't a good idea to begin with). But at
> >> this point, none of this is obvious to me.
> >>
> >> Usually, when you propose a new feature, you should explain the
> >> motivation, goals and non-goals, alternatives, and so on (you can use
> >> a JEP template for that if you like). You adequately addressed the
> >> motivation for your proposed enhancement, but I feel that the
> >> discussion of different approaches should be expanded upon. I'm not
> >> convinced that CustomMesh<TVertex> is impossible to implement: if
> >> TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
> >> PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
> >> enforced, for example using sealed interfaces), then why wouldn't we
> >> be able to connect this to our existing shaders?
> >>
> >> Again, I'm not saying that this is a good idea; it might not work for
> >> any number of reasons. But I think these alternative approaches should
> >> at least be explored a little bit before dismissing them. Maybe it
> >> will be GouraudShadedTriangleMesh in the end.
> >>
> >>
> >> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com> wrote:
> >> >
> >> > Was hoping to get feedback on my suggestion instead, but another
> suggestion doesn't work.
> >> >
> >> > The idea of a CustomMesh<TVertex> is impossible to implement until
> after we have fully user-supplied shader support, which I've already
> addressed as being not the scope of this change (but instead it is a
> separate future change which is not impacted by this) it also feels like
> this point may have been missed as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240823/d53f90fc/attachment-0001.htm>

From almatvee at openjdk.org  Fri Aug 23 22:35:34 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 23 Aug 2024 22:35:34 GMT
Subject: [jfx23u] RFR: 8336940: Update GStreamer to 1.24.6
Message-ID: <PSK9TRaawEaJBE3NE91wdz0r-Pu-t32HGH_pT1IER7Q=.a77726ff-3068-421f-9c17-350fe0c28ba3@github.com>

Clean backport of JDK-8336940 and JDK-8336939.

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

Commit messages:
 - Backport b88ac0495650bd033ba11e3131e9bffc517872eb

Changes: https://git.openjdk.org/jfx23u/pull/14/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336940
  Stats: 24630 lines in 329 files changed: 13062 ins; 6878 del; 4690 mod
  Patch: https://git.openjdk.org/jfx23u/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/14/head:pull/14

PR: https://git.openjdk.org/jfx23u/pull/14

From dalibor.topic at oracle.com  Sat Aug 24 14:26:55 2024
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Sat, 24 Aug 2024 16:26:55 +0200
Subject: It is not possible to create a new bug in Java Bug Database
In-Reply-To: <b19dd403-2be1-4a02-b75d-bcc9e8098937@oracle.com>
References: <3a5b4bf3-95a7-42f6-b4f6-60321e7c5ffe@gmail.com>
 <b19dd403-2be1-4a02-b75d-bcc9e8098937@oracle.com>
Message-ID: <8a9d484e-deca-499a-998a-e5326589406e@oracle.com>



On 23.08.2024 22:32, Dalibor Topic wrote:
> 
> 
> On 22.08.2024 08:33, PavelTurk wrote:
>> Hello, all.
>>
>> It is the second day I am trying to create a JavaFX bug - 
>> https://bugreport.java.com/bugreport/submit_start.
>>
>> After I fill in all the fields and press the submit button I get 504 
>> Gateway Time-out.
>>
>> Please inform your colleagues at Oracle about this.
> 
> Thanks, Pavel, I've passed it on.

Hi Pavel,

the site is back up and running again. Apologies for the delay - please 
try resubmitting the issue.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From pavelturk2000 at gmail.com  Sun Aug 25 08:22:39 2024
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Sun, 25 Aug 2024 11:22:39 +0300
Subject: It is not possible to create a new bug in Java Bug Database
In-Reply-To: <8a9d484e-deca-499a-998a-e5326589406e@oracle.com>
References: <3a5b4bf3-95a7-42f6-b4f6-60321e7c5ffe@gmail.com>
 <b19dd403-2be1-4a02-b75d-bcc9e8098937@oracle.com>
 <8a9d484e-deca-499a-998a-e5326589406e@oracle.com>
Message-ID: <9853d023-c85c-4dc9-bc00-ca0ed6ad3ead@gmail.com>

Hi Dalibor,

I've checked. Everything is working. Thank you very much!

Best regards, Pavel

On 8/24/24 17:26, Dalibor Topic wrote:
>
>
> On 23.08.2024 22:32, Dalibor Topic wrote:
>>
>>
>> On 22.08.2024 08:33, PavelTurk wrote:
>>> Hello, all.
>>>
>>> It is the second day I am trying to create a JavaFX bug - https://bugreport.java.com/bugreport/submit_start.
>>>
>>> After I fill in all the fields and press the submit button I get 504 Gateway Time-out.
>>>
>>> Please inform your colleagues at Oracle about this.
>>
>> Thanks, Pavel, I've passed it on.
>
> Hi Pavel,
>
> the site is back up and running again. Apologies for the delay - please try resubmitting the issue.
>
> cheers,
> dalibor topic
>


From crschnick at xpipe.io  Sun Aug 25 11:40:11 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sun, 25 Aug 2024 13:40:11 +0200
Subject: Nodes are not rendered after window resize
Message-ID: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>

Hello,

so it seems like there is a rare bug in JavaFX (at least on Windows) 
where after a resize operation, some controls are rendered as white 
boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10. 
There were no exceptions thrown or methods called from a non-platform 
thread. I was not able to reproduce this consistently so far. I would 
argue it happens around every 50 runs of an application for me.

There were a couple of posts with videos of the problem:
- 
https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/
- 
https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html 
(I wrongly reported it as a toolbar bug, it seems to be a more general one)

I can sometimes enter this state shown in the videos by resizing a stage 
from for example 1280x720, to fullscreen, back to 1280x720, and to 
fullscreen again. It seems like the renderer dimensions become broken in 
some cases and are no longer updated on consecutive scene resize 
operations, so they always stay on an old value. If in this case the 
scene fits into a stage with size 1280x720 and is resized to fullscreen, 
any nodes outside the old scene bounds are rendered as these white 
artifacts, presumably because the renderer thinks that they are not 
visible. It seems like the renderer thinks they are outside the 
scene/stage because it still has the old scene dimensions. I was not 
able to get the application out of this invalid state without restarting it.

If anyone could advise me on what kind of properties I can pass to 
JavaFX or what kind of actions I can do to narrow this down, that would 
be great.

Best regards, Christopher


From eduard.sdv at web.de  Sun Aug 25 12:06:12 2024
From: eduard.sdv at web.de (Eduard Sedov)
Date: Sun, 25 Aug 2024 14:06:12 +0200
Subject: Nodes are not rendered after window resize
In-Reply-To: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
References: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
Message-ID: <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>

Hello Christopher,

You can try to pass the following parameter to jvm:

-Dprism.dirtyregioncount=1

If it helps, then it's probably the same bug that was fixed in this pull request:

https://github.com/openjdk/jfx/pull/1451

- eduard


Am 25. Aug. 2024, 13:43, um 13:43, Christopher Schnick <crschnick at xpipe.io> schrieb:
>Hello,
>
>so it seems like there is a rare bug in JavaFX (at least on Windows)
>where after a resize operation, some controls are rendered as white
>boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10.
>
>There were no exceptions thrown or methods called from a non-platform
>thread. I was not able to reproduce this consistently so far. I would
>argue it happens around every 50 runs of an application for me.
>
>There were a couple of posts with videos of the problem:
>-
>https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/
>-
>https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html
>
>(I wrongly reported it as a toolbar bug, it seems to be a more general
>one)
>
>I can sometimes enter this state shown in the videos by resizing a
>stage
>from for example 1280x720, to fullscreen, back to 1280x720, and to
>fullscreen again. It seems like the renderer dimensions become broken
>in
>some cases and are no longer updated on consecutive scene resize
>operations, so they always stay on an old value. If in this case the
>scene fits into a stage with size 1280x720 and is resized to
>fullscreen,
>any nodes outside the old scene bounds are rendered as these white
>artifacts, presumably because the renderer thinks that they are not
>visible. It seems like the renderer thinks they are outside the
>scene/stage because it still has the old scene dimensions. I was not
>able to get the application out of this invalid state without
>restarting it.
>
>If anyone could advise me on what kind of properties I can pass to
>JavaFX or what kind of actions I can do to narrow this down, that would
>
>be great.
>
>Best regards, Christopher


From crschnick at xpipe.io  Sun Aug 25 12:15:00 2024
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sun, 25 Aug 2024 14:15:00 +0200
Subject: Nodes are not rendered after window resize
In-Reply-To: <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>
References: <c9c884ad-b91d-4c01-b703-f334db616f24@xpipe.io>
 <4ef7622e-6264-4ae8-aafd-cf31d6e19547@web.de>
Message-ID: <bf6dfb21-17c7-40da-b6ca-cf2f18a7d887@xpipe.io>

Hello Eduard,

thanks I will try that parameter. But I can already rule out that this 
was fixed by the pull request as I used the latest JavaFX 24 ea build, 
which already includes this fix.

On 25/08/2024 14:06, Eduard Sedov wrote:
> Hello Christopher,
>
> You can try to pass the following parameter to jvm:
>
> -Dprism.dirtyregioncount=1
>
> If it helps, then it's probably the same bug that was fixed in this pull request:
>
> https://github.com/openjdk/jfx/pull/1451
>
> - eduard
>
>
> Am 25. Aug. 2024, 13:43, um 13:43, Christopher Schnick <crschnick at xpipe.io> schrieb:
>> Hello,
>>
>> so it seems like there is a rare bug in JavaFX (at least on Windows)
>> where after a resize operation, some controls are rendered as white
>> boxes. I had this issue on the latest JavaFX 24 ea build on Windows 10.
>>
>> There were no exceptions thrown or methods called from a non-platform
>> thread. I was not able to reproduce this consistently so far. I would
>> argue it happens around every 50 runs of an application for me.
>>
>> There were a couple of posts with videos of the problem:
>> -
>> https://www.reddit.com/r/JavaFX/comments/1bvdeny/random_portions_of_the_ui_flashing_white_no/
>> -
>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-November/043584.html
>>
>> (I wrongly reported it as a toolbar bug, it seems to be a more general
>> one)
>>
>> I can sometimes enter this state shown in the videos by resizing a
>> stage
> >from for example 1280x720, to fullscreen, back to 1280x720, and to
>> fullscreen again. It seems like the renderer dimensions become broken
>> in
>> some cases and are no longer updated on consecutive scene resize
>> operations, so they always stay on an old value. If in this case the
>> scene fits into a stage with size 1280x720 and is resized to
>> fullscreen,
>> any nodes outside the old scene bounds are rendered as these white
>> artifacts, presumably because the renderer thinks that they are not
>> visible. It seems like the renderer thinks they are outside the
>> scene/stage because it still has the old scene dimensions. I was not
>> able to get the application out of this invalid state without
>> restarting it.
>>
>> If anyone could advise me on what kind of properties I can pass to
>> JavaFX or what kind of actions I can do to narrow this down, that would
>>
>> be great.
>>
>> Best regards, Christopher

From tsayao at openjdk.org  Sun Aug 25 19:41:12 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 25 Aug 2024 19:41:12 GMT
Subject: RFR: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <lfqzT1fsuPA900ByMDgPTGe-TZc-CVfacaX8u4Gk_k8=.860dd562-a330-4ac1-9741-8fe6c2ee2216@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

This is probably a Mutter bug as it is reproducible on Mutter/Xorg with a Gtk C program and is not reproducible on i3.

Gtk is receiving a wrong configure event that causes this. It also causes the failing `SizeToSceneTest` and some other bugs such as fullscreen or maximized windows going back to floating.

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

PR Comment: https://git.openjdk.org/jfx/pull/1520#issuecomment-2308968387

From tsayao at openjdk.org  Sun Aug 25 19:41:12 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 25 Aug 2024 19:41:12 GMT
Subject: Withdrawn: 8337400: [Linux] Initial window position is not centered on
 Ubuntu 24.04 / Xorg
In-Reply-To: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
References: <atMJmeRpJqJp3qSslCtfuiNm6SStbtFklcvoiV7muhQ=.77ad421c-21ec-4b28-99c9-ba1cfc70e0ae@github.com>
Message-ID: <8pClL5fiQgTQbe5qqsnN1eOKKP5rKC_9-Bu_3Pd1I1Q=.04b19ae2-5a4a-49f7-8960-a2d84e43f118@github.com>

On Mon, 29 Jul 2024 17:46:52 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> On Ubuntu 24.04 with Xorg windows are not shown centered.
> 
> This is due a configure event being received with position 0,0 which is wrong.
> 
> The fix ignores the configure events until the window is mapped.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1520

From tsayao at openjdk.org  Sun Aug 25 20:00:44 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 25 Aug 2024 20:00:44 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v16]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <9ATEeLUc08iDKPHMPFLBECSK11en29AOF1pJTQVgL2o=.8030f175-be02-45dc-87e5-6334f95b1440@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

 - Merge branch 'master' into egl
 - Merge branch 'refs/heads/master' into egl
 - Merge branch 'refs/heads/master' into egl
 - Merge branch 'refs/heads/master' into egl
 - Merge branch 'refs/heads/master' into egl
 - Use prismES2EGLX11 as build name
 - Merge branch 'master' into egl
 - Prefer EGL over GLX
 - Merge branch 'master' into egl
 - Merge branch 'master' into egl
   
   # Conflicts:
   #	modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c
 - ... and 1 more: https://git.openjdk.org/jfx/compare/3261e940...3d30397c

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

Changes: https://git.openjdk.org/jfx/pull/1381/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=15
  Stats: 2438 lines in 36 files changed: 1857 ins; 489 del; 92 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

PR: https://git.openjdk.org/jfx/pull/1381

From tsayao at openjdk.org  Sun Aug 25 20:48:11 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 25 Aug 2024 20:48:11 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v16]
In-Reply-To: <9ATEeLUc08iDKPHMPFLBECSK11en29AOF1pJTQVgL2o=.8030f175-be02-45dc-87e5-6334f95b1440@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <9ATEeLUc08iDKPHMPFLBECSK11en29AOF1pJTQVgL2o=.8030f175-be02-45dc-87e5-6334f95b1440@github.com>
Message-ID: <uUgbxa1KNci_7E-rwlqs1cwkXX-kBiW8m0bC61fyhgg=.afaa7262-fa3a-46f2-af39-d0e86e3ac5e1@github.com>

On Sun, 25 Aug 2024 20:00:44 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into egl
>  - Merge branch 'refs/heads/master' into egl
>  - Merge branch 'refs/heads/master' into egl
>  - Merge branch 'refs/heads/master' into egl
>  - Merge branch 'refs/heads/master' into egl
>  - Use prismES2EGLX11 as build name
>  - Merge branch 'master' into egl
>  - Prefer EGL over GLX
>  - Merge branch 'master' into egl
>  - Merge branch 'master' into egl
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c
>  - ... and 1 more: https://git.openjdk.org/jfx/compare/3261e940...3d30397c

Found the problem:

`createDrawable` is being called twice on the same X Window.

>From the DOCS:

> EGL_BAD_ALLOC is generated if there is already an EGLSurface associated with native_window (as a result of a previous eglCreatePlatformWindowSurface call).

This also happens on the current GLX implementation and is probably a leak.

Place ` fprintf(stderr, "Window XID %ld\n", nativeWindow);` on ` X11GLDrawable.c` line 51 and run the `SetSceneScalingTest` - it gets printed twice.

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2308987931

From tsayao at openjdk.org  Sun Aug 25 20:59:43 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 25 Aug 2024 20:59:43 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v17]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <VaIEnkGM-czQswhNgh5V4d3lbpejFxwc77u6ciJ1T_4=.5ea5a583-c680-407a-8d78-3d0216f93a02@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Fix crash when running `SetSceneScalingTest`

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/3d30397c..a6332834

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=15-16

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

PR: https://git.openjdk.org/jfx/pull/1381

From kneester77 at gmail.com  Mon Aug 26 00:45:31 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Sun, 25 Aug 2024 17:45:31 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7+Nu0TTNpxuqHgqV4yUP3N3sYOXy=C0PyqCkzeSoXrpWA@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
 <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
 <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>
 <CAB9Lf7+Nu0TTNpxuqHgqV4yUP3N3sYOXy=C0PyqCkzeSoXrpWA@mail.gmail.com>
Message-ID: <CAB9Lf7K=F0__Tw7bFZfd8K9ziyoAby5iqgoHHSBnBDQY2BqEug@mail.gmail.com>

Hoping for further feedback from Michael and others on this feature
proposal, as I'm hoping to work on a draft PR soon.

Thanks!

On Fri, Aug 23, 2024 at 2:03?PM Knee Snap <kneester77 at gmail.com> wrote:

> Thanks for the clarification on how the design would work.
>
> However, this design is separate/unrelated to the goal of this feature
> proposal.
> Instead of extending TriangleMesh, you imagine a new separate mesh which
> can eventually be used to support user-supplied shaders.
> I do hope to propose such a feature at a future date (support user-defined
> shaders), but until such a proposal this system isn't super relevant /
> doesn't have much relation to the current proposal.
>
>
> *The future we both see for the future of working with meshes is a
> scenario with two (or potentially more) mesh classes:*
> *#1) *TriangleMesh (No dealing with shaders, buffers, and other advanced
> capabilities)
> *#2) *VertexMesh (or name it ShaderMesh, etc), which allows the user to
> do more advanced capabilities and lets the user define their own
> buffers, which could end up looking like the design you've shown.
>
> But critical to this design is understanding that only TriangleMesh needs
> explicit vertex color support.
> VertexMesh/ShaderMesh/etc would be able to support vertex colors
> implicitly due to its ability to have the user supply arbitrary buffers and
> shaders.
> So the whole purpose of my proposal is that this feature belongs in
> TriangleMesh (or an extension of TriangleMesh), but is currently missing.
> The example you've linked however does not extend TriangleMesh, instead
> it's starting work on the future proposal, ignoring the need for this
> feature in the existing TriangleMesh.
>
> I hope this helps clarify!
>
> On Fri, Aug 23, 2024 at 12:53?AM Michael Strau? <michaelstrau2 at gmail.com>
> wrote:
>
>> I've created a rough prototype to illustrate what I mean:
>> https://github.com/mstr2/jfx/tree/experiments/vertexmesh
>>
>> This is how you would use VertexMesh in an application:
>>
>>     var mesh = new VertexMesh<>(Vertex.PositionTexCoord.class);
>>
>>     mesh.getVertices().addAll(
>>         new Vertex.PositionTexCoord(
>>             new Point3D(0, 0, 0),
>>             new Point2D(0, 0)),
>>
>>         new Vertex.PositionTexCoord(
>>             new Point3D(100, 0, 0),
>>             new Point2D(1, 0)),
>>
>>         new Vertex.PositionTexCoord(
>>             new Point3D(0, 100, 0),
>>             new Point2D(0, 1))
>>     );
>>
>>     mesh.getIndices().addAll(0, 2, 1);
>>
>>     var meshView = new MeshView(mesh);
>>     meshView.setMaterial(new PhongMaterial(Color.RED));
>>     meshView.setCullFace(CullFace.NONE);
>>
>>     stage.setScene(new Scene(new Group(meshView)));
>>     stage.show();
>>
>>
>> In addition to PositionTexCoord, we could then also offer
>> PositionNormal, PositionNormalTexCoord, PositionColor,
>> PositionNormalColor, and PositionNormalColorTexCoord. These objects
>> are supposed to be data carriers for vertices, and could be
>> user-definable in the future.
>>
>> Note that this is by no means a well thought-out proposal, it's just a
>> rough sketch to get the basic idea across. Most likely, this API is
>> deficient in many ways, so take it as a discussion point rather than a
>> serious API proposal.
>>
>>
>>
>> On Fri, Aug 23, 2024 at 6:49?AM Knee Snap <kneester77 at gmail.com> wrote:
>> >
>> > Gottcha,
>> >
>> > That helps give the context I need to better elaborate. And to be clear
>> I'm not suggesting you've done anything wrong, I realized maybe I had
>> implied that I was upset, so I just wanted to say explicitly that is not
>> the case.
>> >
>> > Anywho, regarding CustomMesh<TVertex> it would be impossible to inherit
>> from TriangleMesh.java without breaking the existing API specification. At
>> least, when I assume TVertex is the representation of a single vertex. If
>> this assumption was wrong, and it intended to be the definition of the
>> vertex, that scenario will also be addressed.
>> >
>> > TriangleMesh.java does not currently use vertex objects, and making
>> such a TVertex to represent each individual vertex is incompatible without
>> changing the current public TriangleMesh API specification. If the idea of
>> a vertex object only exists within CustomMesh<TVertex> and not
>> TriangleMesh, then it's a second-class way of writing to mesh data since it
>> would only work on a subset of available mesh types, whereas writing
>> directly to the buffers (as it works now) would have worked in all cases.
>> If I (someone using JavaFX) want to make utilities for creating meshes, it
>> rules out using TVertex unless I commit to never using the base
>> TriangleMesh.
>> >
>> > Additionally, using individual vertex objects provides no utility, but
>> requires a  decent amount of added code complexity, as now there needs to
>> be a way to correlate vertex objects with buffer positions, and keep them
>> up to date as the buffer also changes. (What does it mean when a vertex is
>> moved in the buffer, but the ObservableFloatArray wasn't told that and it
>> was just given a new full array replacement? This is currently the only way
>> to update an ObservableFloatArray. Let's consider this vertex object for a
>> second. What is it? Is it a wrapper around the underlying buffer? If so,
>> every single time the array changes, all vertex objects would become
>> invalidated as there's no way to ensure the objects point to the correct
>> data in the array, or even to know if that data even exists anymore. If
>> it's not a wrapper around the array then we'd need to make changes to the
>> array backport to the object. Which has the same problem since the main way
>> to update the array is to provide a fully new array, meaning we would have
>> no way to associate the new array contents with the old objects. The only
>> solution would be to break the API spec and make these new vertex objects
>> the authoritative data source and not the arrays, which breaks existing
>> code.
>> >
>> > But I'd like to drive home the final nail. There's pretty much no
>> benefit to be had by having vertices as objects anyways. The 3D/GPU
>> paradigm is easiest to work with when treating vertex data as arrays and
>> not individual vertex objects. (Can refer to OpenInventor, Ogre, etc, to
>> confirm this design choice is standard across other object-oriented 3D
>> frameworks). This is because at the end of the day, this is what gets
>> passed directly to the GPU. Adding layers of abstraction is helpful for
>> creating/modifying the array, but not for representing it in memory.
>> >
>> > In other words, while TVertex might intuitively make sense from a
>> general object-oriented perspective, array buffers are almost always
>> preferable to vertex objects, even in object-oriented projects. And when
>> individual objects are desired, they can exist / act as wrappers in
>> user-code, which benefits of objects we cannot provide automatically, as it
>> requires information only the user knows about the organization of the
>> arrays.
>> >
>> > But what about if TVertex is not a vertex,  but instead a definition of
>> what buffers the mesh has? Well, we already have that, and it's called
>> VertexFormat. Making it a generic parameter also wouldn't really provide
>> any benefit anyways. Instead of making CustomMesh<TriangleMesh>, I propose
>> expanding VertexFormat to allow for additional arbitrarily defined buffers.
>> However, I do not think we need to expose this functionality publicly yet,
>> which is why I've not documented it after the suggestion. We can keep it as
>> internal implementation details until it's time to add user-supplied
>> shaders. Doing so will give us maximum flexibility when it is time to make
>> it public.
>> >
>> > This way also has the benefit of us being able to retroactively include
>> TriangleMesh's points/texCoords/normals arrays in the shader system with
>> very little complexity, as they are already part of VertexFormat.
>> >
>> > Also thanks for the suggestion about the JEPs, I'll keep this in mind
>> making future proposals, and it sounds like I should follow-up discussing
>> various different implementation options and why I've chosen the one I've
>> chosen instead. I suspect the reason this feels somewhat underdeveloped
>> from the API perspective is because it's the simplest option I came up with
>> that had the best API outcome and I didn't elaborate as much as I could
>> have on why others I thought about weren't satisfactory.
>> >
>> > Thanks again for the feedback, I look forward to hearing back again ?
>> >
>> > On Thu, Aug 22, 2024, 8:08?PM Michael Strau? <michaelstrau2 at gmail.com>
>> wrote:
>> >>
>> >> I understand that you propose to add a special-purpose mesh
>> >> (GouraudShadedTriangleMesh) instead of adding yet another buffer to
>> >> the existing TriangleMesh. That might be a valid idea if the goal is
>> >> to not overload the TriangleMesh class with special-purpose stuff.
>> >>
>> >> However, I still feel that the solution space in terms of API isn't
>> >> explored in enough detail here. It might be the case that
>> >> CustomMesh<TVertex> is not implementable (and it might also be the
>> >> case that CustomMesh<TVertex> isn't a good idea to begin with). But at
>> >> this point, none of this is obvious to me.
>> >>
>> >> Usually, when you propose a new feature, you should explain the
>> >> motivation, goals and non-goals, alternatives, and so on (you can use
>> >> a JEP template for that if you like). You adequately addressed the
>> >> motivation for your proposed enhancement, but I feel that the
>> >> discussion of different approaches should be expanded upon. I'm not
>> >> convinced that CustomMesh<TVertex> is impossible to implement: if
>> >> TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
>> >> PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
>> >> enforced, for example using sealed interfaces), then why wouldn't we
>> >> be able to connect this to our existing shaders?
>> >>
>> >> Again, I'm not saying that this is a good idea; it might not work for
>> >> any number of reasons. But I think these alternative approaches should
>> >> at least be explored a little bit before dismissing them. Maybe it
>> >> will be GouraudShadedTriangleMesh in the end.
>> >>
>> >>
>> >> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com>
>> wrote:
>> >> >
>> >> > Was hoping to get feedback on my suggestion instead, but another
>> suggestion doesn't work.
>> >> >
>> >> > The idea of a CustomMesh<TVertex> is impossible to implement until
>> after we have fully user-supplied shader support, which I've already
>> addressed as being not the scope of this change (but instead it is a
>> separate future change which is not impacted by this) it also feels like
>> this point may have been missed as well.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240825/09671910/attachment-0001.htm>

From michaelstrau2 at gmail.com  Mon Aug 26 03:44:41 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 26 Aug 2024 05:44:41 +0200
Subject: New CSS parser for JavaFX
Message-ID: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>

I've written up a proposal to implement a new CSS parser for JavaFX:
https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926

The goal is not add new features at this point, but to resolve some
long-standing issues with the existing CSS parsing (though if you read
carefully, you might spot a new feature).

I'm interested in your opinion whether this is a good idea to move forward.

From hmeda at openjdk.org  Mon Aug 26 07:16:43 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 26 Aug 2024 07:16:43 GMT
Subject: [jfx23u] RFR: 8338307: Additional WebKit 619.1 fixes from WebKitGTK
 2.44.3
Message-ID: <9ibSm6tRHEROiVbiX7-He_8YWYXM06qDSwcDF103SYo=.a5963354-ceef-48b8-8f91-213fd1299321@github.com>

Clean Backport

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

Commit messages:
 - Backport aa52f7efc370a4c55ff7a05a6903988871436d64

Changes: https://git.openjdk.org/jfx23u/pull/15/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=15&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338307
  Stats: 1276 lines in 181 files changed: 721 ins; 113 del; 442 mod
  Patch: https://git.openjdk.org/jfx23u/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/15/head:pull/15

PR: https://git.openjdk.org/jfx23u/pull/15

From hmeda at openjdk.org  Mon Aug 26 14:05:12 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 26 Aug 2024 14:05:12 GMT
Subject: [jfx23u] Integrated: 8338307: Additional WebKit 619.1 fixes from
 WebKitGTK 2.44.3
In-Reply-To: <9ibSm6tRHEROiVbiX7-He_8YWYXM06qDSwcDF103SYo=.a5963354-ceef-48b8-8f91-213fd1299321@github.com>
References: <9ibSm6tRHEROiVbiX7-He_8YWYXM06qDSwcDF103SYo=.a5963354-ceef-48b8-8f91-213fd1299321@github.com>
Message-ID: <SW8zV8qwPXG8cQHg66iHVgOAYyKkVsCXD_Fw5wPTdzM=.8ce8f6a8-8c59-48f3-a613-a43dd41e9f1b@github.com>

On Mon, 26 Aug 2024 07:11:30 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: 2e2af94a
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/2e2af94a19e771de13706ce7f458e355bc614545
Stats:     1276 lines in 181 files changed: 721 ins; 113 del; 442 mod

8338307: Additional WebKit 619.1 fixes from WebKitGTK 2.44.3

Backport-of: aa52f7efc370a4c55ff7a05a6903988871436d64

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

PR: https://git.openjdk.org/jfx23u/pull/15

From andy.goryachev at oracle.com  Mon Aug 26 17:24:26 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 26 Aug 2024 17:24:26 +0000
Subject: New CSS parser for JavaFX
In-Reply-To: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
Message-ID: <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>

Michael:

This might be a good idea.  A few questions:


  *   can we create stylesheets programmatically without parsing (i.e. construct the token tree directly)?
  *   would it be possible to add a diagnostic (at the moment of applyCSS()) to show the actual rule(s) being used?
  *   are we going to track the evolution of https://www.w3.org/TR/css-syntax-3/ "spec"?
  *   are we going to clarify the w3 "spec" (what is the value of "EOF code point"?)?
  *   are there incompatibilities between web-style CSS and FX-style CSS?
  *   what is the testing strategy?

Thank you

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Sunday, August 25, 2024 at 20:45
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: New CSS parser for JavaFX
I've written up a proposal to implement a new CSS parser for JavaFX:
https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926

The goal is not add new features at this point, but to resolve some
long-standing issues with the existing CSS parsing (though if you read
carefully, you might spot a new feature).

I'm interested in your opinion whether this is a good idea to move forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/f08ba67b/attachment-0001.htm>

From kevin.rushforth at oracle.com  Mon Aug 26 18:52:05 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 26 Aug 2024 11:52:05 -0700
Subject: New CSS parser for JavaFX
In-Reply-To: <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>

Lots of things might be good ideas. I'm rather skeptical of the cost / 
benefit of implementing a new CSS parser. This would be a large effort 
and run a significant risk of regression, especially since CSS is a 
fragile area (although parsing less so than the runtime CSS processing).

-- Kevin


On 8/26/2024 10:24 AM, Andy Goryachev wrote:
>
> Michael:
>
> This might be a good idea.? A few questions:
>
>   * can we create stylesheets programmatically without parsing (i.e.
>     construct the token tree directly)?
>   * would it be possible to add a diagnostic (at the moment of
>     applyCSS()) to show the actual rule(s) being used?
>   * are we going to track the evolution of
>     https://www.w3.org/TR/css-syntax-3/ "spec"?
>   * are we going to clarify the w3 "spec" (what is the value of "EOF
>     code point"?)?
>   * are there incompatibilities between web-style CSS and FX-style CSS?
>   * what is the testing strategy?
>
> Thank you
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Sunday, August 25, 2024 at 20:45
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *New CSS parser for JavaFX
>
> I've written up a proposal to implement a new CSS parser for JavaFX:
> https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926
>
> The goal is not add new features at this point, but to resolve some
> long-standing issues with the existing CSS parsing (though if you read
> carefully, you might spot a new feature).
>
> I'm interested in your opinion whether this is a good idea to move 
> forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/ccce7e54/attachment.htm>

From andy.goryachev at oracle.com  Mon Aug 26 19:05:46 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 26 Aug 2024 19:05:46 +0000
Subject: New CSS parser for JavaFX
In-Reply-To: <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>
Message-ID: <BL3PR10MB6185AC600881F8F8C4836608E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>

Well, I don't think we should dissuade anyone from discussing a possible improvement from the very beginning, especially if they are trying to address a pain point.

Though Kevin is right: CSS is a complicated subsystem, and attempting to change it, or worse, rewrite it, requires enormous effort - not only for development, but also for reviewing and most of all, testing.  I also have little confidence in the CSS "spec" - not only it's a moving target, but the github shows 3.3k issues https://github.com/w3c/csswg-drafts/issues .  Granted, not all of them might be applicable, but it certainly does not help.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Monday, August 26, 2024 at 11:52
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: New CSS parser for JavaFX
Lots of things might be good ideas. I'm rather skeptical of the cost / benefit of implementing a new CSS parser. This would be a large effort and run a significant risk of regression, especially since CSS is a fragile area (although parsing less so than the runtime CSS processing).

-- Kevin

On 8/26/2024 10:24 AM, Andy Goryachev wrote:
Michael:

This might be a good idea.  A few questions:


  *   can we create stylesheets programmatically without parsing (i.e. construct the token tree directly)?
  *   would it be possible to add a diagnostic (at the moment of applyCSS()) to show the actual rule(s) being used?
  *   are we going to track the evolution of https://www.w3.org/TR/css-syntax-3/ "spec"?
  *   are we going to clarify the w3 "spec" (what is the value of "EOF code point"?)?
  *   are there incompatibilities between web-style CSS and FX-style CSS?
  *   what is the testing strategy?

Thank you

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com><mailto:michaelstrau2 at gmail.com>
Date: Sunday, August 25, 2024 at 20:45
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: New CSS parser for JavaFX
I've written up a proposal to implement a new CSS parser for JavaFX:
https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926

The goal is not add new features at this point, but to resolve some
long-standing issues with the existing CSS parsing (though if you read
carefully, you might spot a new feature).

I'm interested in your opinion whether this is a good idea to move forward.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/c06e70a5/attachment-0001.htm>

From michaelstrau2 at gmail.com  Mon Aug 26 20:42:40 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 26 Aug 2024 22:42:40 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>

> can we create stylesheets programmatically without parsing (i.e. construct the token tree directly)?

Maybe, but `Stylesheet` and its constituent classes really seem like
exposed implementation details of JavaFX. I would rather deprecate
their use and remove them from the public API eventually.


> would it be possible to add a diagnostic (at the moment of applyCSS()) to show the actual rule(s) being used?

Sure, the grammar of a declaration is defined by its StyleConverter,
which can emit diagnostics if so required. This is not so different
from how it is done currently.


> are we going to track the evolution of https://www.w3.org/TR/css-syntax-3/ "spec"?

As far as it pertains to features implemented by JavaFX, yes.


> are we going to clarify the w3 "spec" (what is the value of "EOF code point"?)?

I'm not sure what you mean by that. The specification is quite clear
and unambiguous, so I don't know what we would need to clarify. If you
refer specifically to the EOF code point: there is no value of any
kind associated with that in the syntax API, as it is conceptual only
and not a preserved token.


> are there incompatibilities between web-style CSS and FX-style CSS?

Yes, the grammar and semantics of JavaFX CSS is defined by its
particular implementation, which is different from a HTML document
model. However, there are several things we can do to make them less
dissimilar, for example by supporting shorthand notations in the
future, or supporting notations that are defined in other W3C modules
(color functions come to mind).


> what is the testing strategy?

I don't have anything in mind that goes beyond the usual testing that
we do for all enhancements.

From john.hendrikx at gmail.com  Mon Aug 26 21:14:15 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 26 Aug 2024 23:14:15 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
Message-ID: <3cac584f-3df9-4317-8175-d4d31bccc539@gmail.com>

The CSS code, and its API, to put it diplomatically, is IMHO a bit under 
cooked.

I've had quite a few looks at it, and each time I've come to the 
conclusion that it is near impossible to do any worthwhile improvements 
to it without at a minimum getting rid of the ParsedValue abomination.? 
This class has generics that are used like 1% of the time, and in all 
other cases is either used raw or just instanceof'd and casted to 
whatever type the code knows will be in there.? It literally pollutes 
the code and makes it plain unreadable, not to mention giving you a 
completely false sense of security -- it's about as useful as just 
passing Objects around (which can be arrays, or even arrays of arrays...).

So I'm already 100% in favor as this proposal will be getting rid of 
ParsedValue.? The converter example looks like a breath of fresh air 
compared to the current code seen in most converters.

The convert method is, as I think was said earlier, more of an 
interpretation method, where raw CSS syntax is converted to objects used 
by the FX properties.? There is also a convert method that takes a Map 
which seems to serve a different purpose altogether (it deals with 
merging already interpreted values into a larger FX type which consists 
of those values).? For this last method, there was also talk to have a 
"convertBack" variant.

Introducing a new method here would have to opportunity to give this a 
less confusing name (so not all three of these variants are called 
"convert").? As far as I can see there are three main functions for a 
StyleConverter:

- Interpret "raw"?CSS values to FX types (like Border, Color, String, 
double)
- Take a map of FX types (already interpreted values) and consolidate 
these into an FX type, which I think is used or can be used for 
shorthand properties and is used to merge values into say a Border or 
Background
- The reverse of the above function (for CSS transitions that are 
applied to properties that consist of multiple distinct values).
- There is no reverse of the interpret function (there is no need to 
convert FX types back to CSS, the code that writes CSS files operates at 
a lower level).

Ideally something like:

-?interpret/parse/convertCSS for T convert(ComponentValue, Font)
- consolidate/merge for T convert(Map<CssMetadata,Object>)
- split for Map<CssMetadata, Object> split(T)

Did you any thoughts on this as well?

Anyway, I think it is a worthwhile undertaking.? I think the expected 
benefits will be to break out of the current stalemate where it is hard 
if not impossible to add features to the CSS parser, allowing easier 
future extensions (and immediately offers already one of the best 
features, `var()`).? Other benefits could include more shorthand 
property?support.? It would probably also allow opening up more of this 
as a programmatic API -- that all starts with a clean design.

--John

PS.

Under Solution 1, I think the data structure should read "<function>rgb 
(<percentage>100 <percentage>50 <percentage>0 )" (rgb instead of gray) ?



On 26/08/2024 05:44, Michael Strau? wrote:
> I've written up a proposal to implement a new CSS parser for JavaFX:
> https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926
>
> The goal is not add new features at this point, but to resolve some
> long-standing issues with the existing CSS parsing (though if you read
> carefully, you might spot a new feature).
>
> I'm interested in your opinion whether this is a good idea to move forward.

From kevin.rushforth at oracle.com  Mon Aug 26 21:31:50 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 26 Aug 2024 14:31:50 -0700
Subject: New CSS parser for JavaFX
In-Reply-To: <BL3PR10MB6185AC600881F8F8C4836608E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>
 <BL3PR10MB6185AC600881F8F8C4836608E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <2fe5410d-d739-4ae8-a848-0d9a4d049b92@oracle.com>

I agree that the discussion should continue. As noted by Michael, John, 
and Andy, there are many pain points in CSS. It is a very tall order, 
though. One of the main points to discuss will be how to ensure 
compatibility, both API (a must with the possible exception of API that 
can't be usefully used today by an application) and functional 
compatibility.

-- Kevin


On 8/26/2024 12:05 PM, Andy Goryachev wrote:
>
> Well, I don't think we should dissuade anyone from discussing a 
> possible improvement from the very beginning, especially if they are 
> trying to address a pain point.
>
> Though Kevin is right: CSS is a complicated subsystem, and attempting 
> to change it, or worse, rewrite it, requires enormous effort - not 
> only for development, but also for reviewing and most of all, 
> testing.? I also have little confidence in the CSS "spec" - not only 
> it's a moving target, but the github shows 3.3k issues 
> https://github.com/w3c/csswg-drafts/issues .? Granted, not all of them 
> might be applicable, but it certainly does not help.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Monday, August 26, 2024 at 11:52
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: New CSS parser for JavaFX
>
> Lots of things might be good ideas. I'm rather skeptical of the cost / 
> benefit of implementing a new CSS parser. This would be a large effort 
> and run a significant risk of regression, especially since CSS is a 
> fragile area (although parsing less so than the runtime CSS processing).
>
> -- Kevin
>
> On 8/26/2024 10:24 AM, Andy Goryachev wrote:
>
>     Michael:
>
>     This might be a good idea.? A few questions:
>
>       * can we create stylesheets programmatically without parsing
>         (i.e. construct the token tree directly)?
>       * would it be possible to add a diagnostic (at the moment of
>         applyCSS()) to show the actual rule(s) being used?
>       * are we going to track the evolution of
>         https://www.w3.org/TR/css-syntax-3/ "spec"?
>       * are we going to clarify the w3 "spec" (what is the value of
>         "EOF code point"?)?
>       * are there incompatibilities between web-style CSS and FX-style
>         CSS?
>       * what is the testing strategy?
>
>     Thank you
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Michael Strau?
>     <michaelstrau2 at gmail.com> <mailto:michaelstrau2 at gmail.com>
>     *Date: *Sunday, August 25, 2024 at 20:45
>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *New CSS parser for JavaFX
>
>     I've written up a proposal to implement a new CSS parser for JavaFX:
>     https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926
>
>     The goal is not add new features at this point, but to resolve some
>     long-standing issues with the existing CSS parsing (though if you read
>     carefully, you might spot a new feature).
>
>     I'm interested in your opinion whether this is a good idea to move
>     forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/f0d59324/attachment-0001.htm>

From john.hendrikx at gmail.com  Mon Aug 26 21:35:22 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 26 Aug 2024 23:35:22 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
Message-ID: <288c012e-fce7-4075-816c-486e8eddb45a@gmail.com>


On 26/08/2024 22:42, Michael Strau? wrote:
>> can we create stylesheets programmatically without parsing (i.e. construct the token tree directly)?
> Maybe, but `Stylesheet` and its constituent classes really seem like
> exposed implementation details of JavaFX. I would rather deprecate
> their use and remove them from the public API eventually.

I'm pretty convinced of that as well.? The whole CSS API seems to have 
been put in place to allow use of binary stylesheets (to perhaps 
load?Modena .5 seconds faster?), it doesn't seem to serve much of a 
function beyond that.? I haven't found a use for any of these classes 
and the API surface they expose.

For example, I implemented a LESS parser that I can use with JavaFX, and 
the CSS API was absolutely no help there (what is the point of being 
able to create a StyleSheet when I can't "set" it on a Scene?) -- 
instead I've just resorted to writing the LESS output to memory buffers, 
and pointing my stylesheet properties directly to these (using 
"data:text/css;charset=UTF-8;base64," URL's -- thanks for whoever 
mentioned "data" URL's, I was writing these to temporary files before 
that...).

The CSS API classes are also full of observable properties, which seems 
a rather odd decision given that a Stylesheet is probably far better 
represented as something immutable.? Imagine assigning a Stylesheet type 
to Scene (something that isn't possible, so it is unclear what the 
purpose of this class is), then having the CSS engine observe almost 
every aspect of this Stylesheet, just in case someone decides to add a 
new Selector somewhere programmatically... it would be incredibly 
complicated to "act" on such a change correctly, requiring no doubt 
thousands of lines of code, that will likely?never ever be used in any 
FX application (well perhaps if you are writing a Stylesheet editor, but 
that's hardly a use-case worth supporting just in case...)

--John

From kevin.rushforth at oracle.com  Mon Aug 26 21:40:06 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 26 Aug 2024 14:40:06 -0700
Subject: New CSS parser for JavaFX
In-Reply-To: <288c012e-fce7-4075-816c-486e8eddb45a@gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
 <288c012e-fce7-4075-816c-486e8eddb45a@gmail.com>
Message-ID: <3575a12f-bda7-4df3-9256-b58e5c6fafc0@oracle.com>

Deprecating the existing API is an interesting idea, but with such a 
large API surface it will be difficult to show that no application is 
using it.

-- Kevin


On 8/26/2024 2:35 PM, John Hendrikx wrote:
>
> On 26/08/2024 22:42, Michael Strau? wrote:
>>> can we create stylesheets programmatically without parsing (i.e. 
>>> construct the token tree directly)?
>> Maybe, but `Stylesheet` and its constituent classes really seem like
>> exposed implementation details of JavaFX. I would rather deprecate
>> their use and remove them from the public API eventually.
>
> I'm pretty convinced of that as well.? The whole CSS API seems to have 
> been put in place to allow use of binary stylesheets (to perhaps 
> load?Modena .5 seconds faster?), it doesn't seem to serve much of a 
> function beyond that.? I haven't found a use for any of these classes 
> and the API surface they expose.
>
> For example, I implemented a LESS parser that I can use with JavaFX, 
> and the CSS API was absolutely no help there (what is the point of 
> being able to create a StyleSheet when I can't "set" it on a Scene?) 
> -- instead I've just resorted to writing the LESS output to memory 
> buffers, and pointing my stylesheet properties directly to these 
> (using "data:text/css;charset=UTF-8;base64," URL's -- thanks for 
> whoever mentioned "data" URL's, I was writing these to temporary files 
> before that...).
>
> The CSS API classes are also full of observable properties, which 
> seems a rather odd decision given that a Stylesheet is probably far 
> better represented as something immutable.? Imagine assigning a 
> Stylesheet type to Scene (something that isn't possible, so it is 
> unclear what the purpose of this class is), then having the CSS engine 
> observe almost every aspect of this Stylesheet, just in case someone 
> decides to add a new Selector somewhere programmatically... it would 
> be incredibly complicated to "act" on such a change correctly, 
> requiring no doubt thousands of lines of code, that will likely?never 
> ever be used in any FX application (well perhaps if you are writing a 
> Stylesheet editor, but that's hardly a use-case worth supporting just 
> in case...)
>
> --John


From andy.goryachev at oracle.com  Mon Aug 26 22:01:14 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 26 Aug 2024 22:01:14 +0000
Subject: New CSS parser for JavaFX
In-Reply-To: <3575a12f-bda7-4df3-9256-b58e5c6fafc0@oracle.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
 <288c012e-fce7-4075-816c-486e8eddb45a@gmail.com>
 <3575a12f-bda7-4df3-9256-b58e5c6fafc0@oracle.com>
Message-ID: <BL3PR10MB618562949426ADCF1D049D68E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>

I wonder if this could be done as an incubator module, or hidden behind an experimental system property.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Monday, August 26, 2024 at 14:40
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: New CSS parser for JavaFX
Deprecating the existing API is an interesting idea, but with such a
large API surface it will be difficult to show that no application is
using it.

-- Kevin


On 8/26/2024 2:35 PM, John Hendrikx wrote:
>
> On 26/08/2024 22:42, Michael Strau? wrote:
>>> can we create stylesheets programmatically without parsing (i.e.
>>> construct the token tree directly)?
>> Maybe, but `Stylesheet` and its constituent classes really seem like
>> exposed implementation details of JavaFX. I would rather deprecate
>> their use and remove them from the public API eventually.
>
> I'm pretty convinced of that as well.  The whole CSS API seems to have
> been put in place to allow use of binary stylesheets (to perhaps
> load Modena .5 seconds faster?), it doesn't seem to serve much of a
> function beyond that.  I haven't found a use for any of these classes
> and the API surface they expose.
>
> For example, I implemented a LESS parser that I can use with JavaFX,
> and the CSS API was absolutely no help there (what is the point of
> being able to create a StyleSheet when I can't "set" it on a Scene?)
> -- instead I've just resorted to writing the LESS output to memory
> buffers, and pointing my stylesheet properties directly to these
> (using "data:text/css;charset=UTF-8;base64," URL's -- thanks for
> whoever mentioned "data" URL's, I was writing these to temporary files
> before that...).
>
> The CSS API classes are also full of observable properties, which
> seems a rather odd decision given that a Stylesheet is probably far
> better represented as something immutable.  Imagine assigning a
> Stylesheet type to Scene (something that isn't possible, so it is
> unclear what the purpose of this class is), then having the CSS engine
> observe almost every aspect of this Stylesheet, just in case someone
> decides to add a new Selector somewhere programmatically... it would
> be incredibly complicated to "act" on such a change correctly,
> requiring no doubt thousands of lines of code, that will likely never
> ever be used in any FX application (well perhaps if you are writing a
> Stylesheet editor, but that's hardly a use-case worth supporting just
> in case...)
>
> --John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/35bbc3e6/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Aug 26 22:11:42 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 26 Aug 2024 22:11:42 +0000
Subject: New CSS parser for JavaFX
In-Reply-To: <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
Message-ID: <BL3PR10MB6185CD9497AF932C6D4A653FE58B2@BL3PR10MB6185.namprd10.prod.outlook.com>

see inline

> can we create stylesheets programmatically without parsing (i.e. construct the token tree directly)?

Maybe, but `Stylesheet` and its constituent classes really seem like
exposed implementation details of JavaFX. I would rather deprecate
their use and remove them from the public API eventually.

I did not mean a specific class, but a stylesheet in general.  I just think that there should be a way to construct a stylesheet in memory that does not require parsing, and ideally with an option to do a limited type check.  Unless it significantly increases the overall effort, in which case the app can go the usual route of generating a data url.



> what is the testing strategy?

I don't have anything in mind that goes beyond the usual testing that
we do for all enhancements.

Sorry for pointing out the obvious, the testing might represent overwhelming portion of the overall effort.  Not only we must ensure that any the legacy CSS continues to produce the same results, the new features work as expected, and all multiplied at least by 3 supported desktop platforms (or 5, if we count ios and android for mobile).

-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/e81927eb/attachment.htm>

From michaelstrau2 at gmail.com  Mon Aug 26 22:27:35 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 27 Aug 2024 00:27:35 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <e5e6c960-f379-4028-b98d-b6ce8d7d3ae5@oracle.com>
Message-ID: <CAJEpuXTv9_9tAPtsqVRGhmUe3YHuu=CPbAiO2qpH5xnFMTVJ8Q@mail.gmail.com>

It's certainly true that CSS is a fragile area, but I would argue that
one of the reasons it's fragile is because the implementation is a bit
unsound in many places. Cleaning up tech debt could make this
progressively more robust in the long run. Note that I'm also not
proposing a refactor to make the code more elegant or modern, but to
solve a systematic issue.


On Mon, Aug 26, 2024 at 8:52?PM Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> Lots of things might be good ideas. I'm rather skeptical of the cost / benefit of implementing a new CSS parser. This would be a large effort and run a significant risk of regression, especially since CSS is a fragile area (although parsing less so than the runtime CSS processing).
>
> -- Kevin

From michaelstrau2 at gmail.com  Mon Aug 26 22:35:32 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 27 Aug 2024 00:35:32 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <3cac584f-3df9-4317-8175-d4d31bccc539@gmail.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <3cac584f-3df9-4317-8175-d4d31bccc539@gmail.com>
Message-ID: <CAJEpuXQeiTmVp=LwP_bW71CdfY2hwcxpTP2QzC6mZB75KCGmSQ@mail.gmail.com>

On Mon, Aug 26, 2024 at 11:14?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> The CSS code, and its API, to put it diplomatically, is IMHO a bit under
> cooked.
>
> I've had quite a few looks at it, and each time I've come to the
> conclusion that it is near impossible to do any worthwhile improvements
> to it without at a minimum getting rid of the ParsedValue abomination.
> This class has generics that are used like 1% of the time, and in all
> other cases is either used raw or just instanceof'd and casted to
> whatever type the code knows will be in there.  It literally pollutes
> the code and makes it plain unreadable, not to mention giving you a
> completely false sense of security -- it's about as useful as just
> passing Objects around (which can be arrays, or even arrays of arrays...).
>
> So I'm already 100% in favor as this proposal will be getting rid of
> ParsedValue.  The converter example looks like a breath of fresh air
> compared to the current code seen in most converters.

The fact that ParsedValue is almost unusable by third-party
applications works to our advantage here, as this is the reason why we
can remove it in the first place.



>
> Introducing a new method here would have to opportunity to give this a
> less confusing name (so not all three of these variants are called
> "convert").  As far as I can see there are three main functions for a
> StyleConverter:
>
> - Interpret "raw" CSS values to FX types (like Border, Color, String,
> double)
> - Take a map of FX types (already interpreted values) and consolidate
> these into an FX type, which I think is used or can be used for
> shorthand properties and is used to merge values into say a Border or
> Background
> - The reverse of the above function (for CSS transitions that are
> applied to properties that consist of multiple distinct values).
> - There is no reverse of the interpret function (there is no need to
> convert FX types back to CSS, the code that writes CSS files operates at
> a lower level).
>
> Ideally something like:
>
> - interpret/parse/convertCSS for T convert(ComponentValue, Font)
> - consolidate/merge for T convert(Map<CssMetadata,Object>)
> - split for Map<CssMetadata, Object> split(T)
>
> Did you any thoughts on this as well?

Not beyond what you wrote down here. I think these are quite different
concerns, and don't need to be solved together.



> PS.
>
> Under Solution 1, I think the data structure should read "<function>rgb
> (<percentage>100 <percentage>50 <percentage>0 )" (rgb instead of gray) ?

Yes, thanks for pointing that out!

From michaelstrau2 at gmail.com  Mon Aug 26 22:41:23 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 27 Aug 2024 00:41:23 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <BL3PR10MB618562949426ADCF1D049D68E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
 <288c012e-fce7-4075-816c-486e8eddb45a@gmail.com>
 <3575a12f-bda7-4df3-9256-b58e5c6fafc0@oracle.com>
 <BL3PR10MB618562949426ADCF1D049D68E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXQVsrdOzmTa3MonfKgXQZUYdDDn9ketneTybpe1dWRpsg@mail.gmail.com>

I don't think that's practical, as the proposed enhancement will
change parsing, representation (Declaration, ParsedValue) and runtime
processing (CssStyleHelper). I don't know how we would keep the old
implementations around.


On Tue, Aug 27, 2024 at 12:01?AM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> I wonder if this could be done as an incubator module, or hidden behind an experimental system property.
>
>
>
> -andy

From michaelstrau2 at gmail.com  Mon Aug 26 22:52:42 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 27 Aug 2024 00:52:42 +0200
Subject: New CSS parser for JavaFX
In-Reply-To: <BL3PR10MB6185CD9497AF932C6D4A653FE58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAJEpuXQ4uMtVxX_AqgM9=SAwSrZRnXhnhLy09BH3NYY5bsx=ug@mail.gmail.com>
 <BL3PR10MB61851F4BB322800C2856BFB4E58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAJEpuXQzjq-HGnO4KAPXrc3+MSnXPzSkqmRRXKEq8PN8OCHWtw@mail.gmail.com>
 <BL3PR10MB6185CD9497AF932C6D4A653FE58B2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXTuAK_R==hhc_j2MVHuDE_NP3BzNhpGG41ihX2j1-DkGw@mail.gmail.com>

>
> I did not mean a specific class, but a stylesheet in general.  I just think that there should be a way to construct a stylesheet in memory that does not require parsing, and ideally with an option to do a limited type check.  Unless it significantly increases the overall effort, in which case the app can go the usual route of generating a data url.

In theory, this can work (just add a bunch of CSS tokens to a
javafx.css.Declaration). The problem is that you can't do anything
with a Stylesheet, there's no API for you to set it on a Scene or a
Parent. This would most likely be a separate enhancement and not part
of the CSS parser rework.

>
> Sorry for pointing out the obvious, the testing might represent overwhelming portion of the overall effort.  Not only we must ensure that any the legacy CSS continues to produce the same results, the new features work as expected, and all multiplied at least by 3 supported desktop platforms (or 5, if we count ios and android for mobile).

I agree, it will need to be well-tested.

From almatvee at openjdk.org  Mon Aug 26 23:32:14 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 26 Aug 2024 23:32:14 GMT
Subject: [jfx23u] Integrated: 8336940: Update GStreamer to 1.24.6
In-Reply-To: <PSK9TRaawEaJBE3NE91wdz0r-Pu-t32HGH_pT1IER7Q=.a77726ff-3068-421f-9c17-350fe0c28ba3@github.com>
References: <PSK9TRaawEaJBE3NE91wdz0r-Pu-t32HGH_pT1IER7Q=.a77726ff-3068-421f-9c17-350fe0c28ba3@github.com>
Message-ID: <7EW0VJSOHD1Utab_z5fesNxnAm4iB9Tc6Cj3WFuQLFg=.eb2a5e18-30c6-4a2c-adf9-dff75bdeb622@github.com>

On Fri, 23 Aug 2024 22:26:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Clean backport of JDK-8336940 and JDK-8336939.

This pull request has now been integrated.

Changeset: 4030ad96
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/4030ad96ba6717e4a3a8f0591aef27659f3ec080
Stats:     24630 lines in 329 files changed: 13062 ins; 6878 del; 4690 mod

8336940: Update GStreamer to 1.24.6
8336939: Update Glib to 2.80.4

Backport-of: b88ac0495650bd033ba11e3131e9bffc517872eb

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

PR: https://git.openjdk.org/jfx23u/pull/14

From kevin.rushforth at oracle.com  Tue Aug 27 01:25:38 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 26 Aug 2024 18:25:38 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <CAB9Lf7K=F0__Tw7bFZfd8K9ziyoAby5iqgoHHSBnBDQY2BqEug@mail.gmail.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
 <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
 <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>
 <CAB9Lf7+Nu0TTNpxuqHgqV4yUP3N3sYOXy=C0PyqCkzeSoXrpWA@mail.gmail.com>
 <CAB9Lf7K=F0__Tw7bFZfd8K9ziyoAby5iqgoHHSBnBDQY2BqEug@mail.gmail.com>
Message-ID: <04887dcb-9d63-4ee2-9b54-a68dab18ce92@oracle.com>

As Michael mentioned, it is helpful to discus how this might fit in with 
other possible future improvements. Given the points you raised, I think 
we can now decouple the discussion of whether and how to add vertex 
colors to 3D TriangleMesh from the more general discussion of 
user-defined geometry. Especially since adding support for user-defined 
shaders is not going to happen any time soon (if ever). This has been 
looked at in the past, but always runs into a couple fundamental 
problems -- for one, we do not want to expose the low-level rendering 
library that Prism happens to be using on a particular platform (which 
could change over time: OpenGL --> Metal on macOS, etc), so we would 
need a graphics-language-neutral shading language and figure out how to 
wire that up to the renderer without exposing Prism internals.

So back to your proposal to add vertex colors to 3D TriangleMesh, it 
seems like a somewhat interesting feature, but not a high priority for 
us. I would need to be convinced that multiple applications would 
benefit from such a feature, and that your proposed solution -- as 
documented and exposed by the public API -- is the best way to go.

The next step, then, is to get feedback from other application 
developers as to whether and how they would use this. A Draft PR might 
be OK as long as the focus is on the API and the use cases. I presume 
you have read the CONTRIBUTING guidelines [0], especially the part about 
adding new features? [1]

If it proceeds further, be prepared to come up with a plan to document, 
test, implement the new API on all platforms. You will need to modify 
the shaders for each of the graphics APIs. We might ask you to provide 
at least an initial implementation for the in-progress metal pipeline [2].

All of this is by way of saying that even if this feature proceeds, it 
won't happen quickly.

-- Kevin

[0] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
[1] 
https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions
[2] https://github.com/openjdk/jfx-sandbox/tree/metal


On 8/25/2024 5:45 PM, Knee Snap wrote:
> Hoping for further feedback from Michael and others on this feature 
> proposal, as I'm hoping to work on a draft PR soon.
>
> Thanks!
>
> On Fri, Aug 23, 2024 at 2:03?PM Knee Snap <kneester77 at gmail.com> wrote:
>
>     Thanks for the clarification on how the design would work.
>
>     However, this design is separate/unrelated to the goal of this
>     feature proposal.
>     Instead of extending TriangleMesh, you imagine a new separate mesh
>     which can eventually be used to support user-supplied shaders.
>     I do hope to propose such a feature at a future date (support
>     user-defined shaders), but until such a proposal this system isn't
>     super relevant / doesn't have much relation to the current proposal.
>
>     _The future we both see for the future of working with meshes is a
>     scenario with two (or potentially more) mesh classes:
>     _
>     *#1) *TriangleMesh (No dealing with shaders, buffers, and other
>     advanced capabilities)
>     *#2) *VertexMesh (or name it ShaderMesh, etc), which allows the
>     user to do more advanced capabilities and lets the user define
>     their own buffers,?which could end up looking like the design
>     you've shown.
>
>     But critical to this design is understanding that only
>     TriangleMesh needs explicit vertex color support.
>     VertexMesh/ShaderMesh/etc would be able to support vertex colors
>     implicitly due to its ability to have the user supply arbitrary
>     buffers and shaders.
>     So the whole purpose of my proposal is that this?feature belongs
>     in TriangleMesh (or an extension of TriangleMesh), but is
>     currently missing.
>     The example you've linked however does not extend TriangleMesh,
>     instead it's starting work on the future proposal, ignoring the
>     need for this feature in the existing TriangleMesh.
>
>     I hope this helps clarify!
>
>     On Fri, Aug 23, 2024 at 12:53?AM Michael Strau?
>     <michaelstrau2 at gmail.com> wrote:
>
>         I've created a rough prototype to illustrate what I mean:
>         https://github.com/mstr2/jfx/tree/experiments/vertexmesh
>
>         This is how you would use VertexMesh in an application:
>
>         ? ? var mesh = new VertexMesh<>(Vertex.PositionTexCoord.class);
>
>         ? ? mesh.getVertices().addAll(
>         ? ? ? ? new Vertex.PositionTexCoord(
>         ? ? ? ? ? ? new Point3D(0, 0, 0),
>         ? ? ? ? ? ? new Point2D(0, 0)),
>
>         ? ? ? ? new Vertex.PositionTexCoord(
>         ? ? ? ? ? ? new Point3D(100, 0, 0),
>         ? ? ? ? ? ? new Point2D(1, 0)),
>
>         ? ? ? ? new Vertex.PositionTexCoord(
>         ? ? ? ? ? ? new Point3D(0, 100, 0),
>         ? ? ? ? ? ? new Point2D(0, 1))
>         ? ? );
>
>         ? ? mesh.getIndices().addAll(0, 2, 1);
>
>         ? ? var meshView = new MeshView(mesh);
>         ? ? meshView.setMaterial(new PhongMaterial(Color.RED));
>         ? ? meshView.setCullFace(CullFace.NONE);
>
>         ? ? stage.setScene(new Scene(new Group(meshView)));
>         ? ? stage.show();
>
>
>         In addition to PositionTexCoord, we could then also offer
>         PositionNormal, PositionNormalTexCoord, PositionColor,
>         PositionNormalColor, and PositionNormalColorTexCoord. These
>         objects
>         are supposed to be data carriers for vertices, and could be
>         user-definable in the future.
>
>         Note that this is by no means a well thought-out proposal,
>         it's just a
>         rough sketch to get the basic idea across. Most likely, this
>         API is
>         deficient in many ways, so take it as a discussion point
>         rather than a
>         serious API proposal.
>
>
>
>         On Fri, Aug 23, 2024 at 6:49?AM Knee Snap
>         <kneester77 at gmail.com> wrote:
>         >
>         > Gottcha,
>         >
>         > That helps give the context I need to better elaborate. And
>         to be clear I'm not suggesting you've done anything wrong, I
>         realized maybe I had implied that I was upset, so I just
>         wanted to say explicitly that is not the case.
>         >
>         > Anywho, regarding CustomMesh<TVertex> it would be impossible
>         to inherit from TriangleMesh.java without breaking the
>         existing API specification. At least, when I assume TVertex is
>         the representation of a single vertex. If this assumption was
>         wrong, and it intended to be the definition of the vertex,
>         that scenario will also be addressed.
>         >
>         > TriangleMesh.java does not currently use vertex objects, and
>         making such a TVertex to represent each individual vertex is
>         incompatible without changing the current public TriangleMesh
>         API specification. If the idea of a vertex object only exists
>         within CustomMesh<TVertex> and not TriangleMesh, then it's a
>         second-class way of writing to mesh data since it would only
>         work on a subset of available mesh types, whereas writing
>         directly to the buffers (as it works now) would have worked in
>         all cases. If I (someone using JavaFX) want to make utilities
>         for creating meshes, it rules out using TVertex unless I
>         commit to never using the base TriangleMesh.
>         >
>         > Additionally, using individual vertex objects provides no
>         utility, but requires a? decent amount of added code
>         complexity, as now there needs to be a way to correlate vertex
>         objects with buffer positions, and keep them up to date as the
>         buffer also changes. (What does it mean when a vertex is moved
>         in the buffer, but the ObservableFloatArray wasn't told that
>         and it was just given a new full array replacement? This is
>         currently the only way to update an ObservableFloatArray.
>         Let's consider this vertex object for a second. What is it? Is
>         it a wrapper around the underlying buffer? If so, every single
>         time the array changes, all vertex objects would become
>         invalidated as there's no way to ensure the objects point to
>         the correct data in the array, or even to know if that data
>         even exists anymore. If it's not a wrapper around the array
>         then we'd need to make changes to the array backport to the
>         object. Which has the same problem since the main way to
>         update the array is to provide a fully new array, meaning we
>         would have no way to associate the new array contents with the
>         old objects. The only solution would be to break the API spec
>         and make these new vertex objects the authoritative data
>         source and not the arrays, which breaks existing code.
>         >
>         > But I'd like to drive home the final nail. There's pretty
>         much no benefit to be had by having vertices as objects
>         anyways. The 3D/GPU paradigm is easiest to work with when
>         treating vertex data as arrays and not individual vertex
>         objects. (Can refer to OpenInventor, Ogre, etc, to confirm
>         this design choice is standard across other object-oriented 3D
>         frameworks). This is because at the end of the day, this is
>         what gets passed directly to the GPU. Adding layers of
>         abstraction is helpful for creating/modifying the array, but
>         not for representing it in memory.
>         >
>         > In other words, while TVertex might intuitively make sense
>         from a general object-oriented perspective, array buffers are
>         almost always preferable to vertex objects, even in
>         object-oriented projects. And when individual objects are
>         desired, they can exist / act as wrappers in user-code, which
>         benefits of objects we cannot provide automatically, as it
>         requires information only the user knows about the
>         organization of the arrays.
>         >
>         > But what about if TVertex is not a vertex,? but instead a
>         definition of what buffers the mesh has? Well, we already have
>         that, and it's called VertexFormat. Making it a generic
>         parameter also wouldn't really provide any benefit anyways.
>         Instead of making CustomMesh<TriangleMesh>, I propose
>         expanding VertexFormat to allow for additional arbitrarily
>         defined buffers. However, I do not think we need to expose
>         this functionality publicly yet, which is why I've not
>         documented it after the suggestion. We can keep it as internal
>         implementation details until it's time to add user-supplied
>         shaders. Doing so will give us maximum flexibility when it is
>         time to make it public.
>         >
>         > This way also has the benefit of us being able to
>         retroactively include TriangleMesh's points/texCoords/normals
>         arrays in the shader system with very little complexity, as
>         they are already part of VertexFormat.
>         >
>         > Also thanks for the suggestion about the JEPs, I'll keep
>         this in mind making future proposals, and it sounds like I
>         should follow-up discussing various different implementation
>         options and why I've chosen the one I've chosen instead. I
>         suspect the reason this feels somewhat underdeveloped from the
>         API perspective is because it's the simplest option I came up
>         with that had the best API outcome and I didn't elaborate as
>         much as I could have on why others I thought about weren't
>         satisfactory.
>         >
>         > Thanks again for the feedback, I look forward to hearing
>         back again ?
>         >
>         > On Thu, Aug 22, 2024, 8:08?PM Michael Strau?
>         <michaelstrau2 at gmail.com> wrote:
>         >>
>         >> I understand that you propose to add a special-purpose mesh
>         >> (GouraudShadedTriangleMesh) instead of adding yet another
>         buffer to
>         >> the existing TriangleMesh. That might be a valid idea if
>         the goal is
>         >> to not overload the TriangleMesh class with special-purpose
>         stuff.
>         >>
>         >> However, I still feel that the solution space in terms of
>         API isn't
>         >> explored in enough detail here. It might be the case that
>         >> CustomMesh<TVertex> is not implementable (and it might also
>         be the
>         >> case that CustomMesh<TVertex> isn't a good idea to begin
>         with). But at
>         >> this point, none of this is obvious to me.
>         >>
>         >> Usually, when you propose a new feature, you should explain the
>         >> motivation, goals and non-goals, alternatives, and so on
>         (you can use
>         >> a JEP template for that if you like). You adequately
>         addressed the
>         >> motivation for your proposed enhancement, but I feel that the
>         >> discussion of different approaches should be expanded upon.
>         I'm not
>         >> convinced that CustomMesh<TVertex> is impossible to
>         implement: if
>         >> TVertex can only ever be PositionTexCoord,
>         PositionNormalTexCoord,
>         >> PositionColorTexCoord, and PositionNormalColorTexCoord (and
>         this is
>         >> enforced, for example using sealed interfaces), then why
>         wouldn't we
>         >> be able to connect this to our existing shaders?
>         >>
>         >> Again, I'm not saying that this is a good idea; it might
>         not work for
>         >> any number of reasons. But I think these alternative
>         approaches should
>         >> at least be explored a little bit before dismissing them.
>         Maybe it
>         >> will be GouraudShadedTriangleMesh in the end.
>         >>
>         >>
>         >> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap
>         <kneester77 at gmail.com> wrote:
>         >> >
>         >> > Was hoping to get feedback on my suggestion instead, but
>         another suggestion doesn't work.
>         >> >
>         >> > The idea of a CustomMesh<TVertex> is impossible to
>         implement until after we have fully user-supplied shader
>         support, which I've already addressed as being not the scope
>         of this change (but instead it is a separate future change
>         which is not impacted by this) it also feels like this point
>         may have been missed as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/f486f1e4/attachment-0001.htm>

From kneester77 at gmail.com  Tue Aug 27 03:28:34 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Mon, 26 Aug 2024 20:28:34 -0700
Subject: [Feature Proposal] Vertex Colors on TriangleMesh
In-Reply-To: <04887dcb-9d63-4ee2-9b54-a68dab18ce92@oracle.com>
References: <CAB9Lf7KJRoD5gbUq1UoXHyjgmT7d-AEDZO6-o+6jEYqE5GwQkA@mail.gmail.com>
 <CAJEpuXSeeteqA6jAW36DaU-mo4TjKAbQpjWyiLnfSmF8KYo_nQ@mail.gmail.com>
 <CAB9Lf7+fSzLy2WF6sMXttQ1zvKbWqdXHMMCkKuhps8D=vwc-BQ@mail.gmail.com>
 <CAJEpuXQ7vVP0pwenxhf0d+t+gukTeyz6ML6EaHHJ9d7kvB7v0w@mail.gmail.com>
 <CAB9Lf7KLRwGENNVmCBwhAesmj5Ruq+eM7+U1fPMbYLVgKOg1zg@mail.gmail.com>
 <CAJEpuXSGodMqQm-Vrsjcu6rjD5D6-wYhD3GhAjYXwWn==17pOQ@mail.gmail.com>
 <CAB9Lf7JJCqYkagf1Ou+mAjKAWTRkb10Vgj202U1zn6AWY66BTQ@mail.gmail.com>
 <CAJEpuXTjQ77-KL-XgK+FN4ZkAoLTySSpvD7RNeA3xHQ8yf1s3w@mail.gmail.com>
 <CAB9Lf7+Nu0TTNpxuqHgqV4yUP3N3sYOXy=C0PyqCkzeSoXrpWA@mail.gmail.com>
 <CAB9Lf7K=F0__Tw7bFZfd8K9ziyoAby5iqgoHHSBnBDQY2BqEug@mail.gmail.com>
 <04887dcb-9d63-4ee2-9b54-a68dab18ce92@oracle.com>
Message-ID: <CAB9Lf7KT-3GoYFQn543wNEdW+3YfE-6rcWkSn_QkYN2WRQ+xdg@mail.gmail.com>

Thanks Kevin!
That's disappointing (if also understandable) to hear that user-supplied
shaders may never happen, but yeah that's a separate discussion.

*> I would need to be convinced that multiple applications would benefit
from such a feature*
Regarding other applications, I wrote about this in my initial email. I
know there's a lot of discussion in this thread so it's easy for stuff like
that to get lost, but I'd be happy to discuss in more detail if you're not
convinced yet.

*> , and that your proposed solution -- as documented and exposed by the
public API -- is the best way to go.*
Great! I'll prepare a draft PR, and a comprehensive detail of the design
choices and my thoughts on each.
It might be a little while before I send such a thing, since I'll take my
time, but I'm glad to have the OK to get started on the second step
outlined in the contribution guide.

*> The next step, then, is to get feedback from other application
developers as to whether and how they would use this.*
Will do. There aren't many projects I've found that seem to use the 3D
portion of JavaFX, so I don't know how much feedback I'll get from this,
but I'll get feedback from the handful of projects which do use it,
including the ones I highlighted previously.
I was hoping for some of that feedback here, but as nobody has commented on
whether/how they would use it, I'll start reaching out.

*> A Draft PR might be OK as long as the focus is on the API and the use
cases. I presume you have read the CONTRIBUTING guidelines [0], especially
the part about adding new features? [1]*
Yep!
I'll prepare a draft PR, as well as a comprehensive detail of the factors
I've considered behind the API design choices.
Was holding off until I got your approval on the discussion.

*> As Michael mentioned, it is helpful to discus how this might fit in with
other possible future improvements.*
>From my perspective, there aren't very many other features which are
impacted by/conflict with vertex colors.
I've detailed pretty much every feature I think could be added and how
vertex colors do/don't impact them.

*More realistic features (And how vertex colors impacts them):*
 - Supporting tri-strips, quads, or other primitives. (There are no
implications that aren't there from existing design choices)
 - Allowing the user to disable mip-mapping. (Feature not related)
 - Allowing the user to change coordinate system. (Feature not related)
 - Fog (Feature not related)
 - New built-in primitives, similar to Cylinder.java, Sphere.java, etc:
Cone.java, Capsule.java. (In theory we could support vertex colors on
these, but I'm not sure what purpose vertex colors would serve here or how
we'd expose this to the end-user.)
 - Built-in Quaternion & Matrix data structures. (Feature not related)
 - Allow setting texture wrapping mode. (REPEAT / CLAMP / etc, Feature not
related)
 - Allow setting texture filtering mode. (LINEAR / NEAREST / etc, Feature
not related)
 - Choosing polygon winding order. (Vertex colors not related)
 - Cube maps (Vertex colors not related)
 - Performance Improvement: Draw Call instancing (Feature not related)
 - More backends (Vulkan, Metal, DX12, etc). Vertex colors will be
supported with minimal performance cost

*Less realistic features (**And how vertex colors impacts them)**:*
 - User-supplied shaders. (Unlikely to be implemented due to the reasons
Kevin provided) This feature does come with some design implications for
vertex colors, but they have already been fleshed out & addressed earlier
in the thread.
 - Deferred shading & support of > 3 lights. (Vertex colors don't add any
new complexities to such a feature, but they might require an extra render
pass, as would all the existing vertex buffers.)
 - Stencil Testing (Feature not related, I don't think this will be added
due to the scene-graph design of JavaFX not working well with this feature
conceptually)
 - Some method of creating an outline of a particular mesh. (A discussion
would need to occur regarding how the outline would visually appear, which
could include vertex data in theory.)
 - Automatic sorting of polygons by distance to camera for better handling
of transparency. (Feature not related)
 - Non-phong lighting such as PBR. (Feature not related beyond the fact
that vertex colors would be accounted for in the shaders)
 - Bloom (I don't believe this will be added as this feature is more niche
and I don't think JavaFX has many people who'd benefit from this. Feature
not related)
 - Normal Mapping (Feature not related)
 - Realtime shadows (Feature not related)

*> If it proceeds further, be prepared to come up with a plan to document,
test, implement the new API on all platforms. You will need to modify the
shaders for each of the graphics APIs. We might ask you to provide at least
an initial implementation for the in-progress metal pipeline*
*> All of this is by way of saying that even if this feature proceeds, it
won't happen quickly.*
Of course. It should be no big deal to make the changes to support this
feature in Metal (assuming I'm not responsible for the non-vertex color
portions)
However, I have a decent concern which is that I lack any Apple hardware to
test with. I could work with others I know who have Apple hardware, but
this testing would likely be remote. (Unless I can find someone nearby
who's willing to let me borrow machine(s) to test.)
Does Apple have anything akin to RenderDoc available for Metal? I'd assume
so, but I don't know.
Does JavaFX support 3D on iOS, or would this be looking to just support Mac
OS X? Would be an extra device I don't have that would need to be tested.
(And doesn't Apple charge in order to develop for iOS?)
Maybe the person/group working on the Metal implementation right now would
be able to assist when it comes to testing too?
Do you have a contact I can reach out to, so I can get these questions
answered? Thanks!


On Mon, Aug 26, 2024 at 6:25?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> As Michael mentioned, it is helpful to discus how this might fit in with
> other possible future improvements. Given the points you raised, I think we
> can now decouple the discussion of whether and how to add vertex colors to
> 3D TriangleMesh from the more general discussion of user-defined geometry.
> Especially since adding support for user-defined shaders is not going to
> happen any time soon (if ever). This has been looked at in the past, but
> always runs into a couple fundamental problems -- for one, we do not want
> to expose the low-level rendering library that Prism happens to be using on
> a particular platform (which could change over time: OpenGL --> Metal on
> macOS, etc), so we would need a graphics-language-neutral shading language
> and figure out how to wire that up to the renderer without exposing Prism
> internals.
>
> So back to your proposal to add vertex colors to 3D TriangleMesh, it seems
> like a somewhat interesting feature, but not a high priority for us. I
> would need to be convinced that multiple applications would benefit from
> such a feature, and that your proposed solution -- as documented and
> exposed by the public API -- is the best way to go.
>
> The next step, then, is to get feedback from other application developers
> as to whether and how they would use this. A Draft PR might be OK as long
> as the focus is on the API and the use cases. I presume you have read the
> CONTRIBUTING guidelines [0], especially the part about adding new features?
> [1]
>
> If it proceeds further, be prepared to come up with a plan to document,
> test, implement the new API on all platforms. You will need to modify the
> shaders for each of the graphics APIs. We might ask you to provide at least
> an initial implementation for the in-progress metal pipeline [2].
>
> All of this is by way of saying that even if this feature proceeds, it
> won't happen quickly.
>
> -- Kevin
>
> [0] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> [1]
> https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions
> [2] https://github.com/openjdk/jfx-sandbox/tree/metal
>
>
> On 8/25/2024 5:45 PM, Knee Snap wrote:
>
> Hoping for further feedback from Michael and others on this feature
> proposal, as I'm hoping to work on a draft PR soon.
>
> Thanks!
>
> On Fri, Aug 23, 2024 at 2:03?PM Knee Snap <kneester77 at gmail.com> wrote:
>
>> Thanks for the clarification on how the design would work.
>>
>> However, this design is separate/unrelated to the goal of this feature
>> proposal.
>> Instead of extending TriangleMesh, you imagine a new separate mesh which
>> can eventually be used to support user-supplied shaders.
>> I do hope to propose such a feature at a future date (support
>> user-defined shaders), but until such a proposal this system isn't super
>> relevant / doesn't have much relation to the current proposal.
>>
>>
>> *The future we both see for the future of working with meshes is a
>> scenario with two (or potentially more) mesh classes: *
>> *#1) *TriangleMesh (No dealing with shaders, buffers, and other advanced
>> capabilities)
>> *#2) *VertexMesh (or name it ShaderMesh, etc), which allows the user to
>> do more advanced capabilities and lets the user define their own
>> buffers, which could end up looking like the design you've shown.
>>
>> But critical to this design is understanding that only TriangleMesh needs
>> explicit vertex color support.
>> VertexMesh/ShaderMesh/etc would be able to support vertex colors
>> implicitly due to its ability to have the user supply arbitrary buffers and
>> shaders.
>> So the whole purpose of my proposal is that this feature belongs in
>> TriangleMesh (or an extension of TriangleMesh), but is currently missing.
>> The example you've linked however does not extend TriangleMesh, instead
>> it's starting work on the future proposal, ignoring the need for this
>> feature in the existing TriangleMesh.
>>
>> I hope this helps clarify!
>>
>> On Fri, Aug 23, 2024 at 12:53?AM Michael Strau? <michaelstrau2 at gmail.com>
>> wrote:
>>
>>> I've created a rough prototype to illustrate what I mean:
>>> https://github.com/mstr2/jfx/tree/experiments/vertexmesh
>>>
>>> This is how you would use VertexMesh in an application:
>>>
>>>     var mesh = new VertexMesh<>(Vertex.PositionTexCoord.class);
>>>
>>>     mesh.getVertices().addAll(
>>>         new Vertex.PositionTexCoord(
>>>             new Point3D(0, 0, 0),
>>>             new Point2D(0, 0)),
>>>
>>>         new Vertex.PositionTexCoord(
>>>             new Point3D(100, 0, 0),
>>>             new Point2D(1, 0)),
>>>
>>>         new Vertex.PositionTexCoord(
>>>             new Point3D(0, 100, 0),
>>>             new Point2D(0, 1))
>>>     );
>>>
>>>     mesh.getIndices().addAll(0, 2, 1);
>>>
>>>     var meshView = new MeshView(mesh);
>>>     meshView.setMaterial(new PhongMaterial(Color.RED));
>>>     meshView.setCullFace(CullFace.NONE);
>>>
>>>     stage.setScene(new Scene(new Group(meshView)));
>>>     stage.show();
>>>
>>>
>>> In addition to PositionTexCoord, we could then also offer
>>> PositionNormal, PositionNormalTexCoord, PositionColor,
>>> PositionNormalColor, and PositionNormalColorTexCoord. These objects
>>> are supposed to be data carriers for vertices, and could be
>>> user-definable in the future.
>>>
>>> Note that this is by no means a well thought-out proposal, it's just a
>>> rough sketch to get the basic idea across. Most likely, this API is
>>> deficient in many ways, so take it as a discussion point rather than a
>>> serious API proposal.
>>>
>>>
>>>
>>> On Fri, Aug 23, 2024 at 6:49?AM Knee Snap <kneester77 at gmail.com> wrote:
>>> >
>>> > Gottcha,
>>> >
>>> > That helps give the context I need to better elaborate. And to be
>>> clear I'm not suggesting you've done anything wrong, I realized maybe I had
>>> implied that I was upset, so I just wanted to say explicitly that is not
>>> the case.
>>> >
>>> > Anywho, regarding CustomMesh<TVertex> it would be impossible to
>>> inherit from TriangleMesh.java without breaking the existing API
>>> specification. At least, when I assume TVertex is the representation of a
>>> single vertex. If this assumption was wrong, and it intended to be the
>>> definition of the vertex, that scenario will also be addressed.
>>> >
>>> > TriangleMesh.java does not currently use vertex objects, and making
>>> such a TVertex to represent each individual vertex is incompatible without
>>> changing the current public TriangleMesh API specification. If the idea of
>>> a vertex object only exists within CustomMesh<TVertex> and not
>>> TriangleMesh, then it's a second-class way of writing to mesh data since it
>>> would only work on a subset of available mesh types, whereas writing
>>> directly to the buffers (as it works now) would have worked in all cases.
>>> If I (someone using JavaFX) want to make utilities for creating meshes, it
>>> rules out using TVertex unless I commit to never using the base
>>> TriangleMesh.
>>> >
>>> > Additionally, using individual vertex objects provides no utility, but
>>> requires a  decent amount of added code complexity, as now there needs to
>>> be a way to correlate vertex objects with buffer positions, and keep them
>>> up to date as the buffer also changes. (What does it mean when a vertex is
>>> moved in the buffer, but the ObservableFloatArray wasn't told that and it
>>> was just given a new full array replacement? This is currently the only way
>>> to update an ObservableFloatArray. Let's consider this vertex object for a
>>> second. What is it? Is it a wrapper around the underlying buffer? If so,
>>> every single time the array changes, all vertex objects would become
>>> invalidated as there's no way to ensure the objects point to the correct
>>> data in the array, or even to know if that data even exists anymore. If
>>> it's not a wrapper around the array then we'd need to make changes to the
>>> array backport to the object. Which has the same problem since the main way
>>> to update the array is to provide a fully new array, meaning we would have
>>> no way to associate the new array contents with the old objects. The only
>>> solution would be to break the API spec and make these new vertex objects
>>> the authoritative data source and not the arrays, which breaks existing
>>> code.
>>> >
>>> > But I'd like to drive home the final nail. There's pretty much no
>>> benefit to be had by having vertices as objects anyways. The 3D/GPU
>>> paradigm is easiest to work with when treating vertex data as arrays and
>>> not individual vertex objects. (Can refer to OpenInventor, Ogre, etc, to
>>> confirm this design choice is standard across other object-oriented 3D
>>> frameworks). This is because at the end of the day, this is what gets
>>> passed directly to the GPU. Adding layers of abstraction is helpful for
>>> creating/modifying the array, but not for representing it in memory.
>>> >
>>> > In other words, while TVertex might intuitively make sense from a
>>> general object-oriented perspective, array buffers are almost always
>>> preferable to vertex objects, even in object-oriented projects. And when
>>> individual objects are desired, they can exist / act as wrappers in
>>> user-code, which benefits of objects we cannot provide automatically, as it
>>> requires information only the user knows about the organization of the
>>> arrays.
>>> >
>>> > But what about if TVertex is not a vertex,  but instead a definition
>>> of what buffers the mesh has? Well, we already have that, and it's called
>>> VertexFormat. Making it a generic parameter also wouldn't really provide
>>> any benefit anyways. Instead of making CustomMesh<TriangleMesh>, I propose
>>> expanding VertexFormat to allow for additional arbitrarily defined buffers.
>>> However, I do not think we need to expose this functionality publicly yet,
>>> which is why I've not documented it after the suggestion. We can keep it as
>>> internal implementation details until it's time to add user-supplied
>>> shaders. Doing so will give us maximum flexibility when it is time to make
>>> it public.
>>> >
>>> > This way also has the benefit of us being able to retroactively
>>> include TriangleMesh's points/texCoords/normals arrays in the shader system
>>> with very little complexity, as they are already part of VertexFormat.
>>> >
>>> > Also thanks for the suggestion about the JEPs, I'll keep this in mind
>>> making future proposals, and it sounds like I should follow-up discussing
>>> various different implementation options and why I've chosen the one I've
>>> chosen instead. I suspect the reason this feels somewhat underdeveloped
>>> from the API perspective is because it's the simplest option I came up with
>>> that had the best API outcome and I didn't elaborate as much as I could
>>> have on why others I thought about weren't satisfactory.
>>> >
>>> > Thanks again for the feedback, I look forward to hearing back again ?
>>> >
>>> > On Thu, Aug 22, 2024, 8:08?PM Michael Strau? <michaelstrau2 at gmail.com>
>>> wrote:
>>> >>
>>> >> I understand that you propose to add a special-purpose mesh
>>> >> (GouraudShadedTriangleMesh) instead of adding yet another buffer to
>>> >> the existing TriangleMesh. That might be a valid idea if the goal is
>>> >> to not overload the TriangleMesh class with special-purpose stuff.
>>> >>
>>> >> However, I still feel that the solution space in terms of API isn't
>>> >> explored in enough detail here. It might be the case that
>>> >> CustomMesh<TVertex> is not implementable (and it might also be the
>>> >> case that CustomMesh<TVertex> isn't a good idea to begin with). But at
>>> >> this point, none of this is obvious to me.
>>> >>
>>> >> Usually, when you propose a new feature, you should explain the
>>> >> motivation, goals and non-goals, alternatives, and so on (you can use
>>> >> a JEP template for that if you like). You adequately addressed the
>>> >> motivation for your proposed enhancement, but I feel that the
>>> >> discussion of different approaches should be expanded upon. I'm not
>>> >> convinced that CustomMesh<TVertex> is impossible to implement: if
>>> >> TVertex can only ever be PositionTexCoord, PositionNormalTexCoord,
>>> >> PositionColorTexCoord, and PositionNormalColorTexCoord (and this is
>>> >> enforced, for example using sealed interfaces), then why wouldn't we
>>> >> be able to connect this to our existing shaders?
>>> >>
>>> >> Again, I'm not saying that this is a good idea; it might not work for
>>> >> any number of reasons. But I think these alternative approaches should
>>> >> at least be explored a little bit before dismissing them. Maybe it
>>> >> will be GouraudShadedTriangleMesh in the end.
>>> >>
>>> >>
>>> >> On Fri, Aug 23, 2024 at 4:45?AM Knee Snap <kneester77 at gmail.com>
>>> wrote:
>>> >> >
>>> >> > Was hoping to get feedback on my suggestion instead, but another
>>> suggestion doesn't work.
>>> >> >
>>> >> > The idea of a CustomMesh<TVertex> is impossible to implement until
>>> after we have fully user-supplied shader support, which I've already
>>> addressed as being not the scope of this change (but instead it is a
>>> separate future change which is not impacted by this) it also feels like
>>> this point may have been missed as well.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240826/b100fd37/attachment-0001.htm>

From jpereda at openjdk.org  Tue Aug 27 15:55:25 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 27 Aug 2024 15:55:25 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
Message-ID: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>

This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.

I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.

On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:

Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration

which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 

Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.

Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:


Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
        at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
        at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
        at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
        at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
        at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
        at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
        at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
 ...


because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

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

Commit messages:
 - prevent NPE if FontConfigManager.FcCompFont is null

Changes: https://git.openjdk.org/jfx/pull/1546/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339068
  Stats: 12 lines in 2 files changed: 6 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1546.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1546/head:pull/1546

PR: https://git.openjdk.org/jfx/pull/1546

From duke at openjdk.org  Tue Aug 27 16:00:44 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Tue, 27 Aug 2024 16:00:44 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
Message-ID: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>

On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder

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

Commit messages:
 - 8334124: Rendering issues with CSS "text-shadow" in WebView

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

PR: https://git.openjdk.org/jfx/pull/1547

From kcr at openjdk.org  Tue Aug 27 17:50:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 27 Aug 2024 17:50:10 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <YZcuODJNhSEQ4MQyxhiO42q5XPkvT_w_ImhFrd2SNns=.d6958862-d7ad-425b-b5ce-e574c8c7d690@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

@prrace Can you take a look at this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2313172471

From kcr at openjdk.org  Tue Aug 27 17:51:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 27 Aug 2024 17:51:09 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
In-Reply-To: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
Message-ID: <mHxjGKu496AX7zNE4o6-nc8MSJSAKG7nGQpPheZoPmk=.cd46bea0-93c0-4d67-95fe-ba3567314e84@github.com>

On Tue, 27 Aug 2024 15:55:47 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder

Reviewers: @kevinrushforth @jaybhaskar

@Schmidor Would it be possible to add an automated test for this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1547#issuecomment-2313173923
PR Comment: https://git.openjdk.org/jfx/pull/1547#issuecomment-2313174703

From jhendrikx at openjdk.org  Tue Aug 27 18:16:11 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 27 Aug 2024 18:16:11 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <P1C9W-7ASjELJ0nVv8UhoJEPnuJrqz6Tb_lF1PvfJuM=.d4f234c3-02bc-4575-8a68-045e8e0f1dc8@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> Shouldn't we fail gracefully after LogicalFont::getSlot0Resource if slot0FontResource is finally null?

It calls `PrismFontFactory::getDefaultFontResource` -- this function looks practically everywhere to find some kind of font.  I think if it fails, JavaFX should just not start up at all (unless using FX without fonts is a "supported" configuration).  Having no font at all will no doubt lead to all kinds of problems later on, so whether supported or not, we'd need checks everywhere then to ensure code can handle having no fonts.

If you think that there still is a font, then perhaps `PrismFontFactory::getDefaultFontResource` should return that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2313216418

From jhendrikx at openjdk.org  Tue Aug 27 18:21:10 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 27 Aug 2024 18:21:10 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <3DKFhSfe5zSAGfD787aNUMtBPz7wQfnnAOrFZJLTm3g=.ffc06dde-fe4c-429c-9301-713316c5b1fc@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

The changes seem to deal with the case where Font Config is unavailable on Linux.  I think those changes are fine.  However, if it turns out there isn't any font at all (via an alternative source) I think it would be best to just fail.

modules/javafx.graphics/src/main/java/com/sun/javafx/font/LogicalFont.java line 180:

> 178:                 physicalFullName = fcCompFont.firstFont.fullName;
> 179:                 physicalFileName = fcCompFont.firstFont.fontFile;
> 180:             }

These changes seem okay, as it is assuming that the font is available via font config, but it may have originated from somewhere else.

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2313223687
PR Review Comment: https://git.openjdk.org/jfx/pull/1546#discussion_r1733329665

From jhendrikx at openjdk.org  Tue Aug 27 18:26:10 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 27 Aug 2024 18:26:10 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <homBjodKBshRvJ_TBQMGct-OsYm3GV46JPETtNnAnAc=.60bed63e-2984-4854-a3e2-004d59d31479@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFactory.java line 142:

> 140:             for (int i=0; i<linkedFontNames.size(); i++)  {
> 141:                 info.add(linkedFontNames.get(i), linkedFontFiles.get(i), null);
> 142:             }

Downstream code seems to be able to deal with empty `FontFallbackInfo`, so I guess this is also okay.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1546#discussion_r1733334899

From duke at openjdk.org  Tue Aug 27 20:21:43 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Tue, 27 Aug 2024 20:21:43 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
Message-ID: <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>

> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  add test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1547/files
  - new: https://git.openjdk.org/jfx/pull/1547/files/e86686e2..c0e4adcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1547&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1547&range=00-01

  Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1547.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1547/head:pull/1547

PR: https://git.openjdk.org/jfx/pull/1547

From duke at openjdk.org  Tue Aug 27 20:33:07 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Tue, 27 Aug 2024 20:33:07 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
Message-ID: <ctOKD_lA9oWwDbvcbJr10omouYH-03BNZEvhqY70WLo=.dd5b20b5-2ea6-4a8a-8625-d3fa60524322@github.com>

On Tue, 27 Aug 2024 20:21:43 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

I've added one: Counting pixels in an area for checking whether the shadow is rendered at the appropriate text and not on the other.

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

PR Comment: https://git.openjdk.org/jfx/pull/1547#issuecomment-2313458265

From duke at openjdk.org  Tue Aug 27 23:30:27 2024
From: duke at openjdk.org (duke)
Date: Tue, 27 Aug 2024 23:30:27 GMT
Subject: Withdrawn: 8334593: Adding, removing and then adding a JFXPanel again
 leads to NullPointerException
In-Reply-To: <v0bui-xQy3p8lk5CNG2vRzuWRKFh4jgWPOVSZY-XEAA=.341ed090-0a37-4767-96b7-96dd990b6bee@github.com>
References: <v0bui-xQy3p8lk5CNG2vRzuWRKFh4jgWPOVSZY-XEAA=.341ed090-0a37-4767-96b7-96dd990b6bee@github.com>
Message-ID: <IYEpEVn1eJSEmCYI8tgWxb5BCzIFbP9qC8OQqak6QsQ=.6f6db089-7b76-4b0a-b20f-093f49623d77@github.com>

On Fri, 28 Jun 2024 08:49:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null.
> Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null...
> so when GlassScene.updateSceneState is called, it results in NPE.
> Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1493

From jbhaskar at openjdk.org  Wed Aug 28 14:18:11 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 28 Aug 2024 14:18:11 GMT
Subject: [jfx23u] RFR: 8338886: JavaFX debug builds fail on macOS
Message-ID: <WbpnqLaBBg1OwMualTwG-mzmUIO-cxiDB2RwFW2oZpI=.fac55073-6652-4273-bd10-b952ab45d88d@github.com>

A clean backport to jfx23u. The fix is for a build error , failing to build on mac on debug mode.

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

Commit messages:
 - Backport 48497168892f5625f77936eccf19e836a6c1971e

Changes: https://git.openjdk.org/jfx23u/pull/16/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=16&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338886
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx23u/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/16/head:pull/16

PR: https://git.openjdk.org/jfx23u/pull/16

From angorya at openjdk.org  Wed Aug 28 14:24:27 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Aug 2024 14:24:27 GMT
Subject: [jfx23u] RFR: 8338886: JavaFX debug builds fail on macOS
In-Reply-To: <WbpnqLaBBg1OwMualTwG-mzmUIO-cxiDB2RwFW2oZpI=.fac55073-6652-4273-bd10-b952ab45d88d@github.com>
References: <WbpnqLaBBg1OwMualTwG-mzmUIO-cxiDB2RwFW2oZpI=.fac55073-6652-4273-bd10-b952ab45d88d@github.com>
Message-ID: <qEsrPNiR7WhPaFwx6r-eHx15lF6XduvV1caLOLciIaM=.e7aee4f2-cc2a-453a-93d4-47c7a31b43f3@github.com>

On Wed, 28 Aug 2024 14:10:04 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx23u. The fix is for a build error , failing to build on mac on debug mode.

clean backport

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx23u/pull/16#pullrequestreview-2266440738

From kcr at openjdk.org  Wed Aug 28 20:47:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Aug 2024 20:47:10 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
Message-ID: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>

A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.

This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.

This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.

Summary of the changes:

* Attach the AppKit thread to the JVM as a daemon
* Do not detach the thread when the FX main event loop terminates
* Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
* Terminate the KeepAlive thread when the FX toolkit finishes

Testing:

I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

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

Commit messages:
 - Update explanatory comments
 - 8190329: [macos] Swing InterOp Platform.exit() crash

Changes: https://git.openjdk.org/jfx/pull/1545/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339178
  Stats: 368 lines in 8 files changed: 335 ins; 29 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1545.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1545/head:pull/1545

PR: https://git.openjdk.org/jfx/pull/1545

From angorya at openjdk.org  Wed Aug 28 20:47:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Aug 2024 20:47:10 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <3OvkrOgVSkbrlc2D3b1AatGy5QAyi2j-E9AVeKCRbhc=.e12bdd1e-5ce4-42c0-bad3-d4b58cbed347@github.com>

On Mon, 26 Aug 2024 21:11:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 81:

> 79:         thr.setName("JavaFX-KeepAlive");
> 80:         thr.setDaemon(false);
> 81:         thr.start();

is it possible to reuse some other thread for this purpose?
this may not be an issue when virtual threads take hold, but right now threads are precious native resource.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1545#discussion_r1731870591

From kcr at openjdk.org  Wed Aug 28 20:47:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Aug 2024 20:47:10 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <3rhjZj84drs6WAvI-oYDvdiCD6Ax8XM-6zDb7EoWrdk=.262b17a0-5077-4cf8-9cb5-c96b86ba49c6@github.com>

On Mon, 26 Aug 2024 21:11:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

@prsadhuk Can you be one of the reviewers?

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

PR Comment: https://git.openjdk.org/jfx/pull/1545#issuecomment-2316216722

From kcr at openjdk.org  Wed Aug 28 20:47:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Aug 2024 20:47:10 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <3OvkrOgVSkbrlc2D3b1AatGy5QAyi2j-E9AVeKCRbhc=.e12bdd1e-5ce4-42c0-bad3-d4b58cbed347@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
 <3OvkrOgVSkbrlc2D3b1AatGy5QAyi2j-E9AVeKCRbhc=.e12bdd1e-5ce4-42c0-bad3-d4b58cbed347@github.com>
Message-ID: <ai4Dr3gmYqRF5dfWn_udf0vwOY_A8iBweSVTm3sh028=.a4abfc0f-5a36-4bdf-9c4b-f168ee4d1bd2@github.com>

On Mon, 26 Aug 2024 21:57:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
>> 
>> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
>> 
>> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
>> 
>> Summary of the changes:
>> 
>> * Attach the AppKit thread to the JVM as a daemon
>> * Do not detach the thread when the FX main event loop terminates
>> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
>> * Terminate the KeepAlive thread when the FX toolkit finishes
>> 
>> Testing:
>> 
>> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 81:
> 
>> 79:         thr.setName("JavaFX-KeepAlive");
>> 80:         thr.setDaemon(false);
>> 81:         thr.start();
> 
> is it possible to reuse some other thread for this purpose?
> this may not be an issue when virtual threads take hold, but right now threads are precious native resource.

No. The whole reason we are doing this is that there are no other non-daemon threads. I updated the docs to make this more clear. Anyway, threads aren't _that_ scarce as long as you don't create hundreds of them.

Loosely related: This reminds me that `javafx.application.Application.launch` does create an unnecessary thread (on all platforms). There is a long-standing issue to get rid of it:

[JDK-8090323](https://bugs.openjdk.org/browse/JDK-8090323): Consider eliminating the JavaFX-Launcher Thread

It isn't high priority, but would be good cleanup.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1545#discussion_r1732997480

From angorya at openjdk.org  Wed Aug 28 20:47:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Aug 2024 20:47:10 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <ai4Dr3gmYqRF5dfWn_udf0vwOY_A8iBweSVTm3sh028=.a4abfc0f-5a36-4bdf-9c4b-f168ee4d1bd2@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
 <3OvkrOgVSkbrlc2D3b1AatGy5QAyi2j-E9AVeKCRbhc=.e12bdd1e-5ce4-42c0-bad3-d4b58cbed347@github.com>
 <ai4Dr3gmYqRF5dfWn_udf0vwOY_A8iBweSVTm3sh028=.a4abfc0f-5a36-4bdf-9c4b-f168ee4d1bd2@github.com>
Message-ID: <sar3meiccqbxwmiRfjuY-QJn7XSk1OTHgUQfq3zJs2c=.dd6f0d75-e4ad-4bfb-ae01-0d1715ab29aa@github.com>

On Tue, 27 Aug 2024 14:42:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 81:
>> 
>>> 79:         thr.setName("JavaFX-KeepAlive");
>>> 80:         thr.setDaemon(false);
>>> 81:         thr.start();
>> 
>> is it possible to reuse some other thread for this purpose?
>> this may not be an issue when virtual threads take hold, but right now threads are precious native resource.
>
> No. The whole reason we are doing this is that there are no other non-daemon threads. I updated the docs to make this more clear. Anyway, threads aren't _that_ scarce as long as you don't create hundreds of them.
> 
> Loosely related: This reminds me that `javafx.application.Application.launch` does create an unnecessary thread (on all platforms). There is a long-standing issue to get rid of it:
> 
> [JDK-8090323](https://bugs.openjdk.org/browse/JDK-8090323): Consider eliminating the JavaFX-Launcher Thread
> 
> It isn't high priority, but would be good cleanup.

thank you for clarification!
 
never underestimate the happiness with which the app and library developers create new threads...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1545#discussion_r1733039789

From prr at openjdk.org  Wed Aug 28 22:36:28 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 Aug 2024 22:36:28 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <-JXCs7mp2rJhDUKB5Nh-EiGbTvcCJTW2mc_xf2KJdIU=.1666827e-cc7f-4758-8c11-b9b62e520e50@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

I don't understand why this change is needed.

Perhaps I'm misunderstanding, but if usefontconfig is false, that means "I have supplied embedded fonts instead".
In which case the API calls where the null checks are added should not be returning null.

In other words, setting this to false, and not supplying fonts is a misconfiguration.
Arguably we should disable this property and always look for fontconfig.
But one would only know how to misconfigure it by reading the sources to discover this property.

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2316356553

From jbhaskar at openjdk.org  Thu Aug 29 00:12:26 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 29 Aug 2024 00:12:26 GMT
Subject: [jfx23u] Integrated: 8338886: JavaFX debug builds fail on macOS
In-Reply-To: <WbpnqLaBBg1OwMualTwG-mzmUIO-cxiDB2RwFW2oZpI=.fac55073-6652-4273-bd10-b952ab45d88d@github.com>
References: <WbpnqLaBBg1OwMualTwG-mzmUIO-cxiDB2RwFW2oZpI=.fac55073-6652-4273-bd10-b952ab45d88d@github.com>
Message-ID: <kwCKURlBmK3s-k5V89IdTLreghwtRZWhCBcFqKCStXs=.8b55ea99-e189-401c-8542-08b0b8e5d311@github.com>

On Wed, 28 Aug 2024 14:10:04 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx23u. The fix is for a build error , failing to build on mac on debug mode.

This pull request has now been integrated.

Changeset: 5a81743a
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx23u/commit/5a81743a1aabdf2e03103e6fa6301256301830c6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338886: JavaFX debug builds fail on macOS

Reviewed-by: angorya
Backport-of: 48497168892f5625f77936eccf19e836a6c1971e

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

PR: https://git.openjdk.org/jfx23u/pull/16

From duke at openjdk.org  Thu Aug 29 04:51:50 2024
From: duke at openjdk.org (ANUPAM DEV)
Date: Thu, 29 Aug 2024 04:51:50 GMT
Subject: RFR: 8339212: When build jfx in Linux(aarch64),
 gradle downloads the wrong eclipse swt jar
Message-ID: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>

Hi,

I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
Please review.

Regards,
Anupam

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

Commit messages:
 - Updated build.gradle for SWT_FILE_NAME to support Linux aarch64

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

PR: https://git.openjdk.org/jfx/pull/1549

From psadhukhan at openjdk.org  Thu Aug 29 07:30:25 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 29 Aug 2024 07:30:25 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <1UG3qRTSTenKJ3ioV57SOZlQoVZaIwr0gYgwNCmbDzA=.0ed1f25c-f79e-4df8-b7c6-bd9fa0166e24@github.com>

On Mon, 26 Aug 2024 21:11:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

Tested with and without AWT fix https://github.com/openjdk/jdk/pull/20688 and it looks good without crash..

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1545#pullrequestreview-2267897901

From kcr at openjdk.org  Thu Aug 29 11:51:24 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 11:51:24 GMT
Subject: RFR: 8339212: When build jfx in Linux(aarch64),
 gradle downloads the wrong eclipse swt jar
In-Reply-To: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
Message-ID: <LJD73W63xeMq5VQR1DBxh1T1PI99vhgZY0UVAG3o4E8=.17c6f94a-2c8b-484b-96ca-5d49df5b767d@github.com>

On Thu, 29 Aug 2024 04:46:05 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hi,
> 
> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
> from:
>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> to:
>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> Please review.
> 
> Regards,
> Anupam

@anupamdev20 You also need to add an entry for the Linux/aarch64 jar file in `gradle/verification-metadata.xml`. Copy the entry for the Linux / x64 jar file and modify it as needed. Without this, the build will fail on Linux / aarch64. We don't do Linux / aarch64 builds in our CI nor is there a GHA build on Linux / aarch64. I'll file a bug for the latter.

@tiainen Would you be able to test this once Anupam has added the checksum?

Reviewers: @kevinrushforth @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2317421451

From jpereda at openjdk.org  Thu Aug 29 11:56:40 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 29 Aug 2024 11:56:40 GMT
Subject: RFR: 8339236: Suppress removal warnings for Security Manager methods
 in iOS sources
Message-ID: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>

This PR adds the required annotations to the iOS sources in the JavaFX Web module, to allow the compilation of such sources, now that `-Werror` is enabled, in the same way that was done for https://bugs.openjdk.java.net/browse/JDK-8264139 (where it was already mentioned https://github.com/openjdk/jfx/pull/528#issue-910936512 the need of a follow-up for iOS/Android).

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

Commit messages:
 - Add suppress warnings to iOS sources

Changes: https://git.openjdk.org/jfx/pull/1550/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339236
  Stats: 14 lines in 4 files changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1550.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1550/head:pull/1550

PR: https://git.openjdk.org/jfx/pull/1550

From kcr at openjdk.org  Thu Aug 29 11:57:24 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 11:57:24 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
In-Reply-To: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
Message-ID: <otwNtaVc0iyFKt_d4Q9ikTIUiG6p-Ny3pNGHKgJNOkM=.02c58eab-76b5-4bf4-b1e0-ed105c1debd1@github.com>

On Thu, 29 Aug 2024 04:46:05 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hi,
> 
> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
> from:
>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> to:
>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> Please review.
> 
> Regards,
> Anupam

I updated the JBS bug title to be clearer. Can you update this PR title to match?

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2317435726

From kcr at openjdk.org  Thu Aug 29 13:01:28 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 13:01:28 GMT
Subject: RFR: 8339236: Suppress removal warnings for Security Manager
 methods in iOS sources
In-Reply-To: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
References: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
Message-ID: <BBWntvJngGLxlZBVN0N5EM3lZ5kq1cSz3vH57DzZF68=.b6cd3418-7aa3-48a2-9049-a4186f95f73e@github.com>

On Thu, 29 Aug 2024 11:49:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the required annotations to the iOS sources in the JavaFX Web module, to allow the compilation of such sources, now that `-Werror` is enabled, in the same way that was done for https://bugs.openjdk.java.net/browse/JDK-8264139 (where it was already mentioned https://github.com/openjdk/jfx/pull/528#issue-910936512 the need of a follow-up for iOS/Android).

Looks OK. @johanvos might want to review this.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1550#pullrequestreview-2268666679

From jvos at openjdk.org  Thu Aug 29 13:10:28 2024
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 29 Aug 2024 13:10:28 GMT
Subject: RFR: 8339236: Suppress removal warnings for Security Manager
 methods in iOS sources
In-Reply-To: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
References: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
Message-ID: <GIFkH4sl29vi0721u5jBTteMfYVlfNdCzkuf4rd22iU=.29dc3dad-920c-485d-b635-71842688b4bd@github.com>

On Thu, 29 Aug 2024 11:49:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the required annotations to the iOS sources in the JavaFX Web module, to allow the compilation of such sources, now that `-Werror` is enabled, in the same way that was done for https://bugs.openjdk.java.net/browse/JDK-8264139 (where it was already mentioned https://github.com/openjdk/jfx/pull/528#issue-910936512 the need of a follow-up for iOS/Android).

All good. This is in line with what we did in other places.

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1550#pullrequestreview-2268690563

From duke at openjdk.org  Thu Aug 29 13:20:34 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Thu, 29 Aug 2024 13:20:34 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
Message-ID: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>

FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit

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

Commit messages:
 - 8337481 Fix FileSystemJava.pathFileName

Changes: https://git.openjdk.org/jfx/pull/1551/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1551&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337481
  Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1551.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1551/head:pull/1551

PR: https://git.openjdk.org/jfx/pull/1551

From duke at openjdk.org  Thu Aug 29 13:55:27 2024
From: duke at openjdk.org (ANUPAM DEV)
Date: Thu, 29 Aug 2024 13:55:27 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
In-Reply-To: <otwNtaVc0iyFKt_d4Q9ikTIUiG6p-Ny3pNGHKgJNOkM=.02c58eab-76b5-4bf4-b1e0-ed105c1debd1@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <otwNtaVc0iyFKt_d4Q9ikTIUiG6p-Ny3pNGHKgJNOkM=.02c58eab-76b5-4bf4-b1e0-ed105c1debd1@github.com>
Message-ID: <EsoOt-Bvp3-QUPmaVgWfxAAqA2L2yZHMZvCryTdxXwA=.06046b88-6aa7-4da5-969f-adf7c2e27ea9@github.com>

On Thu, 29 Aug 2024 11:55:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
>> from:
>>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> to:
>>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> Please review.
>> 
>> Regards,
>> Anupam
>
> I updated the JBS bug title to be clearer. Can you update this PR title to match?

Hi @kevinrushforth,
Thankyou for the review. Can you please let me know how to get the checksum for aarch64? I see it gets generated automatically by gradle. ( https://github.com/openjdk/jfx/tree/master/gradle#readme )
I do not have aarch64 headful machine to generate the checksum either. As you suggested, copying the entry for Linux /x64 and modifying it will have the same checksum as x86-64 which would be wrong. 
Please suggest.

Thanks,
~Anupam

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2317726959

From duke at openjdk.org  Thu Aug 29 14:11:01 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Thu, 29 Aug 2024 14:11:01 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
Message-ID: <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>

> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  add test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1551/files
  - new: https://git.openjdk.org/jfx/pull/1551/files/328f32b8..85d11d4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1551&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1551&range=00-01

  Stats: 94 lines in 1 file changed: 94 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1551.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1551/head:pull/1551

PR: https://git.openjdk.org/jfx/pull/1551

From kcr at openjdk.org  Thu Aug 29 14:12:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 14:12:22 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
In-Reply-To: <EsoOt-Bvp3-QUPmaVgWfxAAqA2L2yZHMZvCryTdxXwA=.06046b88-6aa7-4da5-969f-adf7c2e27ea9@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <otwNtaVc0iyFKt_d4Q9ikTIUiG6p-Ny3pNGHKgJNOkM=.02c58eab-76b5-4bf4-b1e0-ed105c1debd1@github.com>
 <EsoOt-Bvp3-QUPmaVgWfxAAqA2L2yZHMZvCryTdxXwA=.06046b88-6aa7-4da5-969f-adf7c2e27ea9@github.com>
Message-ID: <gSKC3RTjJtfjlOrnZpnGqe8idrryRUJOmZBQztC7qjo=.6dcd9961-dfd0-4a5c-a1d9-247a99553f4f@github.com>

On Thu, 29 Aug 2024 13:52:39 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Can you please let me know how to get the checksum for aarch64?

Download the file locally, then:


shasum -a 256 org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355.jar

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2317785948

From jpereda at openjdk.org  Thu Aug 29 14:29:23 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 29 Aug 2024 14:29:23 GMT
Subject: Integrated: 8339236: Suppress removal warnings for Security Manager
 methods in iOS sources
In-Reply-To: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
References: <WnwyC28uNaTB4AJqE1j08Th4TSjsvKoVfTPj7Ws-4VU=.c2b32836-b48e-4f00-9a0b-6e77151b35e7@github.com>
Message-ID: <JJZNEyHuw8SKFRQdyBwm_iZ4GZImSf75uTOMZv0aDm0=.c3001d8a-5bfa-458b-a51e-2e36c3d4f26d@github.com>

On Thu, 29 Aug 2024 11:49:58 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the required annotations to the iOS sources in the JavaFX Web module, to allow the compilation of such sources, now that `-Werror` is enabled, in the same way that was done for https://bugs.openjdk.java.net/browse/JDK-8264139 (where it was already mentioned https://github.com/openjdk/jfx/pull/528#issue-910936512 the need of a follow-up for iOS/Android).

This pull request has now been integrated.

Changeset: a53bc589
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a53bc589ac37d490b1406a2b977097a06bf5ac74
Stats:     14 lines in 4 files changed: 11 ins; 0 del; 3 mod

8339236: Suppress removal warnings for Security Manager methods in iOS sources

Reviewed-by: kcr, jvos

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

PR: https://git.openjdk.org/jfx/pull/1550

From duke at openjdk.org  Thu Aug 29 14:43:39 2024
From: duke at openjdk.org (ANUPAM DEV)
Date: Thu, 29 Aug 2024 14:43:39 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
 [v2]
In-Reply-To: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
Message-ID: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>

> Hi,
> 
> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
> from:
>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> to:
>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
> 
> Please review.
> 
> Regards,
> Anupam

ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:

  Updated verification-metadata.xml. Added sha256 for Linux /aarch64 jar

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1549/files
  - new: https://git.openjdk.org/jfx/pull/1549/files/8433800f..b00c2f32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1549&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1549&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1549.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1549/head:pull/1549

PR: https://git.openjdk.org/jfx/pull/1549

From duke at openjdk.org  Thu Aug 29 14:47:25 2024
From: duke at openjdk.org (ANUPAM DEV)
Date: Thu, 29 Aug 2024 14:47:25 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
In-Reply-To: <gSKC3RTjJtfjlOrnZpnGqe8idrryRUJOmZBQztC7qjo=.6dcd9961-dfd0-4a5c-a1d9-247a99553f4f@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <otwNtaVc0iyFKt_d4Q9ikTIUiG6p-Ny3pNGHKgJNOkM=.02c58eab-76b5-4bf4-b1e0-ed105c1debd1@github.com>
 <EsoOt-Bvp3-QUPmaVgWfxAAqA2L2yZHMZvCryTdxXwA=.06046b88-6aa7-4da5-969f-adf7c2e27ea9@github.com>
 <gSKC3RTjJtfjlOrnZpnGqe8idrryRUJOmZBQztC7qjo=.6dcd9961-dfd0-4a5c-a1d9-247a99553f4f@github.com>
Message-ID: <e7TAnN6gOOyLrhRKz4_T1lPlaHl_kI-TeSMvkahxOEE=.a394a4fd-6f36-4919-87a6-5da6730a04e3@github.com>

On Thu, 29 Aug 2024 14:09:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi @kevinrushforth,
>> Thankyou for the review. Can you please let me know how to get the checksum for aarch64? I see it gets generated automatically by gradle. ( https://github.com/openjdk/jfx/tree/master/gradle#readme )
>> I do not have aarch64 headful machine to generate the checksum either. As you suggested, copying the entry for Linux /x64 and modifying it will have the same checksum as x86-64 which would be wrong. 
>> Please suggest.
>> 
>> Thanks,
>> ~Anupam
>
>> Can you please let me know how to get the checksum for aarch64?
> 
> Download the file locally, then:
> 
> 
> shasum -a 256 org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355.jar

Thanks @kevinrushforth. I have updated verification-metadata.xml.

Regards,
Anupam

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2317930492

From john.hendrikx at gmail.com  Thu Aug 29 15:03:08 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 29 Aug 2024 17:03:08 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
Message-ID: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>

TLDR; AnimationTimer is being fed a time not based on the time the next 
frame is expected to be rendered but the time of when the FX thread is 
finally scheduled to do the callbacks.? This time fluctuates wildly, and 
is a time that's useless for doing frame accurate calculations of 
animations (such a time shouldn't fluctuate at all, unless a frame gets 
skipped).

Longer version:

I've been investigating an "issue" with AnimationTimers.

Timers have a `void handle(long)` method that is called with a time in 
nano seconds that is supposed to be the reference value to be used for 
animations. The reference value is used to calculate in the 
implementation how the animation should look at a specific point in time.

However, I've found that the values being received by the AnimationTimer 
fluctuate wildly, and the differences between the current and previous 
calls of the time passed to the handle method can be anywhere from 1ms 
to 30ms.

The frequency of the calls is however still close to 60 fps -- now, 
correct me if I'm wrong, but when drawing animations that are supposed 
to be displayed on a 60 fps screen, shouldn't the AnimationTimer be 
called (which is supposed to "prepare" things for the **next** frame) 
with a relatively consistently increasing value?? (ie. 0, 16, 32, 48, 64 
ms) instead of what I'm seeing now (0, 30, 33, 60, 66 ms).? Assuming 
that the animation will simply be visible on the next frame, then my 
calculations using this fluctuating timer are going to be quite jittery 
when put on a screen that refreshes at exactly 60 fps.? My animation 
calculations would look like:

 ??? |------|-|------|-|--------|-|------|-|--

While being displayed on a screen that does this:

 ??? |---|---|---|---|---|---|---|---|---|---

I compared the values I receive from `handle(long)` with 
`System.nanoTime()` and found no significant differences between them; 
in other words, the actual calling code is already quite a jittery process.

So I dug a bit deeper -- internally, a subclass of Timer is used (in my 
case WinTimer, the Windows one).? Assuming that the problem stemmed from 
there, I replaced this with a **highly** accurate timer that simply busy 
waits until the appropriate frame time is reached.? The accuracy of this 
is almost nanosecond perfect (ie, within 0.000001 of a millisecond, at 
the cost of a CPU core of course, but that's not relevant for the 
problem).? This however had 0 impact on the accuracy of the 
AnimationTimer -- it was still fluctuating wildly, on the order of 20-30 
milliseconds (several million times less accurate than my Timer 
implementation).

Digging further, the AnimationTimer is not actually called directly from 
the timing thread (which is a different thread than the FX thread, so 
that makes sense).? Instead, the timer is called from the FX thread by 
having my highly accurate timer call Application::invokeLater (similar 
to Platform::runLater).? Once the FX thread picks up this task, it calls 
`System.nanoTime()` as a "base" for all AnimationTimer callbacks... 
however, this value is now distorted by how long it takes the scheduler 
to wake up the FX thread and pick up the invokeLater task.

I find this highly surprising.? To make jitter free animations, you want 
a base time that?increments consistently, and maybe sometimes skips a 
frame.? So you'd expect the base time value to increment with 1 / 
frameRate,?not some arbitrary time for when the work was started 
(fluctuating with thread scheduling delays).? I mean, I'm preparing 
things for the **next** frame, so the time I receive should reflect when 
that frame is likely to be drawn, not roughly be the same time my method 
is actually being called (if I wanted that, I can 
call?`System.nanoTime()` myself...).

I feel this is actually a bug.? It is probably a bit worse on the 
Windows platform where the scheduler generally has a 15 ms period (which 
explains the?fluctuations I'm seeing between 0 and 30 ms). However, this 
really shouldn't matter.? When doing animations, you want to call not 
with the current system time, but with the expected render time of the 
next frame.? Calling `System.nanoTime` and using that as base time is 
just simply incorrect, although can be "close" to correct if your 
platform schedules say with a 1 ms period (it will only fluctuate 
between 0 and 2 ms then).

There should however be 0 fluctuation, unless a frame was skipped.? With 
a 60 fps frame rate, all the nano values passed to AnimationTimer should 
be multiples of 16,666,666 ns.

Let me know what you think, perhaps I'm missing something here.

--John

PS. I think it is possible to do the pulse waiting on the FX thread 
itself; the FX thread can be interrupted when a Platform::runLater call 
comes in, but at all other times it can just wait for the next pulse 
directly on that thread.? With my highly accurate timer implementation 
(I made another variant that is accurate to within a few tenths of a 
milliseconds without busy waiting) Animation code would be called much 
faster, so it would have more time run before the next frame is 
displayed... at it is now, at least on Windows, the AnimationTimer can 
get called just a few milliseconds before the next frame is displayed, 
leaving precious little time to do any kind of calculations.



From kcr at openjdk.org  Thu Aug 29 15:32:26 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 15:32:26 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <5twfx-OM-0bZBUiulrV56SWfZh_jQmha1BZcnfF4XPw=.198a5e58-6e66-4a16-b68c-063eeb3c1312@github.com>

On Mon, 26 Aug 2024 21:11:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

tests/system/src/test/java/test/launchertest/TestAppPlatformExitAWT.java line 50:

> 48:             Platform.exit();
> 49:         });
> 50:         d.setVisible(true);

By code inspection, I realized that the `JDialog` might be shown before `Platform::exit` has been called, meaning that the test could pass even if the bug is present. I'll push a fix to move the setVisible inside the runLater lambda, using a `SwingUtilities::invokeLater`. This will ensure that it provokes the bug.

I ran the updated test and confirm that the test still fails without the fix and passes with the fix.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1545#discussion_r1736501384

From kcr at openjdk.org  Thu Aug 29 15:39:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 15:39:45 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash [v2]
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <oxbARvwxoeTL4_xc_P76urAxueazNJBxK6sPPbyIVBY=.32199629-8ed7-4db1-b688-79dea38b1355@github.com>

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Make sure that the Swing window is shown after the Platform.exit

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1545/files
  - new: https://git.openjdk.org/jfx/pull/1545/files/61ab3c35..bb4ef9ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1545&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1545&range=00-01

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

PR: https://git.openjdk.org/jfx/pull/1545

From kcr at openjdk.org  Thu Aug 29 15:56:59 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 15:56:59 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash [v3]
In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
Message-ID: <ZCjqXxOmqo45nnaDfpHqKtOaF6bnNYvOrYqMANW0814=.f9beefa5-01cf-4dd2-a84f-ab1d3e9cb4b8@github.com>

> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
> 
> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
> 
> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
> 
> Summary of the changes:
> 
> * Attach the AppKit thread to the JVM as a daemon
> * Do not detach the thread when the FX main event loop terminates
> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
> * Terminate the KeepAlive thread when the FX toolkit finishes
> 
> Testing:
> 
> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1545/files
  - new: https://git.openjdk.org/jfx/pull/1545/files/bb4ef9ba..f2e6561d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1545&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1545&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1545.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1545/head:pull/1545

PR: https://git.openjdk.org/jfx/pull/1545

From michaelstrau2 at gmail.com  Thu Aug 29 16:18:48 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 29 Aug 2024 18:18:48 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
Message-ID: <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>

The entire idea of using a system timer in the presence of v-sync is
wrong, it simply can't work reliably. We get accurate frame
synchronization for free from Direct3D, we should use that instead of
system timers.

There's a JBS issue with a detailed analysis:
https://bugs.openjdk.org/browse/JDK-8136536


On Thu, Aug 29, 2024 at 5:40?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> TLDR; AnimationTimer is being fed a time not based on the time the next
> frame is expected to be rendered but the time of when the FX thread is
> finally scheduled to do the callbacks.  This time fluctuates wildly, and
> is a time that's useless for doing frame accurate calculations of
> animations (such a time shouldn't fluctuate at all, unless a frame gets
> skipped).
>
> Longer version:
>
> I've been investigating an "issue" with AnimationTimers.
>
> Timers have a `void handle(long)` method that is called with a time in
> nano seconds that is supposed to be the reference value to be used for
> animations. The reference value is used to calculate in the
> implementation how the animation should look at a specific point in time.
>
> However, I've found that the values being received by the AnimationTimer
> fluctuate wildly, and the differences between the current and previous
> calls of the time passed to the handle method can be anywhere from 1ms
> to 30ms.
>
> The frequency of the calls is however still close to 60 fps -- now,
> correct me if I'm wrong, but when drawing animations that are supposed
> to be displayed on a 60 fps screen, shouldn't the AnimationTimer be
> called (which is supposed to "prepare" things for the **next** frame)
> with a relatively consistently increasing value?  (ie. 0, 16, 32, 48, 64
> ms) instead of what I'm seeing now (0, 30, 33, 60, 66 ms).  Assuming
> that the animation will simply be visible on the next frame, then my
> calculations using this fluctuating timer are going to be quite jittery
> when put on a screen that refreshes at exactly 60 fps.  My animation
> calculations would look like:
>
>      |------|-|------|-|--------|-|------|-|--
>
> While being displayed on a screen that does this:
>
>      |---|---|---|---|---|---|---|---|---|---
>
> I compared the values I receive from `handle(long)` with
> `System.nanoTime()` and found no significant differences between them;
> in other words, the actual calling code is already quite a jittery process.
>
> So I dug a bit deeper -- internally, a subclass of Timer is used (in my
> case WinTimer, the Windows one).  Assuming that the problem stemmed from
> there, I replaced this with a **highly** accurate timer that simply busy
> waits until the appropriate frame time is reached.  The accuracy of this
> is almost nanosecond perfect (ie, within 0.000001 of a millisecond, at
> the cost of a CPU core of course, but that's not relevant for the
> problem).  This however had 0 impact on the accuracy of the
> AnimationTimer -- it was still fluctuating wildly, on the order of 20-30
> milliseconds (several million times less accurate than my Timer
> implementation).
>
> Digging further, the AnimationTimer is not actually called directly from
> the timing thread (which is a different thread than the FX thread, so
> that makes sense).  Instead, the timer is called from the FX thread by
> having my highly accurate timer call Application::invokeLater (similar
> to Platform::runLater).  Once the FX thread picks up this task, it calls
> `System.nanoTime()` as a "base" for all AnimationTimer callbacks...
> however, this value is now distorted by how long it takes the scheduler
> to wake up the FX thread and pick up the invokeLater task.
>
> I find this highly surprising.  To make jitter free animations, you want
> a base time that increments consistently, and maybe sometimes skips a
> frame.  So you'd expect the base time value to increment with 1 /
> frameRate, not some arbitrary time for when the work was started
> (fluctuating with thread scheduling delays).  I mean, I'm preparing
> things for the **next** frame, so the time I receive should reflect when
> that frame is likely to be drawn, not roughly be the same time my method
> is actually being called (if I wanted that, I can
> call `System.nanoTime()` myself...).
>
> I feel this is actually a bug.  It is probably a bit worse on the
> Windows platform where the scheduler generally has a 15 ms period (which
> explains the fluctuations I'm seeing between 0 and 30 ms). However, this
> really shouldn't matter.  When doing animations, you want to call not
> with the current system time, but with the expected render time of the
> next frame.  Calling `System.nanoTime` and using that as base time is
> just simply incorrect, although can be "close" to correct if your
> platform schedules say with a 1 ms period (it will only fluctuate
> between 0 and 2 ms then).
>
> There should however be 0 fluctuation, unless a frame was skipped.  With
> a 60 fps frame rate, all the nano values passed to AnimationTimer should
> be multiples of 16,666,666 ns.
>
> Let me know what you think, perhaps I'm missing something here.
>
> --John
>
> PS. I think it is possible to do the pulse waiting on the FX thread
> itself; the FX thread can be interrupted when a Platform::runLater call
> comes in, but at all other times it can just wait for the next pulse
> directly on that thread.  With my highly accurate timer implementation
> (I made another variant that is accurate to within a few tenths of a
> milliseconds without busy waiting) Animation code would be called much
> faster, so it would have more time run before the next frame is
> displayed... at it is now, at least on Windows, the AnimationTimer can
> get called just a few milliseconds before the next frame is displayed,
> leaving precious little time to do any kind of calculations.
>
>

From kcr at openjdk.org  Thu Aug 29 16:32:30 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 16:32:30 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
 [v2]
In-Reply-To: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
Message-ID: <TSUtYm0Ky2AaR6V_ZRGpX9P8DBFqD69ga-RYBQVHj9c=.93f0819c-248d-460f-8183-7242ba697ddc@github.com>

On Thu, 29 Aug 2024 14:43:39 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
>> from:
>>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> to:
>>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> Please review.
>> 
>> Regards,
>> Anupam
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated verification-metadata.xml. Added sha256 for Linux /aarch64 jar

The checksum you added looks correct (it matches the one I get when I download it). I still want to run one more test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2318302150

From kcr at openjdk.org  Thu Aug 29 17:11:23 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 17:11:23 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
 [v2]
In-Reply-To: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
Message-ID: <LhjfPvnnQk4i0RNC-aGIynyFM5EGo_81zW3JgU6uxGA=.27921e62-7038-4de3-aa44-982db8b90737@github.com>

On Thu, 29 Aug 2024 14:43:39 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
>> from:
>>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> to:
>>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> Please review.
>> 
>> Regards,
>> Anupam
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated verification-metadata.xml. Added sha256 for Linux /aarch64 jar

I pulled the PR branch, then locally edited `build.gradle` to download the new linux_aarch64 artifact on the platform I was building on (it happened to be Windows, but whatever platform you have will work). It worked, meaning the entry you added to `gradle/verification.xml` was good.

Btw, I filed the following bug to add a GHA build for Linux / aarch64, similar to what I recently did for macOS / aarch64:

[JDK-8339270](https://bugs.openjdk.org/browse/JDK-8339270): GHA: build on Linux / aarch64

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1549#pullrequestreview-2269557474

From kcr at openjdk.org  Thu Aug 29 17:15:21 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 17:15:21 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
Message-ID: <lHK1gUeJhUHJXrWQDij0VcL5uiNe7clJIBr4MKdtlDU=.a9a0f81a-43fc-483b-b7ba-b547a5be2a6d@github.com>

On Thu, 29 Aug 2024 14:11:01 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Reviewers: @arapte  @HimaBinduMeda

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

PR Comment: https://git.openjdk.org/jfx/pull/1551#issuecomment-2318409284

From duke at openjdk.org  Thu Aug 29 18:18:35 2024
From: duke at openjdk.org (duke)
Date: Thu, 29 Aug 2024 18:18:35 GMT
Subject: Withdrawn: 8242616: Regression: RTL - TextField Cursor Movement Via
 Keyboard
In-Reply-To: <HOsUqndcEAm2fFm-RTGw64ugdo1dHpj-vm6GH3Sc6sg=.116e8ab4-5292-4fad-97ad-edb7ab2f50eb@github.com>
References: <HOsUqndcEAm2fFm-RTGw64ugdo1dHpj-vm6GH3Sc6sg=.116e8ab4-5292-4fad-97ad-edb7ab2f50eb@github.com>
Message-ID: <oVPj12o4-sbZhYM07WRUcXvh21Yx8xXWRX-TJFm8NtE=.7b6072e4-ebb6-41df-a48a-dbf4c74dd5d1@github.com>

On Fri, 25 Aug 2023 11:41:22 GMT, Karthik P K <kpk at openjdk.org> wrote:

> The old logic for cursor movement was buggy when both RTL and LTR text was present in the TextField. Used character BreakIterator instead of finding the character index using hitTest.
> 
> Added system test to validate the fix.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jfx/pull/1222

From john.hendrikx at gmail.com  Thu Aug 29 18:19:56 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 29 Aug 2024 20:19:56 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
 <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
Message-ID: <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>

I think they're a bit separate.? Even with VSync, the time it takes to 
kick the FX thread in action is still going to be between 0-30ms.? If it 
then passes `System.nanoTime()` to the AnimationRunnables, you're 
basically saying that they should render a frame at the precise time of 
VSync-Time + random time it took to schedule the FX thread... suffice to 
say that the extra accuracy of the more accurate VSync timer (just like 
my far more accurate timer) is made completely redundant by the jitter 
introduced by the scheduler.

This brings me back to my original point: we should not be passing 
`System.nanoTime()` to AnimationRunnables.? Passing `System.nanoTime()` 
is basically asking to create a frame with a time index that will NEVER 
be rendered, so why are we asking Animations to use this value for 
calculating animation locations/offsets/sizes ?

This problem is also present on Mac and Linux, just less noticeable 
because their schedulers generally react within 0-2 ms (vs 0-30 ms on 
Windows).? 2 ms is "close enough" to the most commonly used frame rates 
(60 fps, at 16.667 ms per frame), but on Windows it can practically be a 
two frame difference.

Even in the absence of V-sync, when JavaFX arbitrarily picks 60 Hz as 
its refresh frequency, the times passed to AnimationTimer should be 
multiples of 16.667 ms, not 16.667 ms + however long it took to wake up 
the FX thread.? In other words this code in AbstactPrimaryTimer:

privatelongnextPulseTime= nanos();

privatelonglastPulseDuration= Integer.MIN_VALUE;

@Override

publicvoidrun() {

if(paused) {

return;

}

finallongnow = nanos();

recordStart((nextPulseTime- now) / 1000000);

timePulseImpl(now);

recordEnd();

updateNextPulseTime(now);

// reschedule animation runnable if needed

updateAnimationRunnable();

}

...would be far better if it passed "nextPulseTime" to `timePulseImpl` 
(which eventually calls the AnimationRunnables) instead of "now".

Note: this is assuming the adaptive pulse flag is disabled.? If it is 
enabled, nextPulseTime won't be a nice multiple of the frame rate -- so 
when this is enabled we may want to round it up/down before passing it 
to the AnimationRunnables.

Note 2: you can **already** achieve far smoother animation even on 
Windows by rounding the value you get passed in to a multiple of 
1/frameRate. This only works when you have access to the this time. It 
won't solve Timeline calculations -- they will still calculate positions 
and values for frames that will never exist, subject to FX thread 
scheduling jitter...

--John


On 29/08/2024 18:18, Michael Strau? wrote:
> The entire idea of using a system timer in the presence of v-sync is
> wrong, it simply can't work reliably. We get accurate frame
> synchronization for free from Direct3D, we should use that instead of
> system timers.
>
> There's a JBS issue with a detailed analysis:
> https://bugs.openjdk.org/browse/JDK-8136536
>
>
> On Thu, Aug 29, 2024 at 5:40?PM John Hendrikx<john.hendrikx at gmail.com>  wrote:
>> TLDR; AnimationTimer is being fed a time not based on the time the next
>> frame is expected to be rendered but the time of when the FX thread is
>> finally scheduled to do the callbacks.  This time fluctuates wildly, and
>> is a time that's useless for doing frame accurate calculations of
>> animations (such a time shouldn't fluctuate at all, unless a frame gets
>> skipped).
>>
>> Longer version:
>>
>> I've been investigating an "issue" with AnimationTimers.
>>
>> Timers have a `void handle(long)` method that is called with a time in
>> nano seconds that is supposed to be the reference value to be used for
>> animations. The reference value is used to calculate in the
>> implementation how the animation should look at a specific point in time.
>>
>> However, I've found that the values being received by the AnimationTimer
>> fluctuate wildly, and the differences between the current and previous
>> calls of the time passed to the handle method can be anywhere from 1ms
>> to 30ms.
>>
>> The frequency of the calls is however still close to 60 fps -- now,
>> correct me if I'm wrong, but when drawing animations that are supposed
>> to be displayed on a 60 fps screen, shouldn't the AnimationTimer be
>> called (which is supposed to "prepare" things for the **next** frame)
>> with a relatively consistently increasing value?  (ie. 0, 16, 32, 48, 64
>> ms) instead of what I'm seeing now (0, 30, 33, 60, 66 ms).  Assuming
>> that the animation will simply be visible on the next frame, then my
>> calculations using this fluctuating timer are going to be quite jittery
>> when put on a screen that refreshes at exactly 60 fps.  My animation
>> calculations would look like:
>>
>>       |------|-|------|-|--------|-|------|-|--
>>
>> While being displayed on a screen that does this:
>>
>>       |---|---|---|---|---|---|---|---|---|---
>>
>> I compared the values I receive from `handle(long)` with
>> `System.nanoTime()` and found no significant differences between them;
>> in other words, the actual calling code is already quite a jittery process.
>>
>> So I dug a bit deeper -- internally, a subclass of Timer is used (in my
>> case WinTimer, the Windows one).  Assuming that the problem stemmed from
>> there, I replaced this with a **highly** accurate timer that simply busy
>> waits until the appropriate frame time is reached.  The accuracy of this
>> is almost nanosecond perfect (ie, within 0.000001 of a millisecond, at
>> the cost of a CPU core of course, but that's not relevant for the
>> problem).  This however had 0 impact on the accuracy of the
>> AnimationTimer -- it was still fluctuating wildly, on the order of 20-30
>> milliseconds (several million times less accurate than my Timer
>> implementation).
>>
>> Digging further, the AnimationTimer is not actually called directly from
>> the timing thread (which is a different thread than the FX thread, so
>> that makes sense).  Instead, the timer is called from the FX thread by
>> having my highly accurate timer call Application::invokeLater (similar
>> to Platform::runLater).  Once the FX thread picks up this task, it calls
>> `System.nanoTime()` as a "base" for all AnimationTimer callbacks...
>> however, this value is now distorted by how long it takes the scheduler
>> to wake up the FX thread and pick up the invokeLater task.
>>
>> I find this highly surprising.  To make jitter free animations, you want
>> a base time that increments consistently, and maybe sometimes skips a
>> frame.  So you'd expect the base time value to increment with 1 /
>> frameRate, not some arbitrary time for when the work was started
>> (fluctuating with thread scheduling delays).  I mean, I'm preparing
>> things for the **next** frame, so the time I receive should reflect when
>> that frame is likely to be drawn, not roughly be the same time my method
>> is actually being called (if I wanted that, I can
>> call `System.nanoTime()` myself...).
>>
>> I feel this is actually a bug.  It is probably a bit worse on the
>> Windows platform where the scheduler generally has a 15 ms period (which
>> explains the fluctuations I'm seeing between 0 and 30 ms). However, this
>> really shouldn't matter.  When doing animations, you want to call not
>> with the current system time, but with the expected render time of the
>> next frame.  Calling `System.nanoTime` and using that as base time is
>> just simply incorrect, although can be "close" to correct if your
>> platform schedules say with a 1 ms period (it will only fluctuate
>> between 0 and 2 ms then).
>>
>> There should however be 0 fluctuation, unless a frame was skipped.  With
>> a 60 fps frame rate, all the nano values passed to AnimationTimer should
>> be multiples of 16,666,666 ns.
>>
>> Let me know what you think, perhaps I'm missing something here.
>>
>> --John
>>
>> PS. I think it is possible to do the pulse waiting on the FX thread
>> itself; the FX thread can be interrupted when a Platform::runLater call
>> comes in, but at all other times it can just wait for the next pulse
>> directly on that thread.  With my highly accurate timer implementation
>> (I made another variant that is accurate to within a few tenths of a
>> milliseconds without busy waiting) Animation code would be called much
>> faster, so it would have more time run before the next frame is
>> displayed... at it is now, at least on Windows, the AnimationTimer can
>> get called just a few milliseconds before the next frame is displayed,
>> leaving precious little time to do any kind of calculations.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240829/b7e4daba/attachment-0001.htm>

From michaelstrau2 at gmail.com  Thu Aug 29 18:45:07 2024
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 29 Aug 2024 20:45:07 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
 <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
 <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>
Message-ID: <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>

Yes, that makes sense. In any case, we shouldn't be using a system
timer, but simply record the timestamp at v-sync, and then pass this
precise timestamp to all AnimationTimers. It shouldn't matter when
AnimationTimers are invoked between frames, as long as the timestamp
corresponds to the v-sync signal. (Well, unless the timer callback
measures its own time, which it shouldn't do.)


On Thu, Aug 29, 2024 at 8:20?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> I think they're a bit separate.  Even with VSync, the time it takes to kick the FX thread in action is still going to be between 0-30ms.  If it then passes `System.nanoTime()` to the AnimationRunnables, you're basically saying that they should render a frame at the precise time of VSync-Time + random time it took to schedule the FX thread... suffice to say that the extra accuracy of the more accurate VSync timer (just like my far more accurate timer) is made completely redundant by the jitter introduced by the scheduler.
>
> This brings me back to my original point: we should not be passing `System.nanoTime()` to AnimationRunnables.  Passing `System.nanoTime()` is basically asking to create a frame with a time index that will NEVER be rendered, so why are we asking Animations to use this value for calculating animation locations/offsets/sizes ?
>
> This problem is also present on Mac and Linux, just less noticeable because their schedulers generally react within 0-2 ms (vs 0-30 ms on Windows).  2 ms is "close enough" to the most commonly used frame rates (60 fps, at 16.667 ms per frame), but on Windows it can practically be a two frame difference.
>
> Even in the absence of V-sync, when JavaFX arbitrarily picks 60 Hz as its refresh frequency, the times passed to AnimationTimer should be multiples of 16.667 ms, not 16.667 ms + however long it took to wake up the FX thread.  In other words this code in AbstactPrimaryTimer:
>
> private long nextPulseTime = nanos();
>
> private long lastPulseDuration = Integer.MIN_VALUE;
>
> @Override
>
> public void run() {
>
> if (paused) {
>
> return;
>
> }
>
> final long now = nanos();
>
> recordStart((nextPulseTime - now) / 1000000);
>
> timePulseImpl(now);
>
> recordEnd();
>
> updateNextPulseTime(now);
>
> // reschedule animation runnable if needed
>
> updateAnimationRunnable();
>
> }
>
> ...would be far better if it passed "nextPulseTime" to `timePulseImpl` (which eventually calls the AnimationRunnables) instead of "now".
>
> Note: this is assuming the adaptive pulse flag is disabled.  If it is enabled, nextPulseTime won't be a nice multiple of the frame rate -- so when this is enabled we may want to round it up/down before passing it to the AnimationRunnables.
>
> Note 2: you can **already** achieve far smoother animation even on Windows by rounding the value you get passed in to a multiple of 1/frameRate. This only works when you have access to the this time. It won't solve Timeline calculations -- they will still calculate positions and values for frames that will never exist, subject to FX thread scheduling jitter...
>
> --John

From andy.goryachev at oracle.com  Thu Aug 29 18:53:01 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 29 Aug 2024 18:53:01 +0000
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
 <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
 <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>
 <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>
Message-ID: <BL3PR10MB618523CFFAEA59ADD73C600FE5962@BL3PR10MB6185.namprd10.prod.outlook.com>

This might be slightly off-topic, but I noticed that instead of computing 'now' time for AnimationTimer.handle(long) just before calling the actual handler, we do compute it once before sending to possibly multiple handlers.  Each subsequent invocation produces progressively larger discrepancy (AbstractPrimaryTimer:264).

Does not explain the issue John raised though.

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Thursday, August 29, 2024 at 11:45
To:
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Bug: Times passed to AnimationTimer should not fluctuate
Yes, that makes sense. In any case, we shouldn't be using a system
timer, but simply record the timestamp at v-sync, and then pass this
precise timestamp to all AnimationTimers. It shouldn't matter when
AnimationTimers are invoked between frames, as long as the timestamp
corresponds to the v-sync signal. (Well, unless the timer callback
measures its own time, which it shouldn't do.)


On Thu, Aug 29, 2024 at 8:20?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> I think they're a bit separate.  Even with VSync, the time it takes to kick the FX thread in action is still going to be between 0-30ms.  If it then passes `System.nanoTime()` to the AnimationRunnables, you're basically saying that they should render a frame at the precise time of VSync-Time + random time it took to schedule the FX thread... suffice to say that the extra accuracy of the more accurate VSync timer (just like my far more accurate timer) is made completely redundant by the jitter introduced by the scheduler.
>
> This brings me back to my original point: we should not be passing `System.nanoTime()` to AnimationRunnables.  Passing `System.nanoTime()` is basically asking to create a frame with a time index that will NEVER be rendered, so why are we asking Animations to use this value for calculating animation locations/offsets/sizes ?
>
> This problem is also present on Mac and Linux, just less noticeable because their schedulers generally react within 0-2 ms (vs 0-30 ms on Windows).  2 ms is "close enough" to the most commonly used frame rates (60 fps, at 16.667 ms per frame), but on Windows it can practically be a two frame difference.
>
> Even in the absence of V-sync, when JavaFX arbitrarily picks 60 Hz as its refresh frequency, the times passed to AnimationTimer should be multiples of 16.667 ms, not 16.667 ms + however long it took to wake up the FX thread.  In other words this code in AbstactPrimaryTimer:
>
> private long nextPulseTime = nanos();
>
> private long lastPulseDuration = Integer.MIN_VALUE;
>
> @Override
>
> public void run() {
>
> if (paused) {
>
> return;
>
> }
>
> final long now = nanos();
>
> recordStart((nextPulseTime - now) / 1000000);
>
> timePulseImpl(now);
>
> recordEnd();
>
> updateNextPulseTime(now);
>
> // reschedule animation runnable if needed
>
> updateAnimationRunnable();
>
> }
>
> ...would be far better if it passed "nextPulseTime" to `timePulseImpl` (which eventually calls the AnimationRunnables) instead of "now".
>
> Note: this is assuming the adaptive pulse flag is disabled.  If it is enabled, nextPulseTime won't be a nice multiple of the frame rate -- so when this is enabled we may want to round it up/down before passing it to the AnimationRunnables.
>
> Note 2: you can **already** achieve far smoother animation even on Windows by rounding the value you get passed in to a multiple of 1/frameRate. This only works when you have access to the this time. It won't solve Timeline calculations -- they will still calculate positions and values for frames that will never exist, subject to FX thread scheduling jitter...
>
> --John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240829/16370166/attachment-0001.htm>

From angorya at openjdk.org  Thu Aug 29 19:49:49 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 Aug 2024 19:49:49 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6]
In-Reply-To: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
Message-ID: <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>

> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
> 
> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
> 
> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
> 
> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
> 
> **References**
> 
> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374

Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:

 - improved vertical scrolling
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - cleanup
 - navigation
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - update + review comments
 - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
 - whitespace
 - 8301121: RichTextArea Control (Incubator)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1524/files
  - new: https://git.openjdk.org/jfx/pull/1524/files/09a1637c..e035c166

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=04-05

  Stats: 26362 lines in 566 files changed: 14023 ins; 7061 del; 5278 mod
  Patch: https://git.openjdk.org/jfx/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524

PR: https://git.openjdk.org/jfx/pull/1524

From almatvee at openjdk.org  Thu Aug 29 21:07:33 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 29 Aug 2024 21:07:33 GMT
Subject: RFR: 8338701: Provide media support for libavcodec version 61
Message-ID: <Bb4ePyRPKhnscUyckfHrg1COzc_wu-LI-KIIYnhspnU=.3d4e6679-ac06-49fd-af21-730cac3d7fa2@github.com>

- Added support for libavcodec 61.
- Updated AV plugins to use new APIs instead of APIs which were removed in 61.
- We still using some deprecated APIs.
- `reordered_opaque` replacement exist in 61 which is used to pass user data between compressed frame and uncompressed. In 61 this variable is pointer to `void` instead of `int64_t`. We can use new `opaque` to pass PTS, but it is not documented way to pass PTS between compressed and uncompressed frames. Updated code will be using `AVPacket.pts/AVFrame.pts` which is documented way to provide PTS.
- Tested on Ubuntu 24.10 with 61 and 24.04 with 60 with all supported formats.

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

Commit messages:
 - 8338701: Provide media support for libavcodec version 61

Changes: https://git.openjdk.org/jfx/pull/1552/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1552&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338701
  Stats: 56 lines in 6 files changed: 45 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1552.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1552/head:pull/1552

PR: https://git.openjdk.org/jfx/pull/1552

From angorya at openjdk.org  Thu Aug 29 21:29:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 Aug 2024 21:29:23 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
Message-ID: <8MSRDQ3onZQeSScmjnWvAtV6rK09Pt4xD8qE4FL6JoQ=.275d2051-d439-4619-beb5-546f00fb15ce@github.com>

On Tue, 27 Aug 2024 20:21:43 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp line 1032:

> 1030:             platformContext()->rq().freeSpace(32)
> 1031:             << (jint)com_sun_webkit_graphics_GraphicsDecoder_SETSHADOW
> 1032:             << clr << clr << clr << clr << clr << clr << clr;;

is there an extra ; here ?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737223092

From kcr at openjdk.org  Thu Aug 29 21:50:24 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 21:50:24 GMT
Subject: RFR: 8338701: Provide media support for libavcodec version 61
In-Reply-To: <Bb4ePyRPKhnscUyckfHrg1COzc_wu-LI-KIIYnhspnU=.3d4e6679-ac06-49fd-af21-730cac3d7fa2@github.com>
References: <Bb4ePyRPKhnscUyckfHrg1COzc_wu-LI-KIIYnhspnU=.3d4e6679-ac06-49fd-af21-730cac3d7fa2@github.com>
Message-ID: <GEsczAAYyZy6RlHnu_rAQi_VktHU71N5ZTBhq2_87FU=.b773b755-b14b-49c5-8aeb-26af475af80f@github.com>

On Thu, 29 Aug 2024 21:02:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for libavcodec 61.
> - Updated AV plugins to use new APIs instead of APIs which were removed in 61.
> - We still using some deprecated APIs.
> - `reordered_opaque` replacement exist in 61 which is used to pass user data between compressed frame and uncompressed. In 61 this variable is pointer to `void` instead of `int64_t`. We can use new `opaque` to pass PTS, but it is not documented way to pass PTS between compressed and uncompressed frames. Updated code will be using `AVPacket.pts/AVFrame.pts` which is documented way to provide PTS.
> - Tested on Ubuntu 24.10 with 61 and 24.04 with 60 with all supported formats.

Reviewers: @arapte @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1552#issuecomment-2319087597

From kcr at openjdk.org  Thu Aug 29 22:08:27 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 22:08:27 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
Message-ID: <F9TCp_42IOX-qbPMLXWS1Il__TXEv9cio3O_S_rMJT4=.c0426817-ed49-4a6d-974d-d8e0ffca75ed@github.com>

On Tue, 27 Aug 2024 20:21:43 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

The fix looks good. I verified it with the test program attached to the bug report. I also confirm that the newly added test fails without the fix and passes with the fix.

I left a few mostly minor comments on the test.

modules/javafx.web/src/test/java/test/javafx/scene/web/ShadowTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

That should be 2024.

modules/javafx.web/src/test/java/test/javafx/scene/web/ShadowTest.java line 37:

> 35: import java.awt.image.BufferedImage;
> 36: import java.io.File;
> 37: import java.io.IOException;

These last two are unused imports, along with ImageIO above.

modules/javafx.web/src/test/java/test/javafx/scene/web/ShadowTest.java line 66:

> 64:                 int noShadowCnt = 0;
> 65:                 for(int x = 0; x < 100; x++){
> 66:                     for(int y = 0; y < 200; y++){

Minor: there should be a space after the `if` and before the `{`.

modules/javafx.web/src/test/java/test/javafx/scene/web/ShadowTest.java line 69:

> 67:                         Color pixelColor = new Color(img.getRGB(x, y), true);
> 68:                         if(isColorsSimilar(Color.RED, pixelColor, 1)){
> 69:                             if(y < 100){

Minor: there should be a space after the `if` and before the `{`.

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

PR Review: https://git.openjdk.org/jfx/pull/1547#pullrequestreview-2270312577
PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737263898
PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737266019
PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737267170
PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737267643

From kcr at openjdk.org  Thu Aug 29 22:08:28 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 22:08:28 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <8MSRDQ3onZQeSScmjnWvAtV6rK09Pt4xD8qE4FL6JoQ=.275d2051-d439-4619-beb5-546f00fb15ce@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
 <8MSRDQ3onZQeSScmjnWvAtV6rK09Pt4xD8qE4FL6JoQ=.275d2051-d439-4619-beb5-546f00fb15ce@github.com>
Message-ID: <eET9Mu945tQL8zibn07x7A73zTJ0pY1F0QTlxS2Nis8=.912385ac-20b1-46d2-a5bf-560c09a45c16@github.com>

On Thu, 29 Aug 2024 21:27:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp line 1032:
> 
>> 1030:             platformContext()->rq().freeSpace(32)
>> 1031:             << (jint)com_sun_webkit_graphics_GraphicsDecoder_SETSHADOW
>> 1032:             << clr << clr << clr << clr << clr << clr << clr;;
> 
> is there an extra ; here ?

Looks like it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737263607

From john.hendrikx at gmail.com  Thu Aug 29 22:34:11 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 30 Aug 2024 00:34:11 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <BL3PR10MB618523CFFAEA59ADD73C600FE5962@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
 <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
 <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>
 <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>
 <BL3PR10MB618523CFFAEA59ADD73C600FE5962@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <dd8f4f08-7e75-45ec-a280-ebc967f48184@gmail.com>

It's a constant value for all handler invocations for a given frame, I 
think that part is correct.? It should not matter that a later handler 
is doing its calculations for the next frame at a different point in 
real time; it would still be doing calculations for the next frame, and 
as long as it completes those before the next frame is rendered it will 
be "on time".

So if I have two handlers, A and B, and A is called at (real) time X, 
and B is called at (real) time X + 200 ns, they both should get a "now" 
value that corresponds to the next frame to be rendered -- this doesn't 
have to be derived from System.nanoTime at all.? It only needs to start 
at some value and be incremented for each frame rendered (including 
missed frames).? AnimationTimer is not documented to say that?the value 
is derived from nanoTime -- it is just happenstance that the value 
currently used corresponds closely to System.nanoTime.

--John

On 29/08/2024 20:53, Andy Goryachev wrote:
>
> This might be slightly off-topic, but I noticed that instead of 
> computing 'now' time for AnimationTimer.handle(long) just before 
> calling the actual handler, we do compute it once before sending to 
> possibly multiple handlers.? Each subsequent invocation produces 
> progressively larger discrepancy (AbstractPrimaryTimer:264).
>
> Does not explain the issue John raised though.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Thursday, August 29, 2024 at 11:45
> *To: *
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Bug: Times passed to AnimationTimer should not fluctuate
>
> Yes, that makes sense. In any case, we shouldn't be using a system
> timer, but simply record the timestamp at v-sync, and then pass this
> precise timestamp to all AnimationTimers. It shouldn't matter when
> AnimationTimers are invoked between frames, as long as the timestamp
> corresponds to the v-sync signal. (Well, unless the timer callback
> measures its own time, which it shouldn't do.)
>
>
> On Thu, Aug 29, 2024 at 8:20?PM John Hendrikx 
> <john.hendrikx at gmail.com> wrote:
> >
> > I think they're a bit separate.? Even with VSync, the time it takes 
> to kick the FX thread in action is still going to be between 0-30ms.? 
> If it then passes `System.nanoTime()` to the AnimationRunnables, 
> you're basically saying that they should render a frame at the precise 
> time of VSync-Time + random time it took to schedule the FX thread... 
> suffice to say that the extra accuracy of the more accurate VSync 
> timer (just like my far more accurate timer) is made completely 
> redundant by the jitter introduced by the scheduler.
> >
> > This brings me back to my original point: we should not be passing 
> `System.nanoTime()` to AnimationRunnables.? Passing 
> `System.nanoTime()` is basically asking to create a frame with a time 
> index that will NEVER be rendered, so why are we asking Animations to 
> use this value for calculating animation locations/offsets/sizes ?
> >
> > This problem is also present on Mac and Linux, just less noticeable 
> because their schedulers generally react within 0-2 ms (vs 0-30 ms on 
> Windows).? 2 ms is "close enough" to the most commonly used frame 
> rates (60 fps, at 16.667 ms per frame), but on Windows it can 
> practically be a two frame difference.
> >
> > Even in the absence of V-sync, when JavaFX arbitrarily picks 60 Hz 
> as its refresh frequency, the times passed to AnimationTimer should be 
> multiples of 16.667 ms, not 16.667 ms + however long it took to wake 
> up the FX thread.? In other words this code in AbstactPrimaryTimer:
> >
> > private long nextPulseTime = nanos();
> >
> > private long lastPulseDuration = Integer.MIN_VALUE;
> >
> > @Override
> >
> > public void run() {
> >
> > if (paused) {
> >
> > return;
> >
> > }
> >
> > final long now = nanos();
> >
> > recordStart((nextPulseTime - now) / 1000000);
> >
> > timePulseImpl(now);
> >
> > recordEnd();
> >
> > updateNextPulseTime(now);
> >
> > // reschedule animation runnable if needed
> >
> > updateAnimationRunnable();
> >
> > }
> >
> > ...would be far better if it passed "nextPulseTime" to 
> `timePulseImpl` (which eventually calls the AnimationRunnables) 
> instead of "now".
> >
> > Note: this is assuming the adaptive pulse flag is disabled.? If it 
> is enabled, nextPulseTime won't be a nice multiple of the frame rate 
> -- so when this is enabled we may want to round it up/down before 
> passing it to the AnimationRunnables.
> >
> > Note 2: you can **already** achieve far smoother animation even on 
> Windows by rounding the value you get passed in to a multiple of 
> 1/frameRate. This only works when you have access to the this time. It 
> won't solve Timeline calculations -- they will still calculate 
> positions and values for frames that will never exist, subject to FX 
> thread scheduling jitter...
> >
> > --John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/ab6dbb2a/attachment-0001.htm>

From kcr at openjdk.org  Thu Aug 29 22:35:25 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 22:35:25 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v2]
In-Reply-To: <F9TCp_42IOX-qbPMLXWS1Il__TXEv9cio3O_S_rMJT4=.c0426817-ed49-4a6d-974d-d8e0ffca75ed@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <vMXRMvVzO6OWZo_70N3maeukj2p-pZy7rfjSPZOz_lU=.1640ef3c-eee4-485b-8ce6-c7166b9fe953@github.com>
 <F9TCp_42IOX-qbPMLXWS1Il__TXEv9cio3O_S_rMJT4=.c0426817-ed49-4a6d-974d-d8e0ffca75ed@github.com>
Message-ID: <1z8cB3Eh6pknzv7l52HgGgDsoHVrjfAmzuNkJncKenQ=.1df563b5-11a7-41b8-befe-f9431dcdfc5c@github.com>

On Thu, 29 Aug 2024 22:04:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> modules/javafx.web/src/test/java/test/javafx/scene/web/ShadowTest.java line 66:
> 
>> 64:                 int noShadowCnt = 0;
>> 65:                 for(int x = 0; x < 100; x++){
>> 66:                     for(int y = 0; y < 200; y++){
> 
> Minor: there should be a space after the `if` and before the `{`.

I meant after the `for` ...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1547#discussion_r1737294809

From kcr at openjdk.org  Thu Aug 29 22:40:23 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Aug 2024 22:40:23 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
Message-ID: <aBX8URKp8VWlZFEYi2uyW1MQzD6Uuu53_WQpLznFwzw=.01e61fc3-b1e1-4c04-8068-ee938e872b0a@github.com>

On Thu, 29 Aug 2024 14:11:01 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

The fix looks reasonable to me, but I'll let @arapte be the primary reviewer, so this isn't a formal review.

I was testing #1547 anyway, so I created a test branch with both that fix and this one merged together and ran it through our CI system. I confirm that the newly added test for _this_ PR fails without the fix and passes with the fix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1551#issuecomment-2319182764

From john.hendrikx at gmail.com  Thu Aug 29 22:50:05 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 30 Aug 2024 00:50:05 +0200
Subject: Bug: Times passed to AnimationTimer should not fluctuate
In-Reply-To: <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>
References: <7da7dba9-8912-46b9-8913-a17111c3a45b@gmail.com>
 <CAJEpuXTN1AC3_rd9FEWEX8RqEzx_6=U_HhpWWyR9Gqsea8N3qQ@mail.gmail.com>
 <325ea502-c7b9-48ae-a357-7fa9b277c54a@gmail.com>
 <CAJEpuXQ4uRZ1s12rOc0gk=0FNb3HGmV2P3zeMbT=vxasqt-NNA@mail.gmail.com>
Message-ID: <110a5863-f446-4a17-b708-df5f9de50192@gmail.com>


On 29/08/2024 20:45, Michael Strau? wrote:
> Yes, that makes sense. In any case, we shouldn't be using a system
> timer, but simply record the timestamp at v-sync, and then pass this
> precise timestamp to all AnimationTimers. It shouldn't matter when

Yeah, I still think however that this is not entirely correct either.? I 
mean, when I'm determining the position of say a bouncing ball at 60 
fps, then the frame times will be fixed numbers known in advance.? 
Recording a precise time does not help my calculations here.? I mean, we 
know the frames will be displayed at:

 ?????? frame #0 at 0 ns
 ?????? frame #1 at 16,666,666 ns
 ?????? frame #2 at 33,333,332 ns
 ?????? ...

With a precise time recorded after VSync, that would become:

 ?????? frame #0 at 0 ns + small random ns value
 ?????? frame #1 at 16,666,666 ns + small random ns value
 ?????? frame #2 at 33,333,332 ns + small random ns value
 ?????? ...

There's no point in doing so, and it will subtly change the calculation 
of where the bouncing ball should be on screen (although admittedly, 
such a small ns difference won't matter, unlike the thread scheduling 
differences which are on the order of milliseconds).

Perhaps however this is the best achievable, given that even if we know 
something is 60 fps, it might in reality be 60.00002 fps, or maybe in 
reality it fluctuates slightly.? Having said that, perhaps it would be 
even better to round the value to some arbitrary precision so Animation 
code doesn't see meaningless random low order bits at all.

--John

PS. I think the issue you linked also made a small comment regarding 
this specific problem. They said this:

 > Also under the hood animation frame timestamp deltas are still weird 
(more than half of timestamp deltas are greater than 17ms). It can (and 
does) miss vsync here and there. On weak devices even increasing pulse 
frequency can not eliminate the issue completely and loads on CPU.

I think this is about the times received by AnimationTimer or the times 
used by Animation/Timeline -- these would be subject to the thread 
scheduling jitter.

So it looks like this is two separate problems.? Where the issue you 
linked is about an increasing error which will cause a jitter every X 
frames, my issue (on Windows) is a constant jitter (due to 
miscalculation by supplying a bad time value) that happens every frame.

> AnimationTimers are invoked between frames, as long as the timestamp
> corresponds to the v-sync signal. (Well, unless the timer callback
> measures its own time, which it shouldn't do.)
>
>
> On Thu, Aug 29, 2024 at 8:20?PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>> I think they're a bit separate.  Even with VSync, the time it takes to kick the FX thread in action is still going to be between 0-30ms.  If it then passes `System.nanoTime()` to the AnimationRunnables, you're basically saying that they should render a frame at the precise time of VSync-Time + random time it took to schedule the FX thread... suffice to say that the extra accuracy of the more accurate VSync timer (just like my far more accurate timer) is made completely redundant by the jitter introduced by the scheduler.
>>
>> This brings me back to my original point: we should not be passing `System.nanoTime()` to AnimationRunnables.  Passing `System.nanoTime()` is basically asking to create a frame with a time index that will NEVER be rendered, so why are we asking Animations to use this value for calculating animation locations/offsets/sizes ?
>>
>> This problem is also present on Mac and Linux, just less noticeable because their schedulers generally react within 0-2 ms (vs 0-30 ms on Windows).  2 ms is "close enough" to the most commonly used frame rates (60 fps, at 16.667 ms per frame), but on Windows it can practically be a two frame difference.
>>
>> Even in the absence of V-sync, when JavaFX arbitrarily picks 60 Hz as its refresh frequency, the times passed to AnimationTimer should be multiples of 16.667 ms, not 16.667 ms + however long it took to wake up the FX thread.  In other words this code in AbstactPrimaryTimer:
>>
>> private long nextPulseTime = nanos();
>>
>> private long lastPulseDuration = Integer.MIN_VALUE;
>>
>> @Override
>>
>> public void run() {
>>
>> if (paused) {
>>
>> return;
>>
>> }
>>
>> final long now = nanos();
>>
>> recordStart((nextPulseTime - now) / 1000000);
>>
>> timePulseImpl(now);
>>
>> recordEnd();
>>
>> updateNextPulseTime(now);
>>
>> // reschedule animation runnable if needed
>>
>> updateAnimationRunnable();
>>
>> }
>>
>> ...would be far better if it passed "nextPulseTime" to `timePulseImpl` (which eventually calls the AnimationRunnables) instead of "now".
>>
>> Note: this is assuming the adaptive pulse flag is disabled.  If it is enabled, nextPulseTime won't be a nice multiple of the frame rate -- so when this is enabled we may want to round it up/down before passing it to the AnimationRunnables.
>>
>> Note 2: you can **already** achieve far smoother animation even on Windows by rounding the value you get passed in to a multiple of 1/frameRate. This only works when you have access to the this time. It won't solve Timeline calculations -- they will still calculate positions and values for frames that will never exist, subject to FX thread scheduling jitter...
>>
>> --John

From kneester77 at gmail.com  Fri Aug 30 05:22:39 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Thu, 29 Aug 2024 22:22:39 -0700
Subject: Failing to build JavaFX
Message-ID: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>

Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
-PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
confronted with the following output:

"
> Task :media:buildWinGlib
make: Entering directory
'/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
make TARGET=/libffi.lib -f Makefile.ffi
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
/bin/sh: line 1: cygpath: command not found
make: make: Not a directory
make: *** [Makefile:65: /libffi.lib] Error 127
make: Leaving directory
'/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
"

However, if I immediately run "cygpath", it does run successfully. (See
screenshot below).
I'm not really sure what's going on, but I suspect that either somehow my
WSL installation is getting used by gradle instead (not sure if that's even
possible, but maybe? I don't know enough about how cygwin works), or
something even more difficult to pinpoint is going on.

Can someone help me resolve this issue? I've gotten a bit stuck. Thanks!

[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240829/b47be118/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240829/b47be118/image-0001.png>

From sykora at openjdk.org  Fri Aug 30 07:25:27 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Fri, 30 Aug 2024 07:25:27 GMT
Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64
 [v2]
In-Reply-To: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
References: <NpgLQh8igpTFvNH1jTncWG57oxNXks8wU5y0qeDNj8w=.945b93da-0e23-4b34-936e-e21086c3f222@github.com>
 <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com>
Message-ID: <NBuaUy-7F_5phKHq8UzjF6qBEqIRju0SB-pF8R2wJyA=.ef4a4ecd-46b2-4661-a308-76b1ee401d95@github.com>

On Thu, 29 Aug 2024 14:43:39 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

>> Hi,
>> 
>> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64.
>> from:
>>     IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> to:
>>     IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" :
>>     IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : ""
>> 
>> Please review.
>> 
>> Regards,
>> Anupam
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated verification-metadata.xml. Added sha256 for Linux /aarch64 jar

Build was successful on a linux aarch64 machine.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1549#pullrequestreview-2271415809

From psadhukhan at openjdk.org  Fri Aug 30 08:10:26 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 30 Aug 2024 08:10:26 GMT
Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash [v3]
In-Reply-To: <ZCjqXxOmqo45nnaDfpHqKtOaF6bnNYvOrYqMANW0814=.f9beefa5-01cf-4dd2-a84f-ab1d3e9cb4b8@github.com>
References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com>
 <ZCjqXxOmqo45nnaDfpHqKtOaF6bnNYvOrYqMANW0814=.f9beefa5-01cf-4dd2-a84f-ab1d3e9cb4b8@github.com>
Message-ID: <fXu_NwMAxWo2G1S-xZ6xQ-fXemwrV8W_DBJLHeFEyD4=.0ef55d9f-c6f1-4d90-832c-cb27f2c3966f@github.com>

On Thu, 29 Aug 2024 15:56:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall.
>> 
>> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed.
>> 
>> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR.
>> 
>> Summary of the changes:
>> 
>> * Attach the AppKit thread to the JVM as a daemon
>> * Do not detach the thread when the FX main event loop terminates
>> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts
>> * Terminate the KeepAlive thread when the FX toolkit finishes
>> 
>> Testing:
>> 
>> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1545#pullrequestreview-2271521271

From arapte at openjdk.org  Fri Aug 30 08:26:27 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 30 Aug 2024 08:26:27 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
Message-ID: <1FfixNpaLEZz1x9wJ7gmNfFrbScuvwwfBsSdd6LRboo=.fb37357e-fd61-4a72-9b49-cd1ed81366e7@github.com>

On Thu, 29 Aug 2024 14:11:01 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

The change looks good, For reference the related change in Webkit repo is : https://github.com/WebKit/WebKit/commit/3cab8bc8c7d3f8dc0bad8529df249bc09e6402ec
Provided a few comments that need to be attended.
Verified that test fails without this patch and passes with it.

modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 276:

> 274: }
> 275: 
> 276: String pathFileName(const String& path)

This method is used 2 times in file  `modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm`.
It needs correction. [[1]](https://github.com/openjdk/jfx/blob/a53bc589ac37d490b1406a2b977097a06bf5ac74/modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm#L62), [[2]](https://github.com/openjdk/jfx/blob/a53bc589ac37d490b1406a2b977097a06bf5ac74/modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm#L64)

modules/javafx.web/src/test/java/test/javafx/scene/web/FileTest.java line 94:

> 92:         });
> 93:     }
> 94: }

The test requires a few changes:
1. Correct copyright year
2. Several imports can be removed.
3. method `private State getLoadState()` is unused
4. method `getScriptString()` can be replaced with a string member variable
5. Line 70,71 needs format correction

I tried these changes locally, attaching the file with required changes. Please check
[FileTest.java.zip](https://github.com/user-attachments/files/16813919/FileTest.java.zip)

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1551#pullrequestreview-2271545512
PR Review Comment: https://git.openjdk.org/jfx/pull/1551#discussion_r1738181928
PR Review Comment: https://git.openjdk.org/jfx/pull/1551#discussion_r1738182435

From jpereda at openjdk.org  Fri Aug 30 10:50:28 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 30 Aug 2024 10:50:28 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <qOaCZdVHNbfcdhCVSW7jUpv9183Tj-ug5i8BUTkx5is=.b0eb20bd-413c-42d9-b642-bd81ed22fcf1@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

On Linux, if you use `-Dprism.useFontConfig=false`, but then don't set valid embedded fonts, you get the reported NPE, instead of a different failure, with a more explicit message.
 
But since this property is undocumented, and you indeed need to read the sources to find out about it, you might also discover that setting a fontDir with some fonts and a property file with some properties to use those fonts, will solve the issue and there won't be a NPE anymore.

So I agree that setting this to false, and not supplying fonts is a misconfiguration, but should probably be handled better, with a more explicit message or fast failure.

On Android, however, the situation is different: `fontpath_linux.c`(with the native implementation of `FontConfigManager::getFontConfig`) is not used, but `FTFactory::getFallbacks` calls it nonetheless. 

Using `-Dprism.useFontConfig=false` prevents the runtime issue (UnsatisfiedLinkError), but then since `FontConfigManager.getFontConfigFont` returns null (note there is an `AndroidFontFinder` class that should manage fonts on Android), then the NPE can't be avoided, unless with add this null check. 

I agree that a null check hides the underlying issue, so prabably we should use `isLinux` instead. `PrismFontFactory` has this gate before calling `FontConfigManager`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2320826055

From duke at openjdk.org  Fri Aug 30 11:34:56 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Fri, 30 Aug 2024 11:34:56 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v3]
In-Reply-To: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
Message-ID: <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>

> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  Requested changes from review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1551/files
  - new: https://git.openjdk.org/jfx/pull/1551/files/85d11d4e..af515ffb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1551&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1551&range=01-02

  Stats: 36 lines in 2 files changed: 3 ins; 21 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1551.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1551/head:pull/1551

PR: https://git.openjdk.org/jfx/pull/1551

From duke at openjdk.org  Fri Aug 30 11:34:56 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Fri, 30 Aug 2024 11:34:56 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <1FfixNpaLEZz1x9wJ7gmNfFrbScuvwwfBsSdd6LRboo=.fb37357e-fd61-4a72-9b49-cd1ed81366e7@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
 <1FfixNpaLEZz1x9wJ7gmNfFrbScuvwwfBsSdd6LRboo=.fb37357e-fd61-4a72-9b49-cd1ed81366e7@github.com>
Message-ID: <s1bBAJpA09x0QNR03Yf8h43fqKlqpJF_l_gWkSDcQXo=.2e071e98-aa91-4844-a328-8a4b3459c7d3@github.com>

On Fri, 30 Aug 2024 08:18:08 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> modules/javafx.web/src/main/native/Source/WTF/wtf/java/FileSystemJava.cpp line 276:
> 
>> 274: }
>> 275: 
>> 276: String pathFileName(const String& path)
> 
> This method is used 2 times in file  `modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm`.
> It needs correction. [[1]](https://github.com/openjdk/jfx/blob/a53bc589ac37d490b1406a2b977097a06bf5ac74/modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm#L62), [[2]](https://github.com/openjdk/jfx/blob/a53bc589ac37d490b1406a2b977097a06bf5ac74/modules/javafx.web/src/main/native/Source/WebCore/fileapi/FileCocoa.mm#L64)

Indeed, now there are no more calls to pathGetFileName in the branch

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1551#discussion_r1738464337

From duke at openjdk.org  Fri Aug 30 11:38:29 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Fri, 30 Aug 2024 11:38:29 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v2]
In-Reply-To: <1FfixNpaLEZz1x9wJ7gmNfFrbScuvwwfBsSdd6LRboo=.fb37357e-fd61-4a72-9b49-cd1ed81366e7@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <zqbNFjPdiIGKU4CU_308mdy14XXCSgnwup7F8HLDkok=.8ebea9b9-a666-47f8-9cc4-31a69fdfcdc1@github.com>
 <1FfixNpaLEZz1x9wJ7gmNfFrbScuvwwfBsSdd6LRboo=.fb37357e-fd61-4a72-9b49-cd1ed81366e7@github.com>
Message-ID: <2IyPaPHSOw_i-th0A_w-wY6mqi5w8BkpPhYjEKfy-BA=.5d072b91-64b4-4d9a-a0d7-6288eb4fd4a3@github.com>

On Fri, 30 Aug 2024 08:18:28 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test
>
> modules/javafx.web/src/test/java/test/javafx/scene/web/FileTest.java line 94:
> 
>> 92:         });
>> 93:     }
>> 94: }
> 
> The test requires a few changes:
> 1. Correct copyright year
> 2. Several imports can be removed.
> 3. method `private State getLoadState()` is unused
> 4. method `getScriptString()` can be replaced with a string member variable
> 5. Line 70,71 needs format correction
> 
> I tried these changes locally, attaching the file with required changes. Please check
> [FileTest.java.zip](https://github.com/user-attachments/files/16813919/FileTest.java.zip)

I have taken the requested changes from your file.
This was simply taken from test.javafx.scene.web.FileReaderTest with future tests for other file properties in mind.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1551#discussion_r1738468124

From jpereda at openjdk.org  Fri Aug 30 11:46:24 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 30 Aug 2024 11:46:24 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <3xLkjRYLSvwGCGBKE0uqd9OtOeXQEsifiq5OW4oI-5w=.39b5c2d6-a49a-4ddf-9e78-fe3efaf071da@github.com>

On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

So far, the documentation in https://wiki.openjdk.org/display/OpenJFX/Font+Setup is still somehow valid in this situation (no fontConfig and providing embedded fonts).

So I can revert the change in `LogicalFont`, and modify the message in `FontConfigManager::initFontConfigLogFonts`:

System.err.println("Error: JavaFX detected no fonts! " +
                "Please refer to release notes for proper font configuration");
```         
to something more meaningful, like?

System.err.println("Error: JavaFX detected no fonts!\n " +
                "For proper font configuration, please check https://wiki.openjdk.org/display/OpenJFX/Font+Setup");
```            

The NPE will be still present though.

Thoughts?

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

PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2320964768

From duke at openjdk.org  Fri Aug 30 11:50:54 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Fri, 30 Aug 2024 11:50:54 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v3]
In-Reply-To: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
Message-ID: <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>

> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  Requested changes from review

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1547/files
  - new: https://git.openjdk.org/jfx/pull/1547/files/c0e4adcb..831aa443

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1547&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1547&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1547.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1547/head:pull/1547

PR: https://git.openjdk.org/jfx/pull/1547

From jpereda at openjdk.org  Fri Aug 30 12:00:35 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 30 Aug 2024 12:00:35 GMT
Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because
 "<local4>" is null [v2]
In-Reply-To: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
References: <lmob3O6tiaHRaR5M7wPGa9Hz83QZtK3Ea2ar79rEJnY=.0148b8c2-a28c-4ff5-8d35-437d9a93ff7a@github.com>
Message-ID: <etv56E_WPwzl8pBa14Tsi8fMYhxgnl0MX-MH0QgzTko=.b331af70-6f2b-439d-949b-930d5b91df2a@github.com>

> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null.
> 
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`.
> 
> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out:
> 
> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration
> 
> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. 
> 
> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it.
> 
> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception:
> 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461)
>         at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79)
>         at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258)
>         at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576)
>  ...
> 
> 
> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null?

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Use isLinux in FTFactory instead of null check

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1546/files
  - new: https://git.openjdk.org/jfx/pull/1546/files/e080a4a5..a6fe2e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1546&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1546&range=00-01

  Stats: 11 lines in 1 file changed: 6 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1546.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1546/head:pull/1546

PR: https://git.openjdk.org/jfx/pull/1546

From sykora at openjdk.org  Fri Aug 30 12:13:22 2024
From: sykora at openjdk.org (Joeri Sykora)
Date: Fri, 30 Aug 2024 12:13:22 GMT
Subject: RFR: 8338701: Provide media support for libavcodec version 61
In-Reply-To: <Bb4ePyRPKhnscUyckfHrg1COzc_wu-LI-KIIYnhspnU=.3d4e6679-ac06-49fd-af21-730cac3d7fa2@github.com>
References: <Bb4ePyRPKhnscUyckfHrg1COzc_wu-LI-KIIYnhspnU=.3d4e6679-ac06-49fd-af21-730cac3d7fa2@github.com>
Message-ID: <DNBCBwIwco4srbtTlNAfD9mjoCkOg9O-01P0tzqJ6dU=.d0122439-ccbd-4df7-992a-d21a6d6cd7e3@github.com>

On Thu, 29 Aug 2024 21:02:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for libavcodec 61.
> - Updated AV plugins to use new APIs instead of APIs which were removed in 61.
> - We still using some deprecated APIs.
> - `reordered_opaque` replacement exist in 61 which is used to pass user data between compressed frame and uncompressed. In 61 this variable is pointer to `void` instead of `int64_t`. We can use new `opaque` to pass PTS, but it is not documented way to pass PTS between compressed and uncompressed frames. Updated code will be using `AVPacket.pts/AVFrame.pts` which is documented way to provide PTS.
> - Tested on Ubuntu 24.10 with 61 and 24.04 with 60 with all supported formats.

Everything went fine with the builds.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1552#pullrequestreview-2272100416

From kcr at openjdk.org  Fri Aug 30 12:51:52 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 12:51:52 GMT
Subject: RFR: 8339247: Create release notes for JavaFX 23
Message-ID: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>

This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo).

The following filter was used to produce the list of issues fixed in JavaFX 23:

https://bugs.openjdk.org/issues/?filter=45422

Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes.

I will wait until closer to the September 17th release date to integrate this.


A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split:

## List of New Features

Issue key|Summary|Subcomponent
---------|-------|------------
[JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls
[JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls
[JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics
[JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics
[JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media

## List of Other Enhancements

Issue key|Summary|Subcomponent
---------|-------|------------
[JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build
[JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls
[JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics
[JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics
[JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics

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

Commit messages:
 - Add missing backtick to fix markdown
 - 8339247: Create release notes for JavaFX 23

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

PR: https://git.openjdk.org/jfx/pull/1553

From kcr at openjdk.org  Fri Aug 30 12:54:26 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 12:54:26 GMT
Subject: RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
References: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
Message-ID: <Ilze5X61g0Xahery2GDdF_ptv4c8B1qovuozABDweY4=.9b5dc66b-8894-42e2-b437-d3b34a3719ea@github.com>

On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 23:
> 
> https://bugs.openjdk.org/issues/?filter=45422
> 
> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes.
> 
> I will wait until closer to the September 17th release date to integrate this.
> 
> 
> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split:
> 
> ## List of New Features
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls
> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls
> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics
> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics
> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media
> 
> ## List of Other Enhancements
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build
> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls
> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics
> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics
> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics

Reviewers @johanvos @abhinayagarwal

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

PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2321150510

From kcr at openjdk.org  Fri Aug 30 12:57:29 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 12:57:29 GMT
Subject: RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
References: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
Message-ID: <DinprjVpF_rdCsFMTfrNI-aH7PlF-3AmO2TGQ5fGxTU=.851e847e-166d-4934-afcf-a0ceb54bd79a@github.com>

On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 23:
> 
> https://bugs.openjdk.org/issues/?filter=45422
> 
> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes.
> 
> I will wait until closer to the September 17th release date to integrate this.
> 
> 
> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split:
> 
> ## List of New Features
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls
> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls
> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics
> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics
> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media
> 
> ## List of Other Enhancements
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build
> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls
> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics
> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics
> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics

> A https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014 to split out the new features (something that adds new functionality to the platform) from enhancements.

@andy-goryachev-oracle @nlisker @johanvos @abhinayagarwal Do any of you have an opinion on this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2321160886

From arapte at openjdk.org  Fri Aug 30 13:38:23 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 30 Aug 2024 13:38:23 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v3]
In-Reply-To: <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
Message-ID: <n15_ep4WZ3ckLX4CZ_CAdlbmU5LzFnyBrs5EXoLI9UY=.38d3bc28-89fa-4701-b936-ce67711c8c86@github.com>

On Fri, 30 Aug 2024 11:34:56 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1551#pullrequestreview-2272372466

From kcr at openjdk.org  Fri Aug 30 14:07:22 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 14:07:22 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v3]
In-Reply-To: <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
Message-ID: <GEh53Ro_8XGQo0HT_yTVY58URcq8j2xCjVVQM0Se3LE=.b8704f16-7221-4c00-bf6d-10cf938f41c1@github.com>

On Fri, 30 Aug 2024 11:50:54 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

Looks good now. Test still passes.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1547#pullrequestreview-2272462828

From nlisker at openjdk.org  Fri Aug 30 14:28:25 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 30 Aug 2024 14:28:25 GMT
Subject: RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
References: <OburBdgCapGbGoXJmvlEqoCbbn9xiUyA50dmZUGnZLo=.10b45ced-911b-4a66-bbce-432e001e888d@github.com>
Message-ID: <cqtHPUrpgNncaNEYRbu7mBC-2m7dD65z4vk652pE1ZI=.bda39a38-db8b-41df-b4ef-36ab3cad5a3b@github.com>

On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 23:
> 
> https://bugs.openjdk.org/issues/?filter=45422
> 
> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes.
> 
> I will wait until closer to the September 17th release date to integrate this.
> 
> 
> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split:
> 
> ## List of New Features
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls
> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls
> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics
> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics
> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media
> 
> ## List of Other Enhancements
> 
> Issue key|Summary|Subcomponent
> ---------|-------|------------
> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build
> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls
> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics
> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics
> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics

There are https://openjfx.io/highlights/22/, https://openjfx.io/highlights/21/ etc. I think they do a good job at separating APIs from improvements, so whatever the highlights for 23 will say needs to be aligned with the ones here, in my opinion.

The current separation looks fine.

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

PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2321431383

From nlisker at gmail.com  Fri Aug 30 14:49:40 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 30 Aug 2024 17:49:40 +0300
Subject: Failing to build JavaFX
In-Reply-To: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
Message-ID: <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>

I have WSL 2 and I didn't get this error. For Windows, you're not supposed
to use WSL at all for the building process, so no reason for it to be
involved. I suggest that you just run "./gradlew :media:buildWINGlib"
(which is where the error is occurring) with --debug or --info.

Did you set up Visual Studio? It's required
for WINDOWS_NATIVE_COMPILE_ENVIRONMENT.

- Nir

On Fri, Aug 30, 2024 at 8:23?AM Knee Snap <kneester77 at gmail.com> wrote:

> Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
> -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
> confronted with the following output:
>
> "
> > Task :media:buildWinGlib
> make: Entering directory
> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> make TARGET=/libffi.lib -f Makefile.ffi
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> /bin/sh: line 1: cygpath: command not found
> make: make: Not a directory
> make: *** [Makefile:65: /libffi.lib] Error 127
> make: Leaving directory
> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
> "
>
> However, if I immediately run "cygpath", it does run successfully. (See
> screenshot below).
> I'm not really sure what's going on, but I suspect that either somehow my
> WSL installation is getting used by gradle instead (not sure if that's even
> possible, but maybe? I don't know enough about how cygwin works), or
> something even more difficult to pinpoint is going on.
>
> Can someone help me resolve this issue? I've gotten a bit stuck. Thanks!
>
> [image: image.png]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/918abaf2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/918abaf2/image-0001.png>

From kevin.rushforth at oracle.com  Fri Aug 30 15:08:02 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Aug 2024 08:08:02 -0700
Subject: Failing to build JavaFX
In-Reply-To: <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
 <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
Message-ID: <f9086ead-4dcb-41f4-88a6-f48ed8f1a300@oracle.com>

It looks like cygwin might not be in your path when that media shell 
script is being executed. Maybe it's getting reset by your .bashrc or 
.profile script?

You might try building without media and webkit, although you'll need to 
download a fairly recent version of those libraries if you don't. Try 
replacing " -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true" with 
"-PSTUB_RUNTIME_OPENJFX=24-ea+5".

-- Kevin


On 8/30/2024 7:49 AM, Nir Lisker wrote:
> I have WSL 2 and I didn't get this error. For Windows, you're not 
> supposed to use WSL at all for the?building process, so no reason for 
> it?to be involved. I suggest that you just run "./gradlew 
> :media:buildWINGlib" (which is where the error is occurring) with 
> --debug or --info.
>
> Did you set up Visual Studio? It's required 
> for?WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>
> - Nir
>
> On Fri, Aug 30, 2024 at 8:23?AM Knee Snap <kneester77 at gmail.com> wrote:
>
>     Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
>     -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am
>     eventually confronted with the following output:
>
>     "
>     > Task :media:buildWinGlib
>     make: Entering directory
>     '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     make TARGET=/libffi.lib -f Makefile.ffi
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     /bin/sh: line 1: cygpath: command not found
>     make: make: Not a directory
>     make: *** [Makefile:65: /libffi.lib] Error 127
>     make: Leaving directory
>     '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>     "
>
>     However, if I immediately run "cygpath", it does run successfully.
>     (See screenshot below).
>     I'm not really sure what's going on, but I suspect that either
>     somehow my WSL installation is getting used by gradle instead (not
>     sure if that's even possible, but maybe? I don't know enough about
>     how cygwin works), or something even more difficult to pinpoint is
>     going on.
>
>     Can someone help me resolve this issue? I've gotten a bit stuck.
>     Thanks!
>
>     image.png
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/b81c5cf4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/b81c5cf4/image-0001.png>

From hmeda at openjdk.org  Fri Aug 30 17:22:27 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Fri, 30 Aug 2024 17:22:27 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v3]
In-Reply-To: <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
Message-ID: <g7tbDOJ78tSccLtS_k9U90zeaLoxyv8RIC0ZBvKxoIQ=.7c333fe9-f423-499a-9f3f-9b22df6333e5@github.com>

On Fri, 30 Aug 2024 11:34:56 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

Changes look fine. Verified that full file path is shown without the fix . With the fix, only the file name is shown, as expected.

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

Marked as reviewed by hmeda (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1551#pullrequestreview-2273127246

From duke at openjdk.org  Fri Aug 30 17:32:26 2024
From: duke at openjdk.org (duke)
Date: Fri, 30 Aug 2024 17:32:26 GMT
Subject: RFR: 8337481: File API: file.name contains path instead of name
 [v3]
In-Reply-To: <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
 <rlZMLi96CxxM_Pk7pr_TFoq2wm9H55i_7vAikB3VN8g=.0f9c4713-8c0c-46a6-b62f-6e074c8c89ba@github.com>
Message-ID: <H6M02z6_u6rX7twEogBfiCXPs0vI_vwGoNL3OTaeLNw=.f24ca2c2-c0e8-4a45-b231-0e5445c29adb@github.com>

On Fri, 30 Aug 2024 11:34:56 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

@Schmidor 
Your change (at version af515ffb6a6c180d489de352ba7cce73048ec35f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1551#issuecomment-2322029792

From duke at openjdk.org  Fri Aug 30 19:48:25 2024
From: duke at openjdk.org (Oliver Schmidtmer)
Date: Fri, 30 Aug 2024 19:48:25 GMT
Subject: Integrated: 8337481: File API: file.name contains path instead of name
In-Reply-To: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
References: <-WsLf_utCwUC_QqwjgiEW01W4jZNeTA6ScMdo2AWpco=.53048b59-1ef9-4bb5-8cfe-8981afe2e99e@github.com>
Message-ID: <RRfrLv4wAEWve7RsbjKREcwnbKDi_EvdjYfYD66P__I=.337fb08a-6ee6-46e9-9bf8-83a6df7835c5@github.com>

On Thu, 29 Aug 2024 13:16:11 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

> FileSystemJava had no valid implementation for pathFileName since the function was renamed from pathGetFileName to pathFileName in the FileSystem.h from WebKit

This pull request has now been integrated.

Changeset: ca70a07b
Author:    Oliver Schmidtmer <O.Schmidtmer at elo.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ca70a07b3ee712b1d06baf8a3901e6ae96070124
Stats:     91 lines in 4 files changed: 76 ins; 12 del; 3 mod

8337481: File API: file.name contains path instead of name

Reviewed-by: arapte, hmeda

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

PR: https://git.openjdk.org/jfx/pull/1551

From kneester77 at gmail.com  Fri Aug 30 19:48:24 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Fri, 30 Aug 2024 12:48:24 -0700
Subject: Failing to build JavaFX
In-Reply-To: <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
 <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
Message-ID: <CAB9Lf7+31vV3N3uGTfJ7hR3bNYRsogD5WMGByH0gFByhnt-obg@mail.gmail.com>

I am running from cygwin (not WSL) as my screenshot shows. I'll try --debug.
And yes, I have Visual Studio setup with the C++ package referenced as
required.

I do not believe there is an issue with the Visual Studio usage as it is
able to successfully compile a bunch of C++ source files prior to the
failing step.

On Fri, Aug 30, 2024, 7:50?AM Nir Lisker <nlisker at gmail.com> wrote:

> I have WSL 2 and I didn't get this error. For Windows, you're not supposed
> to use WSL at all for the building process, so no reason for it to be
> involved. I suggest that you just run "./gradlew :media:buildWINGlib"
> (which is where the error is occurring) with --debug or --info.
>
> Did you set up Visual Studio? It's required
> for WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>
> - Nir
>
> On Fri, Aug 30, 2024 at 8:23?AM Knee Snap <kneester77 at gmail.com> wrote:
>
>> Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
>> -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
>> confronted with the following output:
>>
>> "
>> > Task :media:buildWinGlib
>> make: Entering directory
>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> make TARGET=/libffi.lib -f Makefile.ffi
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> make: make: Not a directory
>> make: *** [Makefile:65: /libffi.lib] Error 127
>> make: Leaving directory
>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>> "
>>
>> However, if I immediately run "cygpath", it does run successfully. (See
>> screenshot below).
>> I'm not really sure what's going on, but I suspect that either somehow my
>> WSL installation is getting used by gradle instead (not sure if that's even
>> possible, but maybe? I don't know enough about how cygwin works), or
>> something even more difficult to pinpoint is going on.
>>
>> Can someone help me resolve this issue? I've gotten a bit stuck. Thanks!
>>
>> [image: image.png]
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/e0705840/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/e0705840/image-0001.png>

From kneester77 at gmail.com  Fri Aug 30 19:51:49 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Fri, 30 Aug 2024 12:51:49 -0700
Subject: Failing to build JavaFX
In-Reply-To: <f9086ead-4dcb-41f4-88a6-f48ed8f1a300@oracle.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
 <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
 <f9086ead-4dcb-41f4-88a6-f48ed8f1a300@oracle.com>
Message-ID: <CAB9Lf7JTPOCQMvNg+zKtTcT30C3pFOCXgJauFeOxhwfLU6KrTA@mail.gmail.com>

I tried this suggestion (the one Kevin has suggested) but I got warnings
about Gradle verification failures, and it listed specifically the JavaFX
version I had specified. Tried with a few different  modern versions to no
avail. Perhaps I'll try again and see if I can ignore those warnings.

On Fri, Aug 30, 2024, 8:08?AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> It looks like cygwin might not be in your path when that media shell
> script is being executed. Maybe it's getting reset by your .bashrc or
> .profile script?
>
> You might try building without media and webkit, although you'll need to
> download a fairly recent version of those libraries if you don't. Try
> replacing " -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true" with
> "-PSTUB_RUNTIME_OPENJFX=24-ea+5".
>
> -- Kevin
>
>
> On 8/30/2024 7:49 AM, Nir Lisker wrote:
>
> I have WSL 2 and I didn't get this error. For Windows, you're not supposed
> to use WSL at all for the building process, so no reason for it to be
> involved. I suggest that you just run "./gradlew :media:buildWINGlib"
> (which is where the error is occurring) with --debug or --info.
>
> Did you set up Visual Studio? It's required
> for WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>
> - Nir
>
> On Fri, Aug 30, 2024 at 8:23?AM Knee Snap <kneester77 at gmail.com> wrote:
>
>> Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
>> -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
>> confronted with the following output:
>>
>> "
>> > Task :media:buildWinGlib
>> make: Entering directory
>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> make TARGET=/libffi.lib -f Makefile.ffi
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> /bin/sh: line 1: cygpath: command not found
>> make: make: Not a directory
>> make: *** [Makefile:65: /libffi.lib] Error 127
>> make: Leaving directory
>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>> "
>>
>> However, if I immediately run "cygpath", it does run successfully. (See
>> screenshot below).
>> I'm not really sure what's going on, but I suspect that either somehow my
>> WSL installation is getting used by gradle instead (not sure if that's even
>> possible, but maybe? I don't know enough about how cygwin works), or
>> something even more difficult to pinpoint is going on.
>>
>> Can someone help me resolve this issue? I've gotten a bit stuck. Thanks!
>>
>> [image: image.png]
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/19598b20/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/19598b20/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93910 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/19598b20/image-0003.png>

From kcr at openjdk.org  Fri Aug 30 20:08:27 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 20:08:27 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6]
In-Reply-To: <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
Message-ID: <ycYXZDxWA47K6yoHEMxvW6MtK0QDVg5fbxf-XQzdWmk=.c891c834-efe0-4943-a6f0-d51af43b360c@github.com>

On Thu, 29 Aug 2024 19:49:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - improved vertical scrolling
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - cleanup
>  - navigation
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - update + review comments
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - 8301121: RichTextArea Control (Incubator)

I started writing up some notes for myself, but then thought it might be worth sharing. Here are my meta- suggestions/ reminders for those who want to review this PR. Almost all of this would apply to reviewing any large feature.

Reviewing a large feature such as this presents a bit of a challenge. It might help focus review comments to think of the following two main areas of review:

1. API and feature set

This includes reviewing the feature set as described in the [JEP](https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md) and any other high-level docs, such as [RichTextAreaBehavior.md](https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md), the public API and docs along with other public interfaces (css, modena stylesheet entries) or user-visible behavior, and how well the new feature works (ease-of-use, limitations, etc).

2. Code review of the implementation, including tests and demos

This includes reviewing the implementation from various perspectives:

* Correctness, maintainability, efficiency, etc
* The API coverage provided by the automated tests and demos
* The implementation of the tests and demos
* Code style and other similar aspects (best done after the important things have been addressed)

I would ask reviewers to concentrate on the API and feature set for now. After API issues are mostly settled, we can switch our attention to a more detailed code review.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2322257119

From kcr at openjdk.org  Fri Aug 30 20:11:27 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 20:11:27 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6]
In-Reply-To: <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
Message-ID: <rcQJpNZRophbCPDksZvPC031HwFkzt87dNsnBfeDb6A=.ea5b37e2-1b77-43e4-a277-a02146827240@github.com>

On Thu, 29 Aug 2024 19:49:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - improved vertical scrolling
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - cleanup
>  - navigation
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - update + review comments
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - 8301121: RichTextArea Control (Incubator)

I'm going to be reviewing this in spurts over the next couple of weeks or so. My initial comments will be focused on the `jfx.incubator.richtext` module, specifically the `RichTextArea` control, although I will likely bounce around a little. I will defer any comments on the input map (`jfx.incubator.input` module) until after my review of the richtext module is done.

Overall, I like how the feature set of RichTextArea is shaping up. I feel that it strikes a good balance by providing a basic control that adds missing rich text functionality to JavaFX without trying to be a full-featured rich text editor that a word processor or other rich editing app could use. It should be able to provide the building blocks for a more complex control to be implemented on top of this.

Except where a name is confusing, I'll save comments about names of methods, fields, parameters, and classes for a later pass.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2322262078

From kcr at openjdk.org  Fri Aug 30 20:23:27 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 30 Aug 2024 20:23:27 GMT
Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6]
In-Reply-To: <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
References: <cBw8Owe7C49ait_Y7RfGGhybxUq9ZjWIPyMDeztOM7w=.8bca7f3b-2791-421e-8ae7-b92eb9db1ca9@github.com>
 <bmsN27yEVe14rmHCsLt3IZ2ucmkso8bmyx-l98quOSU=.e39c35e3-7808-433f-b25b-2e3e5ff6ed8f@github.com>
Message-ID: <9hMg8GoVqUtMNXDWm4szvyd8VFVVNOEmGZYnmfvTJY8=.282e77f5-d631-46dc-b337-fec7bada3921@github.com>

On Thu, 29 Aug 2024 19:49:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers.
>> 
>> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have.
>> 
>> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**.
>> 
>> Because it's an incubating module, please focus on the public APIs rather than implementation.  There **will be** changes to the implementation once/if the module is promoted to the core by popular demand.  The goal of the incubator is to let the app developers try the new feature out. 
>> 
>> **References**
>> 
>> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md
>> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md
>> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc
>> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121
>> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md
>> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html
>> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md
>> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374
>
> Andy Goryachev has updated the pull request 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. The pull request contains 10 additional commits since the last revision:
> 
>  - improved vertical scrolling
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - cleanup
>  - navigation
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - update + review comments
>  - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>  - whitespace
>  - 8301121: RichTextArea Control (Incubator)

I was looking into what "editable" does in `RichTextArea`, and I think we need a new name for one of the methods and might also need a second convenience method. There are at least three possible states that we need to consider:

A. The model supports editing; the control's editable property is true

This means that the document can be modified via the UI; it can be modified by calling control methods from the app (or by calling the editing methods on StyledTextModel, but apps don't typically do that).

B. The model supports editing, the control's editable property is false

This means that the document cannot be modified via the UI; it _can_ be modified by calling control methods from the app (or by calling the editing methods on StyledTextModel, but apps don't typically do that).

C. The model does not support editing; it is read-only as far as the control and the StyledTextModel base class are concerned; the control's editable property is not relevant

This means that the document cannot be modified via the UI; it cannot be modified by calling control methods from the app (nor by calling the editing methods on StyledTextModel, but apps don't typically do that).

There are a couple of thoughts I have around this.

First, `RichTextArea::canEdit` is not sufficient to distinguish these three cases; it will return false for both B and C. There are methods in RTA that say "if canEdit is false, then this method does nothing". That's correct for case C, but some of those methods -- namely the ones not tied to a UI action (e.g., `appendText`, `insertText`, `replaceText`, `applyStyle`, `setStyle`, `clear`) -- will intentionally do something in case B. Consider adding a second convenience method that returns `model != null && model.isUserEditable` or similar, and use that new method to qualify whether the non-UI mutator methods of RTA do anything.

Second, `StyledTextModel::userEditable` doesn't seem like the right name for the method in the model to convey that it is effectively read-only as far as the control is concerned. Perhaps "writable" would be a better name, since from the point-of-view of the caller of the StyledTextModel, that's what it means. Maybe there is an even better name, but having "user" in the name is misleading (and editable by itself would be too confusing, since that's the name we want to keep for the control, and it doesn't have the same meaning). Or you could call it "readOnly", but then that would flip the sense of the boolean.

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

PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2322279334

From kneester77 at gmail.com  Fri Aug 30 21:41:47 2024
From: kneester77 at gmail.com (Knee Snap)
Date: Fri, 30 Aug 2024 14:41:47 -0700
Subject: Failing to build JavaFX
In-Reply-To: <CAB9Lf7JTPOCQMvNg+zKtTcT30C3pFOCXgJauFeOxhwfLU6KrTA@mail.gmail.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
 <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
 <f9086ead-4dcb-41f4-88a6-f48ed8f1a300@oracle.com>
 <CAB9Lf7JTPOCQMvNg+zKtTcT30C3pFOCXgJauFeOxhwfLU6KrTA@mail.gmail.com>
Message-ID: <CAB9Lf7KzP6oqu18WzJt9e5BgQHazfbU0Lvc7pKW6Aut6yaZBLQ@mail.gmail.com>

By following Kevin's suggestion, I was able to successfully build JavaFX
and run the unit tests.

Thanks Kevin!

On Fri, Aug 30, 2024 at 12:51?PM Knee Snap <kneester77 at gmail.com> wrote:

> I tried this suggestion (the one Kevin has suggested) but I got warnings
> about Gradle verification failures, and it listed specifically the JavaFX
> version I had specified. Tried with a few different  modern versions to no
> avail. Perhaps I'll try again and see if I can ignore those warnings.
>
> On Fri, Aug 30, 2024, 8:08?AM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> It looks like cygwin might not be in your path when that media shell
>> script is being executed. Maybe it's getting reset by your .bashrc or
>> .profile script?
>>
>> You might try building without media and webkit, although you'll need to
>> download a fairly recent version of those libraries if you don't. Try
>> replacing " -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true" with
>> "-PSTUB_RUNTIME_OPENJFX=24-ea+5".
>>
>> -- Kevin
>>
>>
>> On 8/30/2024 7:49 AM, Nir Lisker wrote:
>>
>> I have WSL 2 and I didn't get this error. For Windows, you're not
>> supposed to use WSL at all for the building process, so no reason for it to
>> be involved. I suggest that you just run "./gradlew :media:buildWINGlib"
>> (which is where the error is occurring) with --debug or --info.
>>
>> Did you set up Visual Studio? It's required
>> for WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>>
>> - Nir
>>
>> On Fri, Aug 30, 2024 at 8:23?AM Knee Snap <kneester77 at gmail.com> wrote:
>>
>>> Upon trying to run "./gradlew -PFULL_TEST=true -PUSE_ROBOT=true
>>> -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true all test", I am eventually
>>> confronted with the following output:
>>>
>>> "
>>> > Task :media:buildWinGlib
>>> make: Entering directory
>>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> make TARGET=/libffi.lib -f Makefile.ffi
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> /bin/sh: line 1: cygpath: command not found
>>> make: make: Not a directory
>>> make: *** [Makefile:65: /libffi.lib] Error 127
>>> make: Leaving directory
>>> '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>>> "
>>>
>>> However, if I immediately run "cygpath", it does run successfully. (See
>>> screenshot below).
>>> I'm not really sure what's going on, but I suspect that either somehow
>>> my WSL installation is getting used by gradle instead (not sure if that's
>>> even possible, but maybe? I don't know enough about how cygwin works), or
>>> something even more difficult to pinpoint is going on.
>>>
>>> Can someone help me resolve this issue? I've gotten a bit stuck. Thanks!
>>>
>>> [image: image.png]
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/fb1459b1/attachment.htm>

From kevin.rushforth at oracle.com  Fri Aug 30 21:51:08 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Aug 2024 14:51:08 -0700
Subject: [External] : Re: Failing to build JavaFX
In-Reply-To: <CAB9Lf7KzP6oqu18WzJt9e5BgQHazfbU0Lvc7pKW6Aut6yaZBLQ@mail.gmail.com>
References: <CAB9Lf7KKCCh7geufckz+=WP2a9hFLofLwXjwbpn9jNvHOm4EsA@mail.gmail.com>
 <CA+0ynh9NyTr_oKEF7K-4SBDw1n357nPb5POZSNFkt+CTh4ouvQ@mail.gmail.com>
 <f9086ead-4dcb-41f4-88a6-f48ed8f1a300@oracle.com>
 <CAB9Lf7JTPOCQMvNg+zKtTcT30C3pFOCXgJauFeOxhwfLU6KrTA@mail.gmail.com>
 <CAB9Lf7KzP6oqu18WzJt9e5BgQHazfbU0Lvc7pKW6Aut6yaZBLQ@mail.gmail.com>
Message-ID: <96a46b38-e5ed-4ac0-8fb6-9d70a53c7ad4@oracle.com>

Good to know it works. I had forgotten that the "-PSTUB_RUNTIME_OPENJFX" 
option would run into the gradle verification issue, but I see you were 
able to work around it.

So, it seems you are running into a problem with the media build 
Makefiles or scripts. At some point it would be good to know what that 
is, but for now, you can build without it.

-- Kevin


On 8/30/2024 2:41 PM, Knee Snap wrote:
> By following Kevin's suggestion, I was able to successfully build 
> JavaFX and run the unit tests.
>
> Thanks Kevin!
>
> On Fri, Aug 30, 2024 at 12:51?PM Knee Snap <kneester77 at gmail.com> wrote:
>
>     I tried this suggestion (the one Kevin has suggested) but I got
>     warnings about Gradle verification failures, and it listed
>     specifically the JavaFX version I had specified. Tried with a few
>     different? modern versions to no avail. Perhaps I'll try again and
>     see if I can ignore those warnings.
>
>     On Fri, Aug 30, 2024, 8:08?AM Kevin Rushforth
>     <kevin.rushforth at oracle.com> wrote:
>
>         It looks like cygwin might not be in your path when that media
>         shell script is being executed. Maybe it's getting reset by
>         your .bashrc or .profile script?
>
>         You might try building without media and webkit, although
>         you'll need to download a fairly recent version of those
>         libraries if you don't. Try replacing " -PCOMPILE_WEBKIT=true
>         -PCOMPILE_MEDIA=true" with "-PSTUB_RUNTIME_OPENJFX=24-ea+5".
>
>         -- Kevin
>
>
>         On 8/30/2024 7:49 AM, Nir Lisker wrote:
>>         I have WSL 2 and I didn't get this error. For Windows, you're
>>         not supposed to use WSL at all for the?building process, so
>>         no reason for it?to be involved. I suggest that you just run
>>         "./gradlew :media:buildWINGlib" (which is where the error is
>>         occurring) with --debug or --info.
>>
>>         Did you set up Visual Studio? It's required
>>         for?WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
>>
>>         - Nir
>>
>>         On Fri, Aug 30, 2024 at 8:23?AM Knee Snap
>>         <kneester77 at gmail.com> wrote:
>>
>>             Upon trying to run "./gradlew -PFULL_TEST=true
>>             -PUSE_ROBOT=true -PCOMPILE_WEBKIT=true
>>             -PCOMPILE_MEDIA=true all test", I am eventually
>>             confronted with the following output:
>>
>>             "
>>             > Task :media:buildWinGlib
>>             make: Entering directory
>>             '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             make TARGET=/libffi.lib -f Makefile.ffi
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             /bin/sh: line 1: cygpath: command not found
>>             make: make: Not a directory
>>             make: *** [Makefile:65: /libffi.lib] Error 127
>>             make: Leaving directory
>>             '/cygdrive/g/Playground/jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite'
>>             "
>>
>>             However, if I immediately run "cygpath", it does run
>>             successfully. (See screenshot below).
>>             I'm not really sure what's going on, but I suspect that
>>             either somehow my WSL installation is getting used by
>>             gradle instead (not sure if that's even possible, but
>>             maybe? I don't know enough about how cygwin works), or
>>             something even more difficult to pinpoint is going on.
>>
>>             Can someone help me resolve this issue? I've gotten a bit
>>             stuck. Thanks!
>>
>>             image.png
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240830/adcaa7c6/attachment-0001.htm>

From kcr at openjdk.org  Sat Aug 31 16:06:28 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 31 Aug 2024 16:06:28 GMT
Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes
 [v7]
In-Reply-To: <shz9RLO9Nl6oM1sz3ZjDXgv4vcjNE7keS8v2Med3_mY=.c0ae1e94-9c49-4851-9d3b-c454bf4ffcc5@github.com>
References: <CSIlid5rNlodbSE6KoExV27_mwREqsz3S6oUGhwmxgQ=.19af825f-9cc4-47f1-b11f-180fb3bc9bfa@github.com>
 <FAZoDGfxclN5ZII39E1QZZPqZbXU8LRHEb3sF11kzok=.3924fbb0-40cb-46b9-bd6c-5ed716cdd0d3@github.com>
 <c_RrFhvHdDPODLIUTo1QxUulPXyxPwwKGKEMeV-dOhY=.feb12312-8acc-4cea-9b63-e183a2f802a7@github.com>
 <nN3Vy1Xu8D-6Nh8q7kL8WjMVytT-G-e-d9c7Dq4pgxI=.deb49f23-3a61-46df-927f-564b20d4bc6d@github.com>
 <shz9RLO9Nl6oM1sz3ZjDXgv4vcjNE7keS8v2Med3_mY=.c0ae1e94-9c49-4851-9d3b-c454bf4ffcc5@github.com>
Message-ID: <T4dvldW8SmlGbQBOftOL2QJQ1PFrp9S4AZ68NAEQLqY=.b01ec1d4-53f0-4248-9df4-c9de925701dd@github.com>

On Tue, 13 Aug 2024 14:18:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> oops, yes, you did, my mistake. the master progressed since then, got me confused.
>>> 
>>> I got a bunch of errors again after switching:
>>> 
>>> ```
>>> Description	Resource	Type	Path	Location
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3024
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3214
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3267
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3282
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3607
>>> Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3651
>>> ```
>> 
>> I got these too, as well as many
>> 
>> The method createShader(String, InputStream, Map<String,Integer>, Map<String,Integer>, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap<String,Integer>, HashMap<String,Integer>, int, boolean, boolean)
>> 
>> I haven't worked on this repo for 3 weeks, what changed?
>
>> > oops, yes, you did, my mistake. the master progressed since then, got me confused.
>> > I got a bunch of errors again after switching:
>> > ```
>> > Description	Resource	Type	Path	Location
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3024
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3214
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3267
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3282
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3607
>> > Cannot infer type arguments for ParsedValueImpl<>	CssParser.java	Java Problem	/graphics/src/main/java/javafx/css	line 3651
>> > ```
>> 
>> I got these too, as well as many
>> 
>> ```
>> The method createShader(String, InputStream, Map<String,Integer>, Map<String,Integer>, int, boolean, boolean) in the type ShaderFactory is not applicable for the arguments (InputStream, HashMap<String,Integer>, HashMap<String,Integer>, int, boolean, boolean)
>> ```
>> 
>> I haven't worked on this repo for 3 weeks, what changed?
> 
> The ones mentioned by Andy I also see, and are just a difference in opinion between Javac and ECJ, or perhaps a bug in the incremental compilation that Eclipse does (as they usually only appear when it does an incremental compile, not a full one).  When those occur, I just select them and remove them from the errors list.
> 
> The others I haven't seen before, and I'm not seeing them now.  I did a search for `createShader` but didn't see anything unusual.
> 
> I'm not aware of any special changes in the last 3 weeks.  I did a fresh import recently, and nothing strange popped up.

@hjohn This PR is approved and just waiting for the CSR. Please create one when you have a chance.

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

PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2322945709

From jbhaskar at openjdk.org  Sat Aug 31 16:24:25 2024
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 31 Aug 2024 16:24:25 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v3]
In-Reply-To: <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
Message-ID: <UDper_ikLjWcZ5tam7elBNTDXJLjhAXmvLRlXvbJ_Vk=.4d4acb7b-779f-4e21-90d2-b1afea7676dd@github.com>

On Fri, 30 Aug 2024 11:50:54 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

The fix looks good, it passes with fix and fail without fix.

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

Marked as reviewed by jbhaskar (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1547#pullrequestreview-2273952981

From duke at openjdk.org  Sat Aug 31 17:46:25 2024
From: duke at openjdk.org (duke)
Date: Sat, 31 Aug 2024 17:46:25 GMT
Subject: RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView
 [v3]
In-Reply-To: <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
References: <LBt2ziwEL7yxjpWKWlApVC8sdh4vrsYL1-wzE_U2hXY=.a038ec9c-d9ae-4a9a-bec6-29321851c021@github.com>
 <CyzCCi_ZBYd-ox8E3g6-cDGCK3uZDKFYJSHIWnUC8PA=.1d5a6175-9098-4a3a-8f2d-03451146b03d@github.com>
Message-ID: <2J3qBOR9Y--KYkzEdamKXGI1ODUbpmtsTHKGlGterDU=.8f00eb8f-72f2-43d5-a1eb-3913d0604882@github.com>

On Fri, 30 Aug 2024 11:50:54 GMT, Oliver Schmidtmer <duke at openjdk.org> wrote:

>> On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested changes from review

@Schmidor 
Your change (at version 831aa44340f2c52398830f9ad4d34f4727c07bbd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1547#issuecomment-2322987797