From duke at openjdk.org  Fri Aug  1 02:15:57 2025
From: duke at openjdk.org (duke)
Date: Fri, 1 Aug 2025 02:15:57 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value [v3]
In-Reply-To: <JS-rZBKWCypwr_PJaXCKLQYvubRSIh2g60861ADDzK0=.11a4bd2c-e4e9-41fb-a9fb-1a5ae52256ea@github.com>
References: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
 <JS-rZBKWCypwr_PJaXCKLQYvubRSIh2g60861ADDzK0=.11a4bd2c-e4e9-41fb-a9fb-1a5ae52256ea@github.com>
Message-ID: <-l58wM_mHheRt5qbQJBMmmpsotL0d9vOclb00-Bk6v4=.09fce0e6-f81f-46e2-9c36-257c5375d899@github.com>

On Tue, 29 Jul 2025 15:55:02 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> The issue is that when we use null value for root item in a TreeView and then expand the root or change it dynamically there are phantom disclosure nodes that appear incorrectly. 
>> The issue was caused by this line `if (getSkinnable().isEmpty()) return;` in `TreeCellSkin#updateDisclosureNode()` as it prevents the method from running unless the cell's value is not empty and it caused the creation of disclosure nodes visually without any logic behind.
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

@Ziad-Mid 
Your change (at version 95997e00bf8d8ac966ca79826df0e8dbc3712a8c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1838#issuecomment-3141927290

From arapte at openjdk.org  Fri Aug  1 03:02:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 03:02:50 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v14]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision:

 - correct MSLBackend if check for CoreSymbols.getFunctions()
 - nir: break MTLTexture.update

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/db244a02..5f24f1de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=12-13

  Stats: 195 lines in 2 files changed: 101 ins; 86 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Fri Aug  1 03:08:06 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 03:08:06 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <MoGhpjcRZa4WezxhTyvO1_wMll_ualOh8gd8yDRNHvI=.4fd170d2-6fa5-4ee6-88f4-394b5ce30144@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <8BWzu14LTrbX8mJomYQ6Ydng7GhLhMIIaxia-1BMHj4=.b516dcf6-a663-42ac-9274-3ee7baef91d3@github.com>
 <qxIEiwvEIsOdblX5rox9BdcMSYWISCLmdZCFMkRCJoE=.dae74adc-9ca1-497b-9dd9-751a5dcaa8c8@github.com>
 <wO5Z_D-cGZWNtNNCfLYLN6IF38NWkosMBGpw-BMmlEs=.c4493776-6a95-444e-ae19-b6e17291524d@github.com>
 <DJgG2cMLgdWcl-Skqy1afCFAn-LHtKtQqPQofxwseqo=.99d36095-80f6-406d-b034-17731342e400@github.com>
 <Iz8JDP2C401WP2O2gLvQXf8737OF7om4-ORjlH2-MYA=.f8e07f3e-1c4b-41cd-8009-8bcbddb0369c@github.com>
 <yiuKrNJdaiuQnttLjIgL2ozohkEuiOoIW8-h2Fv-XJw=.f384216f-e51f-43bb-9bd7-ac6ac2d0c92b@github.com>
 <4QcTf_Qd_f4suDyxtg65qg0c10IUbH8aigNo55SMpzw=.29dae76a-21eb-4db0-8c07-ead9c4fa7c21@github.com>
 <MoGhpjcRZa4WezxhTyvO1_wMll_ualOh8gd
 8yDRNHvI=.4fd170d2-6fa5-4ee6-88f4-394b5ce30144@github.com>
Message-ID: <NoMHK0O31Ytp1e853AWT24hxlbA1cBPNL4iAZIEr380=.c3d28dc1-532c-40d3-b00b-42e300292795@github.com>

On Thu, 31 Jul 2025 22:31:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This issue is still unresolved: `CoreSymbols.getFunctions()` is a collection of `Function`, but it's searched for a `String` (.getName()).
>> 
>> The code in lines 216 and 238 needs to be fixed.
>> 
>> I suspect we are missing a unit test that exercises this functionality, because the code should never work.  How did it work?
>
> Andy and Nir are right. I don't see how the following can do what you intend:
> 
> 
> if (!CoreSymbols.getFunctions().contains(getFuncName(e.getFunction().getName())) &&
> 
> 
> Since `CoreSymbols.getFunctions()` is a `Set<Function>` and `e.getFunction().getName()` is a `String`, the `contains` will always return false (meaning this term in the `if` expression is always true).
> 
> Can you check this?

The check was incorrect and the `contains()` call always returned `false`. 
Due to this incorrect `contains()` call, I would have created the `libraryFunctionsUsedInShader` Set. `libraryFunctionsUsedInShader` is a subset of `CoreSymbols.getFunctions()`. So, after correcting the above `contains` call, the `libraryFunctionsUsedInShader` set is not required.

The previous if condition

if (!CoreSymbols.getFunctions().contains(getFuncName(d.getFunction().getName())) &&
    !libraryFunctionsUsedInShader.contains(getFuncName(d.getFunction().getName())))


is now changed to:

if (!CoreSymbols.getFunctions().contains(d.getFunction()))


The wrong check did not cause any issue, as the check `!CoreSymbols.getFunctions().contains(getFuncName(d.getFunction().getName()))` was wrong but always `true` and `!libraryFunctionsUsedInShader.contains(getFuncName(d.getFunction().getName()))'  check was sufficient enough for achieving required result.

The metal shaders generated before and after this change are exactly same.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2246784569

From arapte at openjdk.org  Fri Aug  1 03:31:05 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 03:31:05 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v14]
In-Reply-To: <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>
Message-ID: <YduPpydxVvXwX2p6l5_HuL7bt7d4Q3ixAf0hn6CyVFU=.1f8518da-9f9b-4b12-bdef-75461eb0fc31@github.com>

On Fri, 1 Aug 2025 03:02:50 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - correct MSLBackend if check for CoreSymbols.getFunctions()
>  - nir: break MTLTexture.update

> I would use an exhaustive switch and possibly extract each branch into a method. This is a big switch with sub-switches, it's easy to get lost.

Changed style for all switch statements. and the switch statement in `MTLTexture` is broken into 3 methods.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3142044359

From zelmidaoui at openjdk.org  Fri Aug  1 11:39:05 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 1 Aug 2025 11:39:05 GMT
Subject: Integrated: 8341286: TreeView: visual artifacts when setting new root
 with null value
In-Reply-To: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
References: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
Message-ID: <MS8IA9csf3qX5piy9uAuOgXy411cZJC7k9JJ0o4iNHo=.412cc120-7ac4-4000-96e6-033e1afa87a6@github.com>

On Mon, 30 Jun 2025 21:49:22 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue is that when we use null value for root item in a TreeView and then expand the root or change it dynamically there are phantom disclosure nodes that appear incorrectly. 
> The issue was caused by this line `if (getSkinnable().isEmpty()) return;` in `TreeCellSkin#updateDisclosureNode()` as it prevents the method from running unless the cell's value is not empty and it caused the creation of disclosure nodes visually without any logic behind.

This pull request has now been integrated.

Changeset: eca3e38b
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/eca3e38b894e8d07fcabf02e3dd381354c589a90
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8341286: TreeView: visual artifacts when setting new root with null value

Reviewed-by: angorya

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

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

From arapte at openjdk.org  Fri Aug  1 12:39:06 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 12:39:06 GMT
Subject: RFR: 8361648: Update Glib to 2.84.3
In-Reply-To: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
References: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
Message-ID: <78KgjK19XM4Dd1HmqCJvrt9VbmLwNTAQcg8CUPyQf34=.10ed0d16-f97f-4d0b-b45c-2956854ba9a7@github.com>

On Tue, 29 Jul 2025 21:02:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GLib updated to 2.84.3.
> - Tested on all platforms.
> - No other changes are done.

LGTM, sanity tested on mac platform.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1862#pullrequestreview-3079060848

From jvos at openjdk.org  Fri Aug  1 13:07:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 1 Aug 2025 13:07:08 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
Message-ID: <OSyaZwEzApCtUnwB1aCEB0Fchyprwk14MuLxUmN_o2E=.4f205540-0068-49c4-9743-b26d9bd1da9a@github.com>

On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
> 
> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
> 
> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
> 
> The contract of `refresh()` is also a big vague, stating:
> 
> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
> necessary to populate the visual bounds of the control.
> In other words, this forces the XXX to update what it is showing to the user. 
> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
> 
> 
> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).

I think the performance improvements due to this PR can be pretty significant. The problem is indeed the risk on regression. I believe we need improvements in 2 areas before we can safely merge this:
1. More functional regression tests
2. Performance tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3144522512

From sykora at openjdk.org  Fri Aug  1 14:04:03 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Fri, 1 Aug 2025 14:04:03 GMT
Subject: RFR: 8361648: Update Glib to 2.84.3
In-Reply-To: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
References: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
Message-ID: <mTsWcDTJept0KNtfueSDRR41dWjwfLATeT3zg0IbuqY=.8e1a869c-6ab1-499f-b9b7-d1cfa56e22cc@github.com>

On Tue, 29 Jul 2025 21:02:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GLib updated to 2.84.3.
> - Tested on all platforms.
> - No other changes are done.

I've successfully ran a build on all platforms.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1862#pullrequestreview-3079364963

From arapte at openjdk.org  Fri Aug  1 14:38:00 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 14:38:00 GMT
Subject: RFR: 8358092: Create accessibility protocol implementation that
 covers various type of menu items
In-Reply-To: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
References: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
Message-ID: <tqSbWc3tQiQSrRfHfegtdQ2wH4XwDZATXBDB0Doarxs=.a3257ea1-732f-4111-9eb1-c5edefdd16b0@github.com>

On Fri, 25 Jul 2025 23:32:04 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. Note that second level menu navigation with the non-system menus does not work but it was not working with the current implementation so i am raising a new bug for tracking that but that can not be a showstopper for this PR.
> 
> The bug raised to track menu deficiencies JDK-8364133

LGTM, MenuItem are read same as without this change.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1858#pullrequestreview-3079492845

From kcr at openjdk.org  Fri Aug  1 15:30:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 15:30:13 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v14]
In-Reply-To: <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>
Message-ID: <o-zODql2af_V0EfZWdBuryDFuoJen-2kqlzMrZI1XTg=.4ca10d02-f812-47bc-84eb-7cb7ed51b4c7@github.com>

On Fri, 1 Aug 2025 03:02:50 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - correct MSLBackend if check for CoreSymbols.getFunctions()
>  - nir: break MTLTexture.update

I ran a full headful system test run and discovered a few tests that crash when disposing resources. I tracked it down to one of the changes made during the review.

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3079633635

From kcr at openjdk.org  Fri Aug  1 15:30:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 15:30:13 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <Vs7Rv060zAP3P_-CDEhUvlwq6DpaMP2lExevyJu3WvA=.f2bdfd8b-665c-4122-814e-fea591b4d22d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@github.com>
 <Vs7Rv060zAP3P_-CDEhUvlwq6DpaMP2lExevyJu3WvA=.f2bdfd8b-665c-4122-814e-fea591b4d22d@github.com>
Message-ID: <mxmxxCbuQBc7_BUDGDQ0aLAElmHFm4WGvMaKLmONvDQ=.5747b0a2-b85c-40b6-904e-db2ca1bbabe6@github.com>

On Fri, 18 Jul 2025 17:54:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 396:
>> 
>>> 394:     public void dispose() {
>>> 395:         super.dispose();
>>> 396:         context.dispose();
>> 
>> Q: should we call super.dispose() _after_ context.dispose()?
>
> Yes, Changed the order. Any resources being used by MTLCommandQueue are made resident, so the resources would stay alive even if MTLResourceFactory is disposed. but the earlier order was incorrect.

Normally, this would be the right thing to do. However, it looks like switching the order has introduced several crashes. I discovered this today while testing the latest version of this PR. I bisected it and found out that this was the culprit.

It would be helpful to know why the order matters. If there is a good reason, then a comment would be helpful.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248246287

From angorya at openjdk.org  Fri Aug  1 15:55:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Aug 2025 15:55:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <mxmxxCbuQBc7_BUDGDQ0aLAElmHFm4WGvMaKLmONvDQ=.5747b0a2-b85c-40b6-904e-db2ca1bbabe6@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@github.com>
 <Vs7Rv060zAP3P_-CDEhUvlwq6DpaMP2lExevyJu3WvA=.f2bdfd8b-665c-4122-814e-fea591b4d22d@github.com>
 <mxmxxCbuQBc7_BUDGDQ0aLAElmHFm4WGvMaKLmONvDQ=.5747b0a2-b85c-40b6-904e-db2ca1bbabe6@github.com>
Message-ID: <eHkTXUrBYL29jlLDVphMa3hofy8OsCPBOJdERipt3o4=.0115dc70-07ef-41d6-9109-f5d4f84d6785@github.com>

On Fri, 1 Aug 2025 15:19:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Yes, Changed the order. Any resources being used by MTLCommandQueue are made resident, so the resources would stay alive even if MTLResourceFactory is disposed. but the earlier order was incorrect.
>
> Normally, this would be the right thing to do. However, it looks like switching the order has introduced several crashes. I discovered this today while testing the latest version of this PR. I bisected it and found out that this was the culprit.
> 
> It would be helpful to know why the order matters. If there is a good reason, then a comment would be helpful.

This is alarming - perhaps something in `super.dispose()` calls overriden methods?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248317623

From arapte at openjdk.org  Fri Aug  1 17:09:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 17:09:58 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  kcr: review: crash regression fix

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/5f24f1de..3b30062e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=13-14

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

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

From arapte at openjdk.org  Fri Aug  1 17:15:12 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 1 Aug 2025 17:15:12 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v14]
In-Reply-To: <o-zODql2af_V0EfZWdBuryDFuoJen-2kqlzMrZI1XTg=.4ca10d02-f812-47bc-84eb-7cb7ed51b4c7@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <kmt6nXBAaExdP1wUGg1_99URIzRMzxHyoL4w1Mk49cU=.0945b805-8ce9-4b6c-9091-b88a2133c4f0@github.com>
 <o-zODql2af_V0EfZWdBuryDFuoJen-2kqlzMrZI1XTg=.4ca10d02-f812-47bc-84eb-7cb7ed51b4c7@github.com>
Message-ID: <5CPCOs-fnsUG296qRdpUJTLVj6bdWlrVbbmaWTOdqIY=.f5a38c3c-5b39-4f16-bb06-84ac79724a33@github.com>

On Fri, 1 Aug 2025 15:27:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I ran a full headful system test run and discovered a few tests that crash when disposing resources. I tracked it down to one of the changes made during the review.

Thanks for the offline discussion. The crash occurs when Application is exiting and a resource is released after releasing MTLContext. Adding a safety check before disposing a resource solves the issue: https://github.com/openjdk/jfx/pull/1824/commits/3b30062ef971dafcf18f08e786b7497d3c5e180d

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3145232186

From kcr at openjdk.org  Fri Aug  1 17:15:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 17:15:13 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <eHkTXUrBYL29jlLDVphMa3hofy8OsCPBOJdERipt3o4=.0115dc70-07ef-41d6-9109-f5d4f84d6785@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@github.com>
 <Vs7Rv060zAP3P_-CDEhUvlwq6DpaMP2lExevyJu3WvA=.f2bdfd8b-665c-4122-814e-fea591b4d22d@github.com>
 <mxmxxCbuQBc7_BUDGDQ0aLAElmHFm4WGvMaKLmONvDQ=.5747b0a2-b85c-40b6-904e-db2ca1bbabe6@github.com>
 <eHkTXUrBYL29jlLDVphMa3hofy8OsCPBOJdERipt3o4=.0115dc70-07ef-41d6-9109-f5d4f84d6785@github.com>
Message-ID: <w2ipICk0kwd4oH6KZss9EEDsDbfACBROx1inb0chfuI=.61ea536f-4774-436f-bcca-65252ac601ca@github.com>

On Fri, 1 Aug 2025 15:52:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Normally, this would be the right thing to do. However, it looks like switching the order has introduced several crashes. I discovered this today while testing the latest version of this PR. I bisected it and found out that this was the culprit.
>> 
>> It would be helpful to know why the order matters. If there is a good reason, then a comment would be helpful.
>
> This is alarming - perhaps something in `super.dispose()` calls overriden methods?

No, it isn't that. We tracked this down, and the problem is that `super.dispose()` clears references to disposer-managed resources, which then get GCed and have their dispose method called. Those dispose methods assume that the context is still active so unconditionally call context.dispose().

The fix, which Ambarish is doing final testing of, is to check whether the context has been disposed before disposing of textures. Basically, this is a latent bug that was exposed by changing the order.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248468500

From angorya at openjdk.org  Fri Aug  1 17:29:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Aug 2025 17:29:10 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
Message-ID: <BGCiCZtAzg7b-l9F_HOlxKC2GmQXQHSHKtZXTUK2oBI=.dcf8ae20-afc5-4544-8a55-7c741a901c65@github.com>

On Fri, 1 Aug 2025 17:09:58 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr: review: crash regression fix

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLFBOTextureData.java line 34:

> 32: 
> 33:     @Override
> 34:     public void dispose() {

There is something wrong here: this method does not call `super.dispose()`.  Is it by design (a comment would be nice then).

The `MTLTextureData.dispose()` calls `MTLResourceFactory.releaseTexture(pTexture);` which will not be called id the context is disposed of.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248497923

From angorya at openjdk.org  Fri Aug  1 17:32:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Aug 2025 17:32:16 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
Message-ID: <CqbUhKxhH5horYNROCSElqGneDIsYey-eszzG_AaMKQ=.f2dcd088-9190-4679-8e6d-b5c9e301f1dc@github.com>

On Fri, 1 Aug 2025 17:09:58 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr: review: crash regression fix

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTextureData.java line 46:

> 44:     }
> 45: 
> 46:     public void setResource(long resource) {

is this method needed?

(I don't see it being called, but I don't have all the sources added to the project in eclipse).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248503135

From angorya at openjdk.org  Fri Aug  1 17:38:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 1 Aug 2025 17:38:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
Message-ID: <7y0cgae3yAqXwDNH4b_6sF770ZAwfdTrJ-zAgh02Gg0=.44180724-d39b-4aa3-b81f-29aebc9b700a@github.com>

On Fri, 1 Aug 2025 17:09:58 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr: review: crash regression fix

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTextureData.java line 40:

> 38:                 mtlContext.flushVertexBuffer();
> 39:             }
> 40:             super.dispose();

since the call to `super.dispose() `is conditional, are you sure it always behaves as expected?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248511746

From jhendrikx at openjdk.org  Fri Aug  1 19:02:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 1 Aug 2025 19:02:58 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
Message-ID: <THsMyvTUuZteghJcXi2v8djcWrPYqvLDhvLcug-R1pg=.f689a80b-b0c0-4d80-8ab4-49c56dbe8058@github.com>

On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`, `TableView`, `TreeTableView`), all cells will be recreated completely, instead of just refreshing them.
> 
> This is because `recreateCells()` of the `VirtualFlow` is called when `refresh()` was called. This is not needed, since refreshing the cells can be done much cheaper with `rebuildCells()`.
> 
> This will reset all cells (`index = -1`), add them to the pile and fill them back in the viewport with an index again. This ensures `updateItem()` is called.
> 
> The contract of `refresh()` is also a big vague, stating:
> 
> Calling {@code refresh()} forces the XXX control to recreate and repopulate the cells 
> necessary to populate the visual bounds of the control.
> In other words, this forces the XXX to update what it is showing to the user. 
> This is useful in cases where the underlying data source has changed in a way that is not observed by the XXX itself.
> 
> 
> As written above, recreating is not needed in order to fulfull the contract of updating what is shown to the user in case the underlying data source changed without JavaFX noticing (e.g. calling a normal Setter without any Property and therefore listener involved).

I think a CSR is needed if we're changing the documentation.  It specifically says it recreates the cells (although the purpose of that eludes me, aside from badly written cells).  

Since cells are supposed to be updated, and not "retain" anything from previous contents, I think only only buggy cells would benefit from recreating.  Such buggy cells however would probably have subtle problems already when they're never recreated, like listener leaks.

So although I agree that recreating is not needed as cell functionality is defined by their `update` methods, I do think this then requires a CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3145476506

From kcr at openjdk.org  Fri Aug  1 20:10:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 20:10:04 GMT
Subject: RFR: 8359599: Calling refresh() for all virtualized controls
 recreates all cells instead of refreshing the cells
In-Reply-To: <THsMyvTUuZteghJcXi2v8djcWrPYqvLDhvLcug-R1pg=.f689a80b-b0c0-4d80-8ab4-49c56dbe8058@github.com>
References: <G1Riy4lfqDyNy8AVLYey0rrB8GdMHTar2Uww3-WRc0U=.31ab2d73-fc5a-4e28-bd09-e414779459ec@github.com>
 <THsMyvTUuZteghJcXi2v8djcWrPYqvLDhvLcug-R1pg=.f689a80b-b0c0-4d80-8ab4-49c56dbe8058@github.com>
Message-ID: <iKzy8_vKTDxdTDxaCTdbLq3bB149ARWD67MSSRizPB4=.a65334c9-ccb4-4fd5-916a-f7961a77c87a@github.com>

On Fri, 1 Aug 2025 18:54:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> So although I agree that recreating is not needed as cell functionality is defined by their `update` methods, I do think this then requires a CSR.

I agree.

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

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3145649552

From kcr at openjdk.org  Fri Aug  1 20:36:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 20:36:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
Message-ID: <xJb1Zhl6qP4xfz02ZzFz74c5lKq9R6xZdJJCKfUOlbI=.f07bca7e-282c-4b0d-9bcf-2e8c78200e6e@github.com>

On Fri, 1 Aug 2025 17:09:58 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr: review: crash regression fix

I ran a full set of automated headless tests using the MTL pipeline on my M1 running macOS 14 and everything passes now.

Andy has valid points for his follow-up questions about dispose. They should either be addressed or documented, since the usual pattern is to unconditionally call `super.dispose()` at the end of the `dispose()` method.

There is one other issue that needs to be addressed, and then I'll get back to reviewing the code. This PR branch is a few commits behind master, which is usually OK unless there have been changes that conflict semantically with the PR.

When testing a PR, I merge master into my local review branch to make sure I'm testing what would be the state of the repo if the PR were integrated then. This reveals a problem, namely that the Headless glass platform needs the same change to the `HeadlessView::_getNativeFrameBuffer` method as you did for all other subclasses of View to avoid the following compilation error:


modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java:32: error: HeadlessView is not abstract and does not override abstract method _getNativeFrameBuffer(long) in View
public class HeadlessView extends View {
       ^
modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java:87: error: _getNativeFrameBuffer(long) in HeadlessView cannot override _getNativeFrameBuffer(long) in View
    protected int _getNativeFrameBuffer(long ptr) {
                  ^
  return type int is not compatible with long


So you will need to merge the latest master into your PR branch and make the needed change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3145700979
PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3145702499

From kizune at openjdk.org  Fri Aug  1 20:46:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 1 Aug 2025 20:46:02 GMT
Subject: Integrated: 8358092: Create accessibility protocol implementation that
 covers various type of menu items
In-Reply-To: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
References: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
Message-ID: <skL-rKFB3zpXswHQIAkhyir3aC0PegbfI2fmp4QDbH4=.e17d8384-df9a-4418-9c47-c7c203ee9d9d@github.com>

On Fri, 25 Jul 2025 23:32:04 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Initial implementation. Note that second level menu navigation with the non-system menus does not work but it was not working with the current implementation so i am raising a new bug for tracking that but that can not be a showstopper for this PR.
> 
> The bug raised to track menu deficiencies JDK-8364133

This pull request has now been integrated.

Changeset: 20c18be0
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/20c18be01daedf14255d8095b47a41cb56ea3683
Stats:     106 lines in 3 files changed: 105 ins; 0 del; 1 mod

8358092: Create accessibility protocol implementation that covers various type of menu items

Reviewed-by: angorya, arapte

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

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

From andy.goryachev at oracle.com  Fri Aug  1 21:17:26 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 1 Aug 2025 21:17:26 +0000
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <FGxyepzaU9Hyj6Hv6w23QPGqw6y5ahfRGTbpK75dFmw=.e513f335-212d-49b4-9983-8cf06d0f0583@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>
 <FGxyepzaU9Hyj6Hv6w23QPGqw6y5ahfRGTbpK75dFmw=.e513f335-212d-49b4-9983-8cf06d0f0583@github.com>
Message-ID: <CY8PR10MB7265BC1811BB01FF3D81EB85E526A@CY8PR10MB7265.namprd10.prod.outlook.com>

Cleaned up the Focus Traversal Policy proposal a bit, see https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversalPolicy.md .

My problem with the Focus Delegation proposal is that it tries, as you put it, to span different levels of abstraction, in my view, unnecessarily.  Node already has the focused/focusWithin properties that are sufficient.

There is more: I think the kind of issues we see stem from the sub-optimal event dispatching mechanism in JavaFX, the weirdest part of which is creating multiple event instances for the same event.  The key events should be targeting the keyboard focus owner, in case of the Spinner and similar controls, the TextField inside of it.  "Control" and "Skin" are abstractions that have nothing to do with that, and the Spinner itself might conceptually be a part of some other custom control.

To answer the last two points:

1. the leaf TextField should be the focused Node, not its parent Control, or its more complex custom control.
2. to avoid duplicate events, don't duplicate events.

I hope to continue this conversation, since we all have one goal in mind - to make JavaFX better.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <mstrauss at openjdk.org>
Date: Wednesday, July 30, 2025 at 18:23
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>
>   Avoid variable reassignment

> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
>
> I think I narrowed down my objection to this proposal. My main problem with it is that it tries to add properties to the wrong entity (Node).
>
> In a typical application, the focus traversal requirements usually come in the context of a higher level aggregate such as a form, or a panel, or a window, and not the individual nodes. An example from Swing and AWT is the FocusTraversalPolicy class. This is no accident - the focus traversal might be dynamically dependent on other aspects of the UI state, for example the kind of information already present in a form.
>
> Trying to implement it at the Node level would be extremely difficult, and one will inevitably resolve to creating a kind of controller that determines the traversal order at the higher level.
>
> A better approach, in my opinion, would be to revive the FocusTraversalPolicy API [0], [1] (after some modernization). The most important feature that would be added is enabling ability to plug in a custom traversal policy that can address any application-level requirements with relative ease.

I don't think that these two proposals are at odds, in fact they are completely orthogonal. Focus delegation has nothing to do with focus traversal. We're not trying to answer the question what happens when (or how) we move the input focus to another control.

Focus delegation is an implementation of multi-level focus for composite controls. It spans different levels of abstraction, something that JavaFX already attempts to do right now, but fails due to a lack of supporting infrastructure. I don't see how a customizable focus traversal API addresses _any_ of the two major improvements that focus delegation brings to the table:

1. A consistent focus delegation chain: focusing a descendant control keeps the outer control focused, which is what would be expected in a black-box control model.
2. Events are not duplicated, they are logically consistent for all observers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3138275955
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250801/1bedf219/attachment-0001.htm>

From andy.goryachev at oracle.com  Fri Aug  1 21:26:47 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 1 Aug 2025 21:26:47 +0000
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <izqCGQ7v5Jgy2KEcZJtvX9oXFKvMnHZ2lFBkoh_7WE8=.4a094838-3efc-45c8-ac9e-8e9b8237c3fa@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>
 <FGxyepzaU9Hyj6Hv6w23QPGqw6y5ahfRGTbpK75dFmw=.e513f335-212d-49b4-9983-8cf06d0f0583@github.com>
 <izqCGQ7v5Jgy2KEcZJtvX9oXFKvMnHZ2lFBkoh_7WE8=.4a094838-3efc-45c8-ac9e-8e9b8237c3fa@github.com>
Message-ID: <CY8PR10MB72659B6BA488A7AD91408DE6E526A@CY8PR10MB7265.namprd10.prod.outlook.com>

My Swing is a bit rusty now, but I think it managed to handle geometry-based navigation just fine.  But it is not the reason I refer to Swing's FocusTraversalPolicy.

The application requirements might call for traversal that is governed not only by geometry, but also by the state of the UI in general, even dynamic, based on the information already entered by the user (as in "skip to item 25 if you answered "no" here).

The value of the Parent.traversalPolicy is not only that it helps with composite controls and skins, but also that it enables the application developers to implement whatever crazy requirements they might have.

Also, the FocusTraversalPolicy (whatever form it eventually might take) is not a foreign concept transplanted from an older system.  JavaFX, in fact, already has these policies internally implemented, offering a small, but important benefit of not altering the behavior of the existing code.

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <jhendrikx at openjdk.org>
Date: Wednesday, July 30, 2025 at 18:54
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
On Thu, 31 Jul 2025 01:20:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
>
> I think I narrowed down my objection to this proposal. My main problem with it is that it tries to add properties to the wrong entity (Node).
>
> In a typical application, the focus traversal requirements usually come in the context of a higher level aggregate such as a form, or a panel, or a window, and not the individual nodes. An example from Swing and AWT is the FocusTraversalPolicy class. This is no accident - the focus traversal might be dynamically dependent on other aspects of the UI state, for example the kind of information already present in a form.

The reason Swing has a FocusTraversalPolicy is because its layout system is decoupled from focus traversal. Layout managers in Swing determine the positions of components but do not expose any information about a good traversal order of those components. As a result, the container has no built-in understanding of how focus should move between components based on layout.

So Swing needed a FocusTraversalPolicy because layout managers (although flexible) do not provide any inherent information on focus traversal order. In contrast, JavaFX integrate layout and focus order more tightly through hierarchical scene graphs, node ordering, and orientation (for some controls).  In other words, there is more than enough ways to influence focus traversal order:

- Making logical groups which comes naturally with the various containers
- Adding nodes to containers in the desired focus order
- Leveraging disabled, visible, and focusTraversable properties for even more control

For instance, if a GridPane should traverse top-to-bottom rather than left-to-right, it?s simply a matter of adding the nodes in top-down order. JavaFX respects the order in which nodes are added, regardless of their visual grid positions.

So, I don't think grabbing this idea from Swing and adding it to FX can ever be the right solution as it was introduced there to solve a completely different problem (not using order of children + layout managers being decoupled and unable to confer focus traversal information).  If there are currently problems with FX's focus traversal order that can't easily be solved by using the existing tools (especially node order), that are common problems for users, then please share these, and let's see how these concerns can be addressed by enhancing what is already there instead of overriding it.  Perhaps a `Node.setViewOrder` type mechanism is needed, but for focus -- but I struggle to think why this couldn't be solved by simply moving the child in the correct position...

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3138313755
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250801/80a7f3f2/attachment.htm>

From almatvee at openjdk.org  Fri Aug  1 22:13:01 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 1 Aug 2025 22:13:01 GMT
Subject: Integrated: 8361648: Update Glib to 2.84.3
In-Reply-To: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
References: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>
Message-ID: <wMs-LGz3CzHJWyQ_Aj_MWfLGcsg6isgbi4gNSN8VGRE=.9bf5c540-6a24-4af9-96b2-fe0499d0c392@github.com>

On Tue, 29 Jul 2025 21:02:20 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - GLib updated to 2.84.3.
> - Tested on all platforms.
> - No other changes are done.

This pull request has now been integrated.

Changeset: f9532842
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f9532842b0765472c7490fb5bbf57cf268dd45ee
Stats:     10129 lines in 100 files changed: 4473 ins; 1389 del; 4267 mod

8361648: Update Glib to 2.84.3

Reviewed-by: arapte, sykora

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

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

From kcr at openjdk.org  Fri Aug  1 22:49:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 22:49:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
Message-ID: <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>

On Fri, 1 Aug 2025 17:09:58 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr: review: crash regression fix

I left a few inline comments, but this looks good overall, and is almost ready to go in.

I'll approve once you've addressed Andy's and my questions and have done the merge from master and a full test.

build.gradle line 1699:

> 1697:         doFirst {
> 1698:             mkdir "$project.buildDir/gensrc/mtl-headers"
> 1699:         }

This is only needed for macOS builds. Should it be conditional?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 98:

> 96:         try {
> 97:             final String shaderLibName = "msl/jfxshaders.metallib";
> 98:             final Class<?> clazz = Class.forName("com.sun.prism.mtl.MTLContext");

What is the purpose of this change? It's almost always better to reference a known class directly rather than `Class.forName(...)`, especially in this case where we're referring to ourself. I recommend reverting this change and assigning it to `MTLContext.class` directly.

modules/javafx.graphics/src/main/native-glass/mac/GlassView.m line 496:

> 494:         [view release];
> 495:     }
> 496:     GLASS_POOL_POP; // it was pushed by "_begin"*/

Minor: looks like you have a leftover `*/`

modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1550:

> 1548:  */
> 1549: JNIEXPORT void JNICALL Java_com_sun_prism_mtl_MTLResourceFactory_nReleaseTexture
> 1550:     (JNIEnv *env, jclass class, jlong pTexture)

I missed the discussion on this. I presume that the native context pointer was removed because it was unused? The other pipelines pass it (probably because they need it), so I was surprised that MTL doesn't. I guess there is no harm in removing it, if it really is unneeded.

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3080640437
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248947770
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248918721
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248956901
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248968967

From kcr at openjdk.org  Fri Aug  1 22:49:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 22:49:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>
Message-ID: <ybcEnXgosYfJFrCrh57gUbsGs1K7pGLoB__przrHnPU=.9fd84511-74ce-4821-bd5f-705f5070b272@github.com>

On Fri, 1 Aug 2025 21:44:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr: review: crash regression fix
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 98:
> 
>> 96:         try {
>> 97:             final String shaderLibName = "msl/jfxshaders.metallib";
>> 98:             final Class<?> clazz = Class.forName("com.sun.prism.mtl.MTLContext");
> 
> What is the purpose of this change? It's almost always better to reference a known class directly rather than `Class.forName(...)`, especially in this case where we're referring to ourself. I recommend reverting this change and assigning it to `MTLContext.class` directly.

In case it wasn't clear from the context, I recommend changing just this one line to:


            final Class<?> clazz = MTLContext.class;

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248971249

From kcr at openjdk.org  Fri Aug  1 22:49:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 1 Aug 2025 22:49:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <BGCiCZtAzg7b-l9F_HOlxKC2GmQXQHSHKtZXTUK2oBI=.dcf8ae20-afc5-4544-8a55-7c741a901c65@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <BGCiCZtAzg7b-l9F_HOlxKC2GmQXQHSHKtZXTUK2oBI=.dcf8ae20-afc5-4544-8a55-7c741a901c65@github.com>
Message-ID: <xEzLGjcWhv9IauBspqfJyeBLBCujMFiNuRFRhzcdcaE=.9982e078-a465-4f7b-8313-696fdfdda0fc@github.com>

On Fri, 1 Aug 2025 17:25:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr: review: crash regression fix
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLFBOTextureData.java line 34:
> 
>> 32: 
>> 33:     @Override
>> 34:     public void dispose() {
> 
> There is something wrong here: this method does not call `super.dispose()`.  Is it by design (a comment would be nice then).
> 
> The `MTLTextureData.dispose()` calls `MTLResourceFactory.releaseTexture(pTexture);` which will not be called id the context is disposed of.

There is a comment just below (line 39) that explains it. Maybe adding an explicit "so no need to call super.dispose()" to the comment would be helpful.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTextureData.java line 40:
> 
>> 38:                 mtlContext.flushVertexBuffer();
>> 39:             }
>> 40:             super.dispose();
> 
> since the call to `super.dispose() `is conditional, are you sure it always behaves as expected?

It looks like it's probably OK, but only because the superclass method has the same check that this one does. If you care relying on that, you will want to document that assumption, although it might be cleaner to just call `super.dispose()` unconditionally.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248923369
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2248928150

From almatvee at openjdk.org  Fri Aug  1 23:12:16 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 1 Aug 2025 23:12:16 GMT
Subject: [jfx25u] RFR: 8361648: Update Glib to 2.84.3
Message-ID: <_AffCikvhmusP_vnTwf3OhBS2TLFhNhlcbj_X3lwfrA=.3951416e-7a49-4661-a3ef-fd9036b00d86@github.com>

Clean backport of JDK-8361648.

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

Commit messages:
 - Backport f9532842b0765472c7490fb5bbf57cf268dd45ee

Changes: https://git.openjdk.org/jfx25u/pull/4/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=4&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361648
  Stats: 10129 lines in 100 files changed: 4473 ins; 1389 del; 4267 mod
  Patch: https://git.openjdk.org/jfx25u/pull/4.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/4/head:pull/4

PR: https://git.openjdk.org/jfx25u/pull/4

From almatvee at openjdk.org  Fri Aug  1 23:33:03 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 1 Aug 2025 23:33:03 GMT
Subject: [jfx25u] Integrated: 8361648: Update Glib to 2.84.3
In-Reply-To: <_AffCikvhmusP_vnTwf3OhBS2TLFhNhlcbj_X3lwfrA=.3951416e-7a49-4661-a3ef-fd9036b00d86@github.com>
References: <_AffCikvhmusP_vnTwf3OhBS2TLFhNhlcbj_X3lwfrA=.3951416e-7a49-4661-a3ef-fd9036b00d86@github.com>
Message-ID: <BqQWZ0eH7k0l9071Kr_2MC68VmqzqBdECoKUQYSG-wU=.a0d14688-e93c-4a71-bfb9-76a7ec7cc4e9@github.com>

On Fri, 1 Aug 2025 23:01:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Clean backport of JDK-8361648.

This pull request has now been integrated.

Changeset: 301f2fed
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/301f2fed00c01e2be698cd728e7a98affbcb8d2f
Stats:     10129 lines in 100 files changed: 4473 ins; 1389 del; 4267 mod

8361648: Update Glib to 2.84.3

Backport-of: f9532842b0765472c7490fb5bbf57cf268dd45ee

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

PR: https://git.openjdk.org/jfx25u/pull/4

From jhendrikx at openjdk.org  Sat Aug  2 12:10:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 2 Aug 2025 12:10:01 GMT
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>
Message-ID: <9coKohSy16HPts5K2eRswCBpPqcKdH6V-XDgg0VLxGI=.cddd9f20-6d17-4e94-8783-91656258b6fc@github.com>

On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid variable reassignment

> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
> 
> My Swing is a bit rusty now, but I think it managed to handle geometry-based navigation just fine. But it is not the reason I refer to Swing's FocusTraversalPolicy.
> 
> The application requirements might call for traversal that is governed not only by geometry, but also by the state of the UI in general, even dynamic, based on the information already entered by the user (as in "skip to item 25 if you answered "no" here).

This can easily be handled by disabling the controls that are not relevant when "no" was answered.  This can be done dynamically and something that most UI's have been doing already since UI's were invented (I remember doing this in the early 90's).  This is not a good enough reason to offer an alternative (and not complimentary) focus traversal mechanism.  

If for some reason those controls must remain "enabled", you can instead of disabling them remove their focus traversable flag -- note that you're actively confusing the user then though.
 
> The value of the Parent.traversalPolicy is not only that it helps with composite controls and skins, but also that it enables the application developers to implement whatever crazy requirements they might have.

FX shouldn't cater to crazy requirements; for inclusion in FX, this must be a **common** requirement, while offering sufficient power for "crazy" requirements.  FX makes the common cases easy (I rarely find fault with FX's default focus traversal), and there's more than sufficient controls available to support more exotic requirements.

> Also, the FocusTraversalPolicy (whatever form it eventually might take) is not a foreign concept transplanted from an older system. JavaFX, in fact, already has these policies internally implemented, offering a small, but important benefit of not altering the behavior of the existing code.

Yes, and almost universally when I encounter its usage in the behavior/skins, they actually show a lack of understanding of how FX works, or are no longer relevant as FX evolved.  I'm very sure we can remove the entire internal system (think of how much code that would safe, and how similar the user model then becomes for their own skins) and not lose any functionality by just using what FX offers with regards to focus traversal.  One of the biggest stumbling blocks for this has been removed already (see #1582 ).

As you didn't share any use cases that are even remotely common, it is still hard for me to imagine why we need an alternative navigation system when JavaFX's system out-of-the-box was by default 10x better than what Swing offered before it introduced the focus traversal policy.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3146464405

From jhendrikx at openjdk.org  Sat Aug  2 12:34:05 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 2 Aug 2025 12:34:05 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <CY8PR10MB7265BC1811BB01FF3D81EB85E526A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <CY8PR10MB7265BC1811BB01FF3D81EB85E526A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <Rnd4-QMvQM9n2q70Gi3sSojXhvV19UhRVpPWSKgSpkU=.0268df5d-ed5f-47a0-890a-c770f20aa7e5@github.com>

On Fri, 1 Aug 2025 21:18:53 GMT, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> There is more: I think the kind of issues we see stem from the sub-optimal event dispatching mechanism in JavaFX, the weirdest part of which is creating multiple event instances for the same event. 

You've mentioned this a number of times.

Events are copied because FX uses the **source** field to indicate where the receiving event handled was attached.  As it bubbles down, the source field must be updated if you want it to contain the correct value.  This is actually a performance optimization for cases where a single listener can be attached to say all table cells, and use the `source` field to distinguish which cell was involved.

It's worth noting that this is actually contrary to how the source field is documented in Event's superclass `EventObject`.
 
A better solution for this would have been to use a `ThreadLocal` to hold the source (or the soon to be finalized `ScopedValue`).  It may be possible to back-implement this still without introducing any incompatibilities.  It may safe a few copies (although there won't be any performance wins as even MouseMove events are simply too infrequent to matter).  Events would still not be fully immutable though as they still have the consumed flag, and custom implementations could allow for tracking additional information (like "ifNotConsumed" actions).

> The key events should be targeting the keyboard focus owner, in case of the Spinner and similar controls, the TextField inside of it. "Control" and "Skin" are abstractions that have nothing to do with that, and the Spinner itself might conceptually be a part of some other custom control.

I disagree.  The Control is intended to function as single encapsulated unit.  Its substructure is pure happenstance, and any control (no matter how complex) could choose to not use any sub-controls at all but completely implement them anew.  The use of sub-controls is for implementation convenience and reuse, but should not be exposed to users. They reason about a `ComboBox` as a single unit.  How such a control handles events is up to it (it could for example choose not to forward events at all, but instead directly alter its sub-controls).  The forwarding of events here is again for convenience and re-use, not because we want users to see or directly interact with those events, they are part of the black box that a Control embodies.

What Spinner and related controls currently do is taking a poorly constructed short-cut to do as little work as possible to make the Spinner work (poorly duplicating events, and re-firing them at the top level).  They didn't have to do it this way at all.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3146475509

From quizynox at gmail.com  Sat Aug  2 16:42:31 2025
From: quizynox at gmail.com (mkpaz)
Date: Sat, 2 Aug 2025 20:42:31 +0400
Subject: RichTextArea feedback and suggestions
Message-ID: <25939b0e-cd09-41c5-94a7-24ef0e6ea1d0@gmail.com>

Hello,

I?ve been testing the new RichTextArea control and encountered a few 
issues. Some may not be bugs, though I couldn't find existing reports, 
so I?m sharing them here.

- The cursor doesn?t change from TEXT to DEFAULT when hovering over the 
scrollbar.

https://drive.google.com/file/d/1ob_2d-abI4F0bVoNWVS6d51rwYTt3-1n/view?usp=drive_link

- Setting font-family doesn?t work in CoreArea (but works in RichTextArea)

.rich-text-area .content,? // only this line works
.code-area .content,
.code-area .content .label,
.code-area .content TextFlow {
 ??? -fx-font-family: "JetBrains Mono";
 ??? -fx-font-size: 14px;
}

I also hope there is room left for small enhancements:

- RichParagraph.getSegments() is abstract and package-private and a part 
of public API.

 ? Judging from API it's suposed to be extensible, otherwise it's not 
possible to create a custom model.
https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model

https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java#L354

- RichTextArea lacks the ability to set common editor settings directly 
or via looked-up colors. I've created a project that brings TextMate 
support to RTA, so I'm obtaining editor's background, text color and 
highlight color from the theme settings.

https://github.com/mkpaz/tm4javafx/blob/master/tm4javafx/src/main/java/tm4javafx/richtext/StyleHelper.java#L75


Thanks for adding RichText support to JavaFX! Should I report all these 
issues in JBS?

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250802/4cf65f83/attachment.htm>

From mstrauss at openjdk.org  Sat Aug  2 19:21:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 2 Aug 2025 19:21:01 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <CY8PR10MB7265BC1811BB01FF3D81EB85E526A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <CY8PR10MB7265BC1811BB01FF3D81EB85E526A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <Q4F1vfWMI-Ni4FpG7KT0seiyf1qAA51VzBgysMJH_ZU=.618c1262-3497-4076-aefb-a42684d111a5@github.com>

On Fri, 1 Aug 2025 21:18:53 GMT, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> There is more: I think the kind of issues we see stem from the sub-optimal event dispatching mechanism in JavaFX, the weirdest part of which is creating multiple event instances for the same event. The key events should be targeting the keyboard focus owner, in case of the Spinner and similar controls, the TextField inside of it. "Control" and "Skin" are abstractions that have nothing to do with that, and the Spinner itself might conceptually be a part of some other custom control.
> 
> To answer the last two points:
> 
> 1. the leaf TextField should be the focused Node, not its parent Control, or its more complex custom control.

But that would be a bad experience for application developers. In most cases, application developers interact with a scene graph of controls. The skins are just an implementation detail that is mostly invisible, and easily changeable with a different theme.

Developers should be able to expect that when they `requestFocus()` on a control, the control will be focused. This is what JavaFX currently tries to do (but it fails to do it right). Your suggestion would be a major breaking change, it would mean that a skin arbitrarily gets to decide which node will _actually_ be focused.

This leaks an implementation detail into the user model with huge consequences: simply changing a skin becomes brittle and potentially impossible, as user code can no longer reason about controls independently from their skins. User code would no longer be able to know which node will be focused, or which node will be the target of events.

> 2. to avoid duplicate events, don't duplicate events.

Yes, this is the logical solution for your suggestion. But then observers will not be able to know that a key event is targeted at a spinner. Let's assume that a scene listener is installed that intercepts key events going to spinners. Using your suggestion, the listener would have to look whether the key event is targeted at a TextField (which is an implementation detail of a skin, and could change with another theme), and then figure out whether the parent of that TextField is a Spinner (which is another implementation detail).

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3146679812

From lkostyra at openjdk.org  Mon Aug  4 08:52:37 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 4 Aug 2025 08:52:37 GMT
Subject: RFR: 8359899: Stage.isFocused() returns invalid value when Stage fails
 to receive focus
Message-ID: <einORxJYJmPpn4dSQuVRu8rIvOvTDNf7FfgIVrTyJhU=.b6b1beb0-ef49-40ab-81fb-3cf6c4e772b7@github.com>

**NOTE:** For now I submitted this change as a DRAFT PR in order to get some feedback on whether this is the way to fix the problem, as well as to check for potential problems with this solution that I might've missed.

___

This PR fixes `isFocused()` returning invalid value when Stage fails to receive focus after calling `Stage.show()`. This problem is Windows-only.

In Windows the `SetForegroundWindow()` API lists [a set of conditions to successfully grant focus to a Window](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow#remarks). If any of the conditions are not met, the API will return FALSE. JavaFX did not respect that and instead assumed that receiving `WM_ACTIVATE` with our Window being activated is enough to assume the Window is in focus (which in some cases is not true).

I first tried reacting to `WM_SETFOCUS` and `WM_KILLFOCUS` but it seems those messages are not sent when the window is shown for the first time (instead `WM_ACTIVATE` is used).

To correct this behavior, I noticed the following path is the most reliable:
- Call `ShowWindow()` using `SW_SHOWNA` instead of `SW_SHOW` - that makes the window visible but does NOT activate it
- Call `SetForegroundWindow()` - that will attempt to give the Window focus and will also activate it if it is successful
  - If successful, Java `notifyFocus` callback will be called via `WM_ACTIVATE` handler
  - If it fails, we call the `notifyFocus` callback manually informing the upper layers the focus is lost. This establishes the correct state of `Window.focused` property.

With this change I observed that all tests pass as intended as long as two conditions are met (these are needed to satisfy `SetForegroundWindow()` restrictions):
- Gradle build is ran without the Gradle daemon
- The terminal running Gradle test is in foreground

If any of above two conditions is not met, some tests (including canary test from https://github.com/openjdk/jfx/pull/1804) now timeout/fail when checking whether `Window.isFocused()` is true.

Manually started JavaFX apps (ex. Ensemble) run as they used to and still receive focus upon Stage showing.

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

Commit messages:
 - Adjust window focus management for Windows Glass

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

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

From arapte at openjdk.org  Mon Aug  4 09:45:37 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 09:45:37 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v16]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <9zOqnBFLthJ4-kONgJClk_4vbQyktOlqomt0AzGZf2w=.5c55d995-f6f6-419e-b00b-0bfa63fac52b@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

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 20 additional commits since the last revision:

 - Update HeadlessView _getNativeFrameBuffer
 - Merge branch 'master' into impl-metal
 - kcr: review: crash regression fix
 - correct MSLBackend if check for CoreSymbols.getFunctions()
 - nir: break MTLTexture.update
 - nir: review followup
 - nir: review comments
 - lukasz: addJSL-mtl-d3d12
 - Merge branch 'master' into impl-metal
 - add comment for ES2SwapChain.getFboID
 - ... and 10 more: https://git.openjdk.org/jfx/compare/eba161b8...705d7ec7

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/3b30062e..705d7ec7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=14-15

  Stats: 12830 lines in 146 files changed: 6791 ins; 1660 del; 4379 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Mon Aug  4 10:46:37 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 10:46:37 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  kcr-andy: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/705d7ec7..95739d6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=15-16

  Stats: 18 lines in 6 files changed: 5 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Mon Aug  4 12:07:08 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 12:07:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>
Message-ID: <TCSORcchlIDTqpb8xUlWtHMrxOeEZDAdAMcBYJQJmfo=.5baf9a9f-5524-49fd-85b7-74180746e93c@github.com>

On Fri, 1 Aug 2025 22:44:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I left a few inline comments, but this looks good overall, and is almost ready to go in.
> 
> I'll approve once you've addressed Andy's and my questions and have done the merge from master and a full test.

I addressed the comments and update the PR. Verified that build and system test on Mac and Windows platform.

> build.gradle line 1699:
> 
>> 1697:         doFirst {
>> 1698:             mkdir "$project.buildDir/gensrc/mtl-headers"
>> 1699:         }
> 
> This is only needed for macOS builds. Should it be conditional?

Yes, enclosed in IS_MAC check. Verified that build works fine on Windows.

> modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1550:
> 
>> 1548:  */
>> 1549: JNIEXPORT void JNICALL Java_com_sun_prism_mtl_MTLResourceFactory_nReleaseTexture
>> 1550:     (JNIEnv *env, jclass class, jlong pTexture)
> 
> I missed the discussion on this. I presume that the native context pointer was removed because it was unused? The other pipelines pass it (probably because they need it), so I was surprised that MTL doesn't. I guess there is no harm in removing it, if it really is unneeded.

The native class MetalTexture stores reference to MetalContext when MetalTexture is created.
We can use the same reference instead of passing through this JNI method.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3150337231
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251269184
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251249652

From arapte at openjdk.org  Mon Aug  4 12:07:09 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 12:07:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <ybcEnXgosYfJFrCrh57gUbsGs1K7pGLoB__przrHnPU=.9fd84511-74ce-4821-bd5f-705f5070b272@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <n9iP5UNH454kXEdONCkfRPaTu_Bw7wVZxqxvrw1bdrM=.4e191b80-55a4-4c53-be33-4e2dd8e6610d@github.com>
 <ybcEnXgosYfJFrCrh57gUbsGs1K7pGLoB__przrHnPU=.9fd84511-74ce-4821-bd5f-705f5070b272@github.com>
Message-ID: <hNuSvD4brUrgLLhnciygum8V_AU1f7R33R3TdS4mC1E=.e6b69d2e-322b-4fca-badb-a488ed7f1b9c@github.com>

On Fri, 1 Aug 2025 22:46:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 98:
>> 
>>> 96:         try {
>>> 97:             final String shaderLibName = "msl/jfxshaders.metallib";
>>> 98:             final Class<?> clazz = Class.forName("com.sun.prism.mtl.MTLContext");
>> 
>> What is the purpose of this change? It's almost always better to reference a known class directly rather than `Class.forName(...)`, especially in this case where we're referring to ourself. I recommend reverting this change and assigning it to `MTLContext.class` directly.
>
> In case it wasn't clear from the context, I recommend changing just this one line to:
> 
> 
>             final Class<?> clazz = MTLContext.class;

Reverted the change, `forName` was a wrong choice.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251272281

From arapte at openjdk.org  Mon Aug  4 12:07:10 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 12:07:10 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <xEzLGjcWhv9IauBspqfJyeBLBCujMFiNuRFRhzcdcaE=.9982e078-a465-4f7b-8313-696fdfdda0fc@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <BGCiCZtAzg7b-l9F_HOlxKC2GmQXQHSHKtZXTUK2oBI=.dcf8ae20-afc5-4544-8a55-7c741a901c65@github.com>
 <xEzLGjcWhv9IauBspqfJyeBLBCujMFiNuRFRhzcdcaE=.9982e078-a465-4f7b-8313-696fdfdda0fc@github.com>
Message-ID: <RN_RsLzG7YCZ-noxSRtzOsUSRtUucP6FspEN_LwPBto=.6e4ab274-fac1-45b9-888c-9a1937359eb1@github.com>

On Fri, 1 Aug 2025 21:49:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLFBOTextureData.java line 34:
>> 
>>> 32: 
>>> 33:     @Override
>>> 34:     public void dispose() {
>> 
>> There is something wrong here: this method does not call `super.dispose()`.  Is it by design (a comment would be nice then).
>> 
>> The `MTLTextureData.dispose()` calls `MTLResourceFactory.releaseTexture(pTexture);` which will not be called id the context is disposed of.
>
> There is a comment just below (line 39) that explains it. Maybe adding an explicit "so no need to call super.dispose()" to the comment would be helpful.

Appended the comment as suggested.

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTextureData.java line 40:
>> 
>>> 38:                 mtlContext.flushVertexBuffer();
>>> 39:             }
>>> 40:             super.dispose();
>> 
>> since the call to `super.dispose() `is conditional, are you sure it always behaves as expected?
>
> It looks like it's probably OK, but only because the superclass method has the same check that this one does. If you care relying on that, you will want to document that assumption, although it might be cleaner to just call `super.dispose()` unconditionally.

Changed to call `super.dispose()` unconditionally. It is safe as `super.dispose()` method also has same check.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251256000
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251265785

From arapte at openjdk.org  Mon Aug  4 12:07:11 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 4 Aug 2025 12:07:11 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v15]
In-Reply-To: <CqbUhKxhH5horYNROCSElqGneDIsYey-eszzG_AaMKQ=.f2dcd088-9190-4679-8e6d-b5c9e301f1dc@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <bLKUKAqHPtGJqkhPI2boqeFZt7EO7AbUNovYAVmPHzs=.990c3e1f-b235-484f-9bbc-b28f835b7c7d@github.com>
 <CqbUhKxhH5horYNROCSElqGneDIsYey-eszzG_AaMKQ=.f2dcd088-9190-4679-8e6d-b5c9e301f1dc@github.com>
Message-ID: <jE-f6_6ck7FCIa36nz0FhepcGDIvf9IrQCNmvNa5slE=.bcc315ac-5a19-4a93-822c-42af91e9cf8b@github.com>

On Fri, 1 Aug 2025 17:29:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr: review: crash regression fix
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTextureData.java line 46:
> 
>> 44:     }
>> 45: 
>> 46:     public void setResource(long resource) {
> 
> is this method needed?
> 
> (I don't see it being called, but I don't have all the sources added to the project in eclipse).

Yes, the method was unused. Removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2251266135

From andy.goryachev at oracle.com  Mon Aug  4 15:21:16 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 4 Aug 2025 15:21:16 +0000
Subject: RichTextArea feedback and suggestions
In-Reply-To: <25939b0e-cd09-41c5-94a7-24ef0e6ea1d0@gmail.com>
References: <25939b0e-cd09-41c5-94a7-24ef0e6ea1d0@gmail.com>
Message-ID: <CY8PR10MB726545F1C5DADDA053FD94C4E523A@CY8PR10MB7265.namprd10.prod.outlook.com>

Thank you for trying out the RichTextArea and the kind words!  Your feedback is invaluable.

Yes, we want to create the JSB tickets for the actual bugs.  Please allow me some time to get back to you.

Thanks,
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of mkpaz <quizynox at gmail.com>
Date: Saturday, August 2, 2025 at 09:42
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea feedback and suggestions
Hello,

I?ve been testing the new RichTextArea control and encountered a few issues. Some may not be bugs, though I couldn't find existing reports, so I?m sharing them here.

- The cursor doesn?t change from TEXT to DEFAULT when hovering over the scrollbar.

https://drive.google.com/file/d/1ob_2d-abI4F0bVoNWVS6d51rwYTt3-1n/view?usp=drive_link
- Setting font-family doesn?t work in CoreArea (but works in RichTextArea)

.rich-text-area .content,  // only this line works
.code-area .content,
.code-area .content .label,
.code-area .content TextFlow {
    -fx-font-family: "JetBrains Mono";
    -fx-font-size: 14px;
}

I also hope there is room left for small enhancements:

- RichParagraph.getSegments() is abstract and package-private and a part of public API.
  Judging from API it's suposed to be extensible, otherwise it's not possible to create a custom model.
  https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model

https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java#L354

- RichTextArea lacks the ability to set common editor settings directly or via looked-up colors. I've created a project that brings TextMate support to RTA, so I'm obtaining editor's background, text color and highlight color from the theme settings.

https://github.com/mkpaz/tm4javafx/blob/master/tm4javafx/src/main/java/tm4javafx/richtext/StyleHelper.java#L75



Thanks for adding RichText support to JavaFX! Should I report all these issues in JBS?
Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250804/67ea0b2e/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Aug  4 15:59:57 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 4 Aug 2025 15:59:57 +0000
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <9coKohSy16HPts5K2eRswCBpPqcKdH6V-XDgg0VLxGI=.cddd9f20-6d17-4e94-8783-91656258b6fc@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>
 <9coKohSy16HPts5K2eRswCBpPqcKdH6V-XDgg0VLxGI=.cddd9f20-6d17-4e94-8783-91656258b6fc@github.com>
Message-ID: <CY8PR10MB72657F4FB1D8D74C3DA1F454E523A@CY8PR10MB7265.namprd10.prod.outlook.com>

John,

Thank you for continuing this discussion.  This particular response might need its own thread and a topic (FocusTraversalPolicy).

I want to emphasize that JavaFX should provide support for "crazy" as you put it requirements.  In my experience, the world of enterprise software is full of "crazy" requirements that have solid business justification.  I already presented a use case ("skip to item 25 if you answered no here"), and it cannot / should not be implemented by disabling the control, as the input fields still need to be editable.

And no, there are always use cases that the stock JavaFX implementation cannot support and the application developers need a way to implement then, preferably via some easy-to-understand API.  The FocusTraversalPolicy is one such API that solves the problems of skin and application developers nicely, with an easy to understand API.  Providing a geometry-based focus traversal (and the other usual navigation schemes) **may not be enough**.  The real world requirements are more complicated that any JavaFX developer, even the smartest ones, can imagine.

-andy

P.S.  I realized that my example may be not entirely clear if one has not encountered such scenarios before.  I'll try to provide a more clear one in a separate thread.


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <jhendrikx at openjdk.org>
Date: Saturday, August 2, 2025 at 05:10
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>
>   Avoid variable reassignment

> _Mailing list message from [Andy Goryachev](mailto:andy.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at mail.openjdk.org):_
>
> My Swing is a bit rusty now, but I think it managed to handle geometry-based navigation just fine. But it is not the reason I refer to Swing's FocusTraversalPolicy.
>
> The application requirements might call for traversal that is governed not only by geometry, but also by the state of the UI in general, even dynamic, based on the information already entered by the user (as in "skip to item 25 if you answered "no" here).

This can easily be handled by disabling the controls that are not relevant when "no" was answered.  This can be done dynamically and something that most UI's have been doing already since UI's were invented (I remember doing this in the early 90's).  This is not a good enough reason to offer an alternative (and not complimentary) focus traversal mechanism.

If for some reason those controls must remain "enabled", you can instead of disabling them remove their focus traversable flag -- note that you're actively confusing the user then though.

> The value of the Parent.traversalPolicy is not only that it helps with composite controls and skins, but also that it enables the application developers to implement whatever crazy requirements they might have.

FX shouldn't cater to crazy requirements; for inclusion in FX, this must be a **common** requirement, while offering sufficient power for "crazy" requirements.  FX makes the common cases easy (I rarely find fault with FX's default focus traversal), and there's more than sufficient controls available to support more exotic requirements.

> Also, the FocusTraversalPolicy (whatever form it eventually might take) is not a foreign concept transplanted from an older system. JavaFX, in fact, already has these policies internally implemented, offering a small, but important benefit of not altering the behavior of the existing code.

Yes, and almost universally when I encounter its usage in the behavior/skins, they actually show a lack of understanding of how FX works, or are no longer relevant as FX evolved.  I'm very sure we can remove the entire internal system (think of how much code that would safe, and how similar the user model then becomes for their own skins) and not lose any functionality by just using what FX offers with regards to focus traversal.  One of the biggest stumbling blocks for this has been removed already (see #1582 ).

As you didn't share any use cases that are even remotely common, it is still hard for me to imagine why we need an alternative navigation system when JavaFX's system out-of-the-box was by default 10x better than what Swing offered before it introduced the focus traversal policy.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3146464405
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250804/35b29e5e/attachment.htm>

From kcr at openjdk.org  Mon Aug  4 16:06:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 4 Aug 2025 16:06:21 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
Message-ID: <XFnE8pPLGhlqfzggOwV8n54oBXEiKV28drZwb_8vEg8=.90fb4664-b94b-4737-a37f-735a4dbbc257@github.com>

On Mon, 4 Aug 2025 10:46:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr-andy: review comments

I did a quick test build on Windows and I see the following non-fatal error:


> Task :graphics:generateDecoraShaders
Custom actions are attached to task ':graphics:generateDecoraShaders'.
Caching disabled for task ':graphics:generateDecoraShaders' because:
  Build cache is disabled
  Gradle would require more information to cache this task
Task ':graphics:generateDecoraShaders' is not up-to-date because:
  No history is available.
Starting process 'command 'jdk-24.0.2\bin\java.exe''. Working directory: jfx\modules\javafx.graphics Command: jdk-24.0.2\bin\java.exe --module-path=jfx\modules\javafx.graphics\build\classes\java\main;jfx/modules/javafx.base/build/classes/java/main --add-modules=javafx.graphics --add-exports=javafx.graphics/com.sun.scenario.effect=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.scenario.effect.light=ALL-UNNAMED --add-exports=javafx.graphics/com.sun.scenario.effect.impl.state=ALL-UNNAMED -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp jfx\modules\javafx.base\build\libs\base.jar;.gradle\caches\modules-2\files-2.1\org.antlr\antlr4\4.7.2\34fc363424d3b060b660f84974a82d6bdc7ebe0c\antlr4-4.7.2-complete.jar;jfx\modules\javafx.graphics\build\classes\java\jslc;jfx\modules\javafx.graphics\src\jslc\resources;jfx\modules\javafx.graphics\build\classes\jsl-compilers\decora GenAllDecoraShaders -i jfx\modules\javafx.graphics\src\main\jsl-decora -o jfx\modules\javafx.gra
 phics\build\gensrc\jsl-decora -t -pkg com/sun/scenario/effect -all GenAllDecoraShaders
Successfully started process 'command 'jdk-24.0.2\bin\java.exe''
IOException occurred while creating FragmentShaderCommon.h: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\FragmentShaderCommon.h (The system cannot find the path specified)
java.io.FileNotFoundException: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\FragmentShaderCommon.h (The system cannot find the path specified)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(FileOutputStream.java:255)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:210)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:120)
	at java.base/java.io.FileWriter.<init>(FileWriter.java:67)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.writeFragmentShaderHeader(MSLBackend.java:498)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.setShaderNameAndHeaderPath(MSLBackend.java:470)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:234)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:191)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:158)
	at CompileJSL.main(CompileJSL.java:75)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at GenAllDecoraShaders.main(GenAllDecoraShaders.java:53)
An error occurred.
java.io.FileNotFoundException: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\DecoraShaderCommon.h (The system cannot find the path specified)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(FileOutputStream.java:255)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:210)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:120)
	at java.base/java.io.FileWriter.<init>(FileWriter.java:67)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.updateCommonHeaders(MSLBackend.java:314)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.getShader(MSLBackend.java:429)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:236)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:191)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:158)
	at CompileJSL.main(CompileJSL.java:75)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at GenAllDecoraShaders.main(GenAllDecoraShaders.java:53)
An error occurred.
...  (repeated many times)

> Task :graphics:generatePrismShaders
Custom actions are attached to task ':graphics:generatePrismShaders'.
Caching disabled for task ':graphics:generatePrismShaders' because:
  Build cache is disabled
  Gradle would require more information to cache this task
Task ':graphics:generatePrismShaders' is not up-to-date because:
  No history is available.
Starting process 'command 'jdk-24.0.2\bin\java.exe''. Working directory: jfx\modules\javafx.graphics Command: jdk-24.0.2\bin\java.exe -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp jfx\modules\javafx.base\build\libs\base.jar;.gradle\caches\modules-2\files-2.1\org.antlr\antlr4\4.7.2\34fc363424d3b060b660f84974a82d6bdc7ebe0c\antlr4-4.7.2-complete.jar;jfx\modules\javafx.graphics\build\classes\java\jslc;jfx\modules\javafx.graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\prism\PrismGlue.stg;jfx\modules\javafx.graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\sw\java\JSWGlue.stg;jfx\modules\javafx.graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\sw\me\MEJavaGlue.stg;jfx\modules\javafx.graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\sw\me\MENativeGlue.stg;jfx\modules\javafx.graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\sw\sse\SSEJavaGlue.stg;jfx\modules\javafx
 .graphics\src\jslc\resources\com\sun\scenario\effect\compiler\backend\sw\sse\SSENativeGlue.stg;jfx\modules\javafx.graphics\build\classes\jsl-compilers\prism;jfx\modules\javafx.graphics\src\main\jsl-prism CompileJSL -i jfx\modules\javafx.graphics\src\main\jsl-prism -o jfx\modules\javafx.graphics\build\gensrc\jsl-prism -t -pkg com/sun/prism -d3d -es2 -mtl -name jfx\modules\javafx.graphics\src\main\jsl-prism\MaskAlphaOne.jsl
Successfully started process 'command 'jdk-24.0.2\bin\java.exe''
IOException occurred while creating FragmentShaderCommon.h: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\FragmentShaderCommon.h (The system cannot find the path specified)
java.io.FileNotFoundException: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\FragmentShaderCommon.h (The system cannot find the path specified)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(FileOutputStream.java:255)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:210)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:120)
	at java.base/java.io.FileWriter.<init>(FileWriter.java:67)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.writeFragmentShaderHeader(MSLBackend.java:498)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.setShaderNameAndHeaderPath(MSLBackend.java:470)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:234)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:191)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:151)
	at CompileJSL.compileShader(CompileJSL.java:422)
	at CompileJSL.compileShader(CompileJSL.java:414)
	at CompileJSL.compileColorPaint(CompileJSL.java:248)
	at CompileJSL.main(CompileJSL.java:481)
An error occurred.
java.io.FileNotFoundException: jfx\modules\javafx.graphics\build\gensrc\mtl-headers\PrismShaderCommon.h (The system cannot find the path specified)
	at java.base/java.io.FileOutputStream.open0(Native Method)
	at java.base/java.io.FileOutputStream.open(FileOutputStream.java:255)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:210)
	at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:120)
	at java.base/java.io.FileWriter.<init>(FileWriter.java:67)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.updateCommonHeaders(MSLBackend.java:314)
	at com.sun.scenario.effect.compiler.backend.hw.MSLBackend.getShader(MSLBackend.java:429)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:236)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:191)
	at com.sun.scenario.effect.compiler.JSLC.compile(JSLC.java:151)
	at CompileJSL.compileShader(CompileJSL.java:422)
	at CompileJSL.compileShader(CompileJSL.java:414)
	at CompileJSL.compileColorPaint(CompileJSL.java:248)
	at CompileJSL.main(CompileJSL.java:481)
An error occurred.
...  (repeated many times)

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3151365650

From kcr at openjdk.org  Mon Aug  4 16:27:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 4 Aug 2025 16:27:13 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
Message-ID: <YttbnR3HZg3Ya2SIq5FAAksGxJnMX94ZecRL7Vp5XEE=.8db8e508-677f-4a39-955d-63058d9d529c@github.com>

On Mon, 4 Aug 2025 10:46:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr-andy: review comments

I did verify that the exception is harmless: the output artifacts written to the `build` directory on Windows are the same with and without this patch.

So this is just compile-time noise. It would be nice to fix it before integration if not too difficult (else a follow-up bug would be OK).

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3151435595

From nlisker at openjdk.org  Mon Aug  4 16:51:09 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 4 Aug 2025 16:51:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
Message-ID: <MCI8ow6dNse_NmA2U8EE1CnGE9y82ARw9iRRHriv16E=.91b3fdbb-82df-4e91-b0d9-2056867bf244@github.com>

On Mon, 4 Aug 2025 10:46:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr-andy: review comments

I'll try to do a second pass on the Java section changes later today. A quick look shows no concerns on my part.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3151520630

From jhendrikx at openjdk.org  Mon Aug  4 19:34:14 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 4 Aug 2025 19:34:14 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <CY8PR10MB72657F4FB1D8D74C3DA1F454E523A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <CY8PR10MB72657F4FB1D8D74C3DA1F454E523A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <-O6U5N3XFgr1zfFOy_Wo4IqNsMBLnDYcXJ-TIWEJHis=.db9169b9-5658-4941-9d64-a6fdf260566f@github.com>

On Mon, 4 Aug 2025 16:01:54 GMT, Andy Goryachev <andy.goryachev at oracle.com> wrote:

> John,
> 
> Thank you for continuing this discussion. This particular response might need its own thread and a topic (FocusTraversalPolicy).
> 
> I want to emphasize that JavaFX should provide support for "crazy" as you put it requirements. In my experience, the world of enterprise software is full of "crazy" requirements that have solid business justification.

Andy, fine.  However, this is a quote from you, emphasis mine:

> The value of the Parent.traversalPolicy is not only that it helps with composite controls and skins, but also that it enables the application developers to implement **whatever crazy requirements** they might have.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3152087568

From arapte at openjdk.org  Tue Aug  5 01:05:01 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 01:05:01 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v18]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <DSW9kHiviC_QlYmwFHZZl52LvQekcDVtegCZ9ZprTVg=.5bef1d8f-fba8-473b-88f3-f5d23b1dda59@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  remove IS_MAC check

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/95739d6f..78c90b5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=16-17

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

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

From arapte at openjdk.org  Tue Aug  5 01:13:21 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 01:13:21 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <YttbnR3HZg3Ya2SIq5FAAksGxJnMX94ZecRL7Vp5XEE=.8db8e508-677f-4a39-955d-63058d9d529c@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <YttbnR3HZg3Ya2SIq5FAAksGxJnMX94ZecRL7Vp5XEE=.8db8e508-677f-4a39-955d-63058d9d529c@github.com>
Message-ID: <AVDvnp-iNqRfgIK-et7WJwPKGHZSKsElfmOr7Y5ERyk=.a5f9a8ec-e202-48cf-9d06-cd34fe514cac@github.com>

On Mon, 4 Aug 2025 16:23:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> So this is just compile-time noise. It would be nice to fix it before integration if not too difficult (else a follow-up bug would be OK).

It is happening due the the IS_MAC check added to build.gradle file in this commit : https://github.com/openjdk/jfx/pull/1824/commits/95739d6f4ccff6dbbaaee986451cdd0c40dea5c1
Root cause is that we generate the shaders on all platforms, Modifying this existing behavior as part of the Metal implementation may not be appropriate and needs more investigation to build.gradle. I shall file a follow-up bug for this.
Reverted the IS_MAC change, it removes the error message.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3152934358

From arapte at openjdk.org  Tue Aug  5 04:27:20 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 04:27:20 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <AVDvnp-iNqRfgIK-et7WJwPKGHZSKsElfmOr7Y5ERyk=.a5f9a8ec-e202-48cf-9d06-cd34fe514cac@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <YttbnR3HZg3Ya2SIq5FAAksGxJnMX94ZecRL7Vp5XEE=.8db8e508-677f-4a39-955d-63058d9d529c@github.com>
 <AVDvnp-iNqRfgIK-et7WJwPKGHZSKsElfmOr7Y5ERyk=.a5f9a8ec-e202-48cf-9d06-cd34fe514cac@github.com>
Message-ID: <9HbHBEpTz3o8D3OfJzKHcGQKf_tL_gTkssREuiB2ULE=.f53d2e4c-670b-49f8-9389-d7c0f5034def@github.com>

On Tue, 5 Aug 2025 01:10:15 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> So this is just compile-time noise. It would be nice to fix it before integration if not too difficult (else a follow-up bug would be OK).

The follow-up issue : [JDK-8357625](https://bugs.openjdk.org/browse/JDK-8357625)

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3153245347

From arapte at openjdk.org  Tue Aug  5 04:46:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 04:46:29 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v19]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <zMLBUARph98Ydf7bLD0tXmp_rhVQQGt-gLmKTu28e4o=.5b0587de-9a73-4285-beaa-990930bf1946@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  SwapChain.setOpaque/isOpaque comment JDK-8364672

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/78c90b5a..4602bc3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=18
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=17-18

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

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

From arapte at openjdk.org  Tue Aug  5 05:56:20 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 05:56:20 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
Message-ID: <8buh87PL2Nmv5MT8dk_BbPZMk7rz0Bev_qYtmsXjogo=.5e39f034-0aa1-499b-918f-a08e86e8fe67@github.com>

On Fri, 25 Jul 2025 19:49:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into impl-metal
>>  - add comment for ES2SwapChain.getFboID
>>  - remove MTLLog
>>  - andy review comments 1
>>  - changes for running apps in eclipse
>>  - review-update: jni method refactoring
>>  - add @Override
>>  - minor cleanup changes in glass
>>  - Use appropriate layer for setting opacity
>>  - Glass changes after Metal PR inputs
>>  - ... and 2 more: https://git.openjdk.org/jfx/compare/feb5d598...1a9a0a41
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 166:
> 
>> 164: 
>> 165:     @Override
>> 166:     public void setOpaque(boolean opaque) {
> 
> Should we warn somehow about this no-op? It could be confusing for the caller for this to "fail" silently.

Filed [JDK-8364672](https://bugs.openjdk.org/browse/JDK-8364672) for investigating this for all pipelines.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2253204519

From duke at openjdk.org  Tue Aug  5 08:33:51 2025
From: duke at openjdk.org (=?UTF-8?B?Q2zDqW1lbnQ=?= de Tastes)
Date: Tue, 5 Aug 2025 08:33:51 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless
Message-ID: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>

Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.

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

Commit messages:
 - Allow headless (lowercase)

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

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

From nlisker at openjdk.org  Tue Aug  5 08:57:22 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 5 Aug 2025 08:57:22 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
Message-ID: <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>

On Mon, 4 Aug 2025 10:46:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kcr-andy: review comments

modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 78:

> 76:     private boolean hasTextureVar;
> 77: 
> 78:     private final List<String> helperFunctions = new ArrayList<>();;

Double `;`

modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 170:

> 168:         "ddx",     "dfdx",
> 169:         "ddy",     "dfdy",
> 170:         "intcast", "int");

Not that it matters probably, but why are these immutable maps and not switches? If we know all the strings at compile time and the structure is used only for key-based retrievals, we're not gaining anything with a map.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPipeline.java line 90:

> 88: 
> 89:             // This enables sharing of MTLCommandQueue between PRISM and GLASS
> 90:             Map<String, Long> devDetails = MTLPipeline.getInstance().getDeviceDetails();

`getDeviceDetails()` returns a raw `Map`, but here it's cast to `Map<String, Long>`. Is it safe? We probably want to fix it in `GraphicsPipelin`.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 193:

> 191: 
> 192:         MTLTextureData textData = new MTLTextureData(context, pResource, size);
> 193:         MTLTextureResource<MTLTextureData> resource = new MTLTextureResource(textData, true);

`MTLTextureResource` is raw -> `MTLTextureResource<>`

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 197:

> 195:         // contentX and contentY is set as 0 unlike D3D/ES2.
> 196:         // The wrap mode are addressed, can be mapped to D3D/ES2 only if necessary.
> 197:         return new MTLTexture(getContext(), resource, formatHint, wrapMode, allocw, alloch, 0, 0, allocw, alloch, useMipmap);

Same raw type.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 149:

> 147:                     for (int colIndex = 0; colIndex < rowStride; colIndex += 3) {
> 148:                         index = rowIndex + colIndex;
> 149:                         arr32Bit[dstIndex++] = arr[index + 2];

`arr` might be `null` here if `buf.hasArray() == false`, resulting in an NPE.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 174:

> 172:                     for (int colIndex = 0; colIndex < srcw; colIndex++) {
> 173:                         index = rowIndex + colIndex;
> 174:                         arr32Bit[dstIndex++] = arr[index];

Same here.

modules/javafx.graphics/src/main/jsl-decora/GenAllDecoraShaders.java line 50:

> 48:         for (int i = 0; i < compileShaders.length; i++) {
> 49:             args[7] = compileShaders[i][1];
> 50:             args[8] = compileShaders[i][2];

I'd add a comment to `args[7]` and 8 because it's not clear what these are and where `args` is coming from since a `main` method can be invoked from everywhere.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252690093
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252699423
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252715145
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252718882
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252720009
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2253497317
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2253498081
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2253617601

From nlisker at openjdk.org  Tue Aug  5 08:57:24 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 5 Aug 2025 08:57:24 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>
Message-ID: <BFGIzdexd_qWqjDGRfDd5PvSij6xOLYllmS0SfAgWIQ=.cdee1712-1839-4a4e-9566-c88c2aafecb5@github.com>

On Tue, 29 Jul 2025 16:34:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMeshView.java line 40:
>> 
>>> 38:     private final long nativeHandle;
>>> 39: 
>>> 40:     final private MTLMesh mesh;
>> 
>> `mesh` is unused. Is it awaiting a dereference in `dispose()`?
>
> Yes, MTLMesh can be shared by multiple MTLMeshView.

I'm not sure I understand where is it used? I see that the same `MTLMesh` can be passed to multiple `MTLMeshView`s, but what do they do with it?

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTexture.java line 39:
>> 
>>> 37: import com.sun.prism.mtl.MTLTexture;
>>> 38: import com.sun.prism.mtl.MTLTextureData;
>>> 39: import com.sun.prism.mtl.MTLTextureResource;
>> 
>> Unused
>
> MTLTextureResource is used in this class

import com.sun.prism.mtl.MTLContext;
import com.sun.prism.mtl.MTLTexture;
import com.sun.prism.mtl.MTLTextureData;
import com.sun.prism.mtl.MTLTextureResource;

Since they are from the same package, the FQN of these types is known, hence these imports are unused (even if the types are). If you remove these you shouldn't get any compilation error,

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252706415
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252723807

From nlisker at openjdk.org  Tue Aug  5 08:57:26 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 5 Aug 2025 08:57:26 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
Message-ID: <LJkm3Apf0qQksK-jU1TogORJUOsdsvb-wFvd5y6-YAg=.9e8740e7-61bc-4d78-9d5b-a9c7c3d6c475@github.com>

On Fri, 25 Jul 2025 19:51:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into impl-metal
>>  - add comment for ES2SwapChain.getFboID
>>  - remove MTLLog
>>  - andy review comments 1
>>  - changes for running apps in eclipse
>>  - review-update: jni method refactoring
>>  - add @Override
>>  - minor cleanup changes in glass
>>  - Use appropriate layer for setting opacity
>>  - Glass changes after Metal PR inputs
>>  - ... and 2 more: https://git.openjdk.org/jfx/compare/86b80ad2...1a9a0a41
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 79:
> 
>> 77: 
>> 78:     // We don't handle mipmap in shared texture yet.
>> 79:     private MTLTexture(MTLTexture sharedTex, WrapMode newMode) {
> 
> Raw type

Still needs to be parametrized to `MTLTexture<T>`.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 87:
> 
>> 85:     @Override
>> 86:     protected Texture createSharedTexture(WrapMode newMode) {
>> 87:         return new MTLTexture(this, newMode);
> 
> Raw type

Same, needs to be `MTLTexture<>`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252737345
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2252738596

From kcr at openjdk.org  Tue Aug  5 11:42:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Aug 2025 11:42:12 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless
In-Reply-To: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
Message-ID: <lydbbBWgsqooWhIo6VN8VHLgaQADhyvMXyCtSgQjjUA=.4564066a-ecb7-4baa-a921-1682a8b7006e@github.com>

On Tue, 5 Aug 2025 07:45:34 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.

Reviewer: @johanvos

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3154855116

From duke at openjdk.org  Tue Aug  5 11:45:50 2025
From: duke at openjdk.org (=?UTF-8?B?Q2zDqW1lbnQ=?= de Tastes)
Date: Tue, 5 Aug 2025 11:45:50 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
Message-ID: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>

> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.

Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:

  remove additional space

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1864/files
  - new: https://git.openjdk.org/jfx/pull/1864/files/069d9615..91d6076d

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

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

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

From arapte at openjdk.org  Tue Aug  5 14:18:01 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 14:18:01 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v20]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <2oWVjS4PmkG4mwdXz1ef6g_OcrJdqjtoChnsVyrc1YA=.6fca0be1-37fa-4702-9cba-6693c6602dae@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  nir: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/4602bc3b..eb63c223

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=18-19

  Stats: 19 lines in 6 files changed: 6 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Tue Aug  5 14:18:03 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 14:18:03 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v19]
In-Reply-To: <zMLBUARph98Ydf7bLD0tXmp_rhVQQGt-gLmKTu28e4o=.5b0587de-9a73-4285-beaa-990930bf1946@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <zMLBUARph98Ydf7bLD0tXmp_rhVQQGt-gLmKTu28e4o=.5b0587de-9a73-4285-beaa-990930bf1946@github.com>
Message-ID: <1b-EUCKm_JZByqwXlJhF3Is3bQD2zUjh_1oALCb92rY=.f08669f5-9bde-494c-8b19-dadf9be6acdd@github.com>

On Tue, 5 Aug 2025 04:46:29 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SwapChain.setOpaque/isOpaque comment JDK-8364672

@nlisker Updated the PR to address the comments.

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3087783900

From arapte at openjdk.org  Tue Aug  5 14:18:05 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 14:18:05 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>
Message-ID: <kFwHtaI4lTnDc9fkiw_QCsgYpKUTAqnVmg5A4d5CfHs=.d413d860-4cd2-4762-aa20-846b0742c006@github.com>

On Mon, 4 Aug 2025 22:26:29 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr-andy: review comments
>
> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 170:
> 
>> 168:         "ddx",     "dfdx",
>> 169:         "ddy",     "dfdy",
>> 170:         "intcast", "int");
> 
> Not that it matters probably, but why are these immutable maps and not switches? If we know all the strings at compile time and the structure is used only for key-based retrievals, we're not gaining anything with a map.

We have maps for similar classes GLSLBackend and HLSLBackend. It seems good maintain the similarity.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPipeline.java line 90:
> 
>> 88: 
>> 89:             // This enables sharing of MTLCommandQueue between PRISM and GLASS
>> 90:             Map<String, Long> devDetails = MTLPipeline.getInstance().getDeviceDetails();
> 
> `getDeviceDetails()` returns a raw `Map`, but here it's cast to `Map<String, Long>`. Is it safe? We probably want to fix it in `GraphicsPipelin`.

The Map is created by the `MTLPipeline` class itself and passed to super class `GraphicsPipeline`. As we know the exact type, it is safe.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 149:
> 
>> 147:                     for (int colIndex = 0; colIndex < rowStride; colIndex += 3) {
>> 148:                         index = rowIndex + colIndex;
>> 149:                         arr32Bit[dstIndex++] = arr[index + 2];
> 
> `arr` might be `null` here if `buf.hasArray() == false`, resulting in an NPE.

We use non-direct buffers, so it is very unlikely case. But adding a recovery path seems right thing for now.
Eventually we should evaluate if the buffer is always non-direct then hasArray check can be removed from all pipelines. I shall file a followup bug for this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2254006543
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2254015712
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2254133522

From arapte at openjdk.org  Tue Aug  5 14:18:06 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 14:18:06 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <BFGIzdexd_qWqjDGRfDd5PvSij6xOLYllmS0SfAgWIQ=.cdee1712-1839-4a4e-9566-c88c2aafecb5@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>
 <BFGIzdexd_qWqjDGRfDd5PvSij6xOLYllmS0SfAgWIQ=.cdee1712-1839-4a4e-9566-c88c2aafecb5@github.com>
Message-ID: <Lu_n8c-MnQ1dOO0mWclvgSHpqpU5sXyJY0YbEz12XrY=.d63991c6-5314-4448-85e4-106068bed384@github.com>

On Mon, 4 Aug 2025 22:32:40 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Yes, MTLMesh can be shared by multiple MTLMeshView.
>
> I'm not sure I understand where is it used? I see that the same `MTLMesh` can be passed to multiple `MTLMeshView`s, but what do they do with it?

MTLMesh is the geometry i.e. vertex buffer, index buffer required to render a 3D Shape. So, if we create say 10 Spheres as `Sphere(50)`, then it creates 10 MTLMeshView and only 1 MTLMesh shared among MTLMeshView.

The mesh is used on native side, Please check MetalMesh.render() method in the PR. 
This aligns very much with D3DMesh, ES2Mesh.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2253993865

From kcr at openjdk.org  Tue Aug  5 16:26:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Aug 2025 16:26:22 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v20]
In-Reply-To: <2oWVjS4PmkG4mwdXz1ef6g_OcrJdqjtoChnsVyrc1YA=.6fca0be1-37fa-4702-9cba-6693c6602dae@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <2oWVjS4PmkG4mwdXz1ef6g_OcrJdqjtoChnsVyrc1YA=.6fca0be1-37fa-4702-9cba-6693c6602dae@github.com>
Message-ID: <vYSQyBntODpCldnONb16vNQA8qfhOMo7U-6YFbHrc_Q=.cd6191e2-4c2f-4253-ba91-e6ca7335895e@github.com>

On Tue, 5 Aug 2025 14:18:01 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nir: review comments

Most of the cleanup changes look good. I left an inline comment about one that I think needs to be reverted.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 133:

> 131:             arr = new byte[buf.remaining()];
> 132:             buf.get(arr);
> 133:         }

I instrumented the code, and found that `updateTextureByte` is sometimes called with a direct byte buffer, which means that `buf.hasArray()` returns false. In the cases I tested, the format is `BYTE_ALPHA`, so without your change it will correctly call the native method with a null array and the direct byte buffer. This will cause the native method to use the optimized path. With this change, we now create a new byte array, copy from the direct byte buffer to that array, and pass that to the native method. This isn't what we want.

I think you should revert this change, and move the array allocation / copy code to the cases that actually need it. The revert needs to happen now. The allocation / copy code could be done either now or via a follow-up bug.

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3088903402
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2254777222

From kcr at openjdk.org  Tue Aug  5 16:26:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Aug 2025 16:26:23 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <kFwHtaI4lTnDc9fkiw_QCsgYpKUTAqnVmg5A4d5CfHs=.d413d860-4cd2-4762-aa20-846b0742c006@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>
 <kFwHtaI4lTnDc9fkiw_QCsgYpKUTAqnVmg5A4d5CfHs=.d413d860-4cd2-4762-aa20-846b0742c006@github.com>
Message-ID: <I8mHkaxdOxroC0ZIoPr62CC8j1o2QW1qW8mVjG-RJcQ=.1ed5c2c5-5b33-41d6-8793-4a77794ce57b@github.com>

On Tue, 5 Aug 2025 12:00:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 149:
>> 
>>> 147:                     for (int colIndex = 0; colIndex < rowStride; colIndex += 3) {
>>> 148:                         index = rowIndex + colIndex;
>>> 149:                         arr32Bit[dstIndex++] = arr[index + 2];
>> 
>> `arr` might be `null` here if `buf.hasArray() == false`, resulting in an NPE.
>
> We use non-direct buffers, so it is very unlikely case. But adding a recovery path seems right thing for now.
> Eventually we should evaluate if the buffer is always non-direct then hasArray check can be removed from all pipelines. I shall file a followup bug for this.

The buffer is sometimes direct, so the fallback case of creating a new byte array and copying it from the buffer should only be done where it is needed. See my inline comment.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2254782421

From arapte at openjdk.org  Tue Aug  5 18:07:04 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 18:07:04 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v21]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  change buf.hasArray()

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/eb63c223..cc3dffc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=19-20

  Stats: 15 lines in 1 file changed: 8 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1824/head:pull/1824

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

From arapte at openjdk.org  Tue Aug  5 18:09:21 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 5 Aug 2025 18:09:21 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v20]
In-Reply-To: <vYSQyBntODpCldnONb16vNQA8qfhOMo7U-6YFbHrc_Q=.cd6191e2-4c2f-4253-ba91-e6ca7335895e@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <2oWVjS4PmkG4mwdXz1ef6g_OcrJdqjtoChnsVyrc1YA=.6fca0be1-37fa-4702-9cba-6693c6602dae@github.com>
 <vYSQyBntODpCldnONb16vNQA8qfhOMo7U-6YFbHrc_Q=.cd6191e2-4c2f-4253-ba91-e6ca7335895e@github.com>
Message-ID: <RuSOWt8H5Y5G6L03ahpUBSCn90ehdzRfoulCnbbegYA=.d419a046-80a2-4865-a853-cef594b0ebb3@github.com>

On Tue, 5 Aug 2025 16:21:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   nir: review comments
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 133:
> 
>> 131:             arr = new byte[buf.remaining()];
>> 132:             buf.get(arr);
>> 133:         }
> 
> I instrumented the code, and found that `updateTextureByte` is sometimes called with a direct byte buffer, which means that `buf.hasArray()` returns false. In the cases I tested, the format is `BYTE_ALPHA`, so without your change it will correctly call the native method with a null array and the direct byte buffer. This will cause the native method to use the optimized path. With this change, we now create a new byte array, copy from the direct byte buffer to that array, and pass that to the native method. This isn't what we want.
> 
> I think you should revert this change, and move the array allocation / copy code to the cases that actually need it. The revert needs to happen now. The allocation / copy code could be done either now or via a follow-up bug.

Moved the copy code to specific cases PixelFormat.BYTE_RGB  and  PixelFormat.BYTE_GRAY.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2255001943

From martinfox656 at gmail.com  Tue Aug  5 20:01:55 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Tue, 5 Aug 2025 13:01:55 -0700
Subject: [External] : Re: Focus delegation API
In-Reply-To: <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB3013A4B3062D686CDE6C147EE55A2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXRrQwnS2cVYAPsq5migrWhRVBe97=Z0cPnR3CyGv1XLQQ@mail.gmail.com>
 <BYAPR10MB3013E5DFC75F01E81C75D817E5312@BYAPR10MB3013.namprd10.prod.outlook.com>
 <BYAPR10MB30130D898F76F636C88F423FE53C2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
Message-ID: <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>

I have some questions related to the spec. I think some of this has been addressed in the PR but not in the documentation.

- The spec discusses the focused property but what should happen with the focusVisible and focusWithin flags? I don?t think it?s a good idea to have these properties and related CSS pseudo-classes be the same across a node and all of its delegates. That would dictate that all of the nodes show their focus indicators in unison.

- How should the accessible attributes be set up in the focus owner and delegate(s)? Can the accessibility frameworks deal with multi-level delegate chains?

- In a delegate chain which node responds to input method requests? We can pass events through multiple nodes but there can only be one IM caret. Keep in mind that in macOS the caret is used for more than Asian language input. When the user toggles Caps Lock or changes the keyboard layout the system briefly displays an indicator near the caret. (The spec could say that delegating focus also delegates IM events and input request processing and leave it at that. The behavior is easier to implement than to describe.)

- This spec goes through some trouble to ensure that the target of a KeyEvent is the ComboBox/Spinner and not its TextField. But we don?t do that for mouse events. When clicking on a ComboBox (or Button or whatever) the event?s target is set to whatever object the user clicked on even if it?s an undocumented piece in the control?s skin. I would like to see a discussion on why we?re trying to hide the use of composition here when we don?t elsewhere. 

To satisfy my curiosity I briefly looked at how a few other toolkits do this.

On macOS a ComboBox is a subclass of a TextField. Internally it?s using composition but that?s not visible at the API level. GTK 3.0 uses a similar class structure (no idea what it?s doing under the hood). JavaFX does this in some cases e.g. a Button does not contain a label but is derived from Labeled.

In Windows Presentation Foundation a ComboBox is a composite control but it doesn?t create a complicated multi-focus state in the scene graph. When an editable ComboBox is given focus it transfers focus to its TextBox. Only the TextBox is considered focused by the system (in JavaFX terms it is the focus owner and is the only control with the focused property set). When a key event is processed the target is the ComboBox but there?s an additional field in the event args so you can easily discover that the original target was the TextBox. WPF does this for all events e.g. if you click on a ComboBox the event target is set to the ComboBox but the original target is set to whatever sub-element you clicked on.

Martin

> On Feb 10, 2025, at 5:12?AM, Martin Fox <martinfox656 at gmail.com> wrote:
> 
> 
>> I guess that's just the way I made it work. Implementing this in
>> Control is not something I've thought about a lot.
> 
> It was really my thought experiment to begin with. Not sure it?s even possible to do this without involving Scene and Scene knows nothing about Controls. Don?t give it another thought.
> 
>> I see no reason why a control shouldn't dynamically change what it
>> returns from getFocusDelegate(). However, there's no notification
>> mechanism that would indicate when something has changed. Would you
>> need something like Scene.focusOwner(), but instead of containing the
>> outermost focused node (like ComboBox), it contains the last node in
>> the current delegation chain (TextField)?
> 
> 
> I?ll go think about the implementation and get back to you. For now I just needed to clarify that a Node?s focus delegate can change dynamically and that there might be a chain of delegates (which is the tricky part).


From kcr at openjdk.org  Tue Aug  5 20:06:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 5 Aug 2025 20:06:17 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v21]
In-Reply-To: <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
Message-ID: <-soBsX3cwZMtgnfp8c4roSbB93rZZ9qScNa40dBnk-0=.2ef632c5-b8dc-4867-8bc6-d47269a9ee42@github.com>

On Tue, 5 Aug 2025 18:07:04 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change buf.hasArray()

All looks good now!

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3089559405

From angorya at openjdk.org  Tue Aug  5 20:29:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 5 Aug 2025 20:29:21 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v21]
In-Reply-To: <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
Message-ID: <PQ701YYwC7Acp7Qzmn-PjGNk1-8ctwloXCWlMfr7wB0=.741d14f1-85ca-4579-a9b8-f1a793ad3fba@github.com>

On Tue, 5 Aug 2025 18:07:04 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change buf.hasArray()

lgtm, I see no issues running the MT and PickTest3D.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3089619013

From andy.goryachev at oracle.com  Tue Aug  5 22:03:23 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 5 Aug 2025 22:03:23 +0000
Subject: RichTextArea feedback and suggestions
In-Reply-To: <25939b0e-cd09-41c5-94a7-24ef0e6ea1d0@gmail.com>
References: <25939b0e-cd09-41c5-94a7-24ef0e6ea1d0@gmail.com>
Message-ID: <CY8PR10MB72656A6A654309E96EB66EFCE522A@CY8PR10MB7265.namprd10.prod.outlook.com>

Responding to your earlier message, and thanks again for trying RichTextArea/CodeArea out and giving the feedback!

#1
Created ticket for the cursor issue: https://bugs.openjdk.org/browse/JDK-8364777

#2
CodeArea has the font property, which is styleable.  Use the same CSS as TextArea:

-fx-font
<font>
inherit
shorthand property for font-size, font-family, font-weight and font-style
-fx-font-family
<font-family>
inherit

-fx-font-size
<font-size>
inherit

-fx-font-style
<font-style>
inherit

-fx-font-weight
<font-weight>
inherit


Enhancements:

#3
RichParagraph::getSegments() is an implementation detail.  Of course it is possible to create a custom model, please use RichParagraph.Builder to build your paragraphs.

#4
Set common editor settings directly or via looked-up colors.

RichTextArea or CodeArea use different mechanisms for styling.  For the RichTextArea, one can use stylesheet or direct styles when building paragraph segments, please refer to RichParagraph.Builder.addWith***() methods.

The CodeArea is different, as it is essentially a plain text control with a decorator (or a syntax highlighter).  Since CodeModel supports in-memory and virtualized models, it might be more difficult to plug in syntax highlighters that work with a single, in-memory string.  One way to use the usual syntax highlighters is to create a custom model with getText() method.  The other would be to use a highlighter which only updates the parts that have been changed.

Hope this helps.  Did I miss anything?

Thanks again,
-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of mkpaz <quizynox at gmail.com>
Date: Saturday, August 2, 2025 at 09:42
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: RichTextArea feedback and suggestions
Hello,

I?ve been testing the new RichTextArea control and encountered a few issues. Some may not be bugs, though I couldn't find existing reports, so I?m sharing them here.

- The cursor doesn?t change from TEXT to DEFAULT when hovering over the scrollbar.

https://drive.google.com/file/d/1ob_2d-abI4F0bVoNWVS6d51rwYTt3-1n/view?usp=drive_link
- Setting font-family doesn?t work in CoreArea (but works in RichTextArea)

.rich-text-area .content,  // only this line works
.code-area .content,
.code-area .content .label,
.code-area .content TextFlow {
    -fx-font-family: "JetBrains Mono";
    -fx-font-size: 14px;
}

I also hope there is room left for small enhancements:

- RichParagraph.getSegments() is abstract and package-private and a part of public API.
  Judging from API it's suposed to be extensible, otherwise it's not possible to create a custom model.
  https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model

https://github.com/openjdk/jfx/blob/master/modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java#L354

- RichTextArea lacks the ability to set common editor settings directly or via looked-up colors. I've created a project that brings TextMate support to RTA, so I'm obtaining editor's background, text color and highlight color from the theme settings.

https://github.com/mkpaz/tm4javafx/blob/master/tm4javafx/src/main/java/tm4javafx/richtext/StyleHelper.java#L75



Thanks for adding RichText support to JavaFX! Should I report all these issues in JBS?
Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250805/4484cb6e/attachment-0001.htm>

From john.hendrikx at gmail.com  Tue Aug  5 23:07:20 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 6 Aug 2025 01:07:20 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB30130D898F76F636C88F423FE53C2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
Message-ID: <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>


On 05/08/2025 22:01, Martin Fox wrote:
> I have some questions related to the spec. I think some of this has been addressed in the PR but not in the documentation.
>
> - This spec goes through some trouble to ensure that the target of a KeyEvent is the ComboBox/Spinner and not its TextField. 

This is not new in this spec though.? KeyEvents are delivered to the
focused control.? The focused node has always been the Control, and not
any part of its Skin.

> But we don?t do that for mouse events. When clicking on a ComboBox (or Button or whatever) the event?s target is set to whatever object the user clicked on even if it?s an undocumented piece in the control?s skin. I would like to see a discussion on why we?re trying to hide the use of composition here when we don?t elsewhere. 

It has always been this way, and the delegation API does not change
this.? It only makes it easier to forward these events automatically to
a delegate.

However, you do touch on an interesting point.? I think Controls and
their Skins should enforce their black box for mouse events as well. As
Control does provide several interesting encapsulations already (it
makes Skin styleable properties part of its own?styleable properties for
example) it perhaps should have done this from the beginning, so that a
MouseEvent when intercepted by users will show a click on a Spinner, and
not "internal_arrow_region_2" or whatever.? The forwarded events will be
only visible to the Skin internals, and can't be intercepted by users,
and so they would never see internals.

Note that they can already do so by setting `pickOnBounds` to `true` for
the Control (control can override this property to be always true), and
forcing all children to be mouse transparent (control can monitor
children and force them to be transparent) -- it perhaps should have
been enforced to be this way from the beginning.? All that would be
needed then is to forward the event still to the correct internal target.

--John

From lkostyra at openjdk.org  Wed Aug  6 13:03:22 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 6 Aug 2025 13:03:22 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v21]
In-Reply-To: <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <T0SWUBBPtt1K1E9z0IxwX2k-TnEOHNQfhLeCeSADWzE=.fdca057a-6623-475e-ab44-1b7a7056d590@github.com>
Message-ID: <LACuatcgd3Tfs4ECylqKB6uabPkp-u8Fz15XfDmw858=.9566d6e6-e36e-4bca-b8d7-0b1a424fcf05@github.com>

On Tue, 5 Aug 2025 18:07:04 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change buf.hasArray()

LGTM, did some testing on all platforms and everything seems fine. Good work!

I would also give @nlisker a chance to verify the fixes before integrating.

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3092435303

From martinfox656 at gmail.com  Wed Aug  6 16:06:00 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 6 Aug 2025 09:06:00 -0700
Subject: [External] : Re: Focus delegation API
In-Reply-To: <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB30130D898F76F636C88F423FE53C2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
Message-ID: <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>


> On Aug 5, 2025, at 4:07?PM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> 
> On 05/08/2025 22:01, Martin Fox wrote:
>> I have some questions related to the spec. I think some of this has been addressed in the PR but not in the documentation.
>> 
>> - This spec goes through some trouble to ensure that the target of a KeyEvent is the ComboBox/Spinner and not its TextField.
> 
> This is not new in this spec though.  KeyEvents are delivered to the
> focused control.  The focused node has always been the Control, and not
> any part of its Skin.

The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It?s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).

I believe the implementation of Spinner predates focusWithin and focusVisible. I think the natural way to drive the focus indicators these days would be to use focused for the TextEdit and focus-within for the Spinner. In any case I think it?s a good idea to somehow separate these out and not force all of these flags to be set in unison across the entire delegate chain.

If we were to make the Spinner?s TextEdit the focus owner input methods would work, the focused and focus-within pseudo-classes would sort themselves out in a natural way, and the double firing of KeyEvents would go away. The downside is that you would create an information deficit during event processing; the event target would be the TextEdit and not the logical control. But that?s an existing problem that also affects mouse click events. Perhaps we should focus on closing that information gap instead.

Martin



From jvos at openjdk.org  Wed Aug  6 17:25:34 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 6 Aug 2025 17:25:34 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
Message-ID: <6tjw35DwsxlRiKCsZT6x4gkrLQx5LIhflrMR9zatfqc=.7746ee70-fa75-4cc2-ab01-7364bb0b490c@github.com>

On Tue, 5 Aug 2025 11:45:50 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove additional space

I'll check later, but I want to raise this already:
there are 2 places (in 2 different modules) where the platform checks are done: com.sun.glass.ui.platform does one (discussed here), but there is also com.sun.javafx.PlatformUtil in the javafx.base method, which now has a method `isHeadless` which returns true on either "headless" or "Headless".
I do understand the differences between the Platform.java and the PlatformUtil.java checks, but there is some overlap that I'm not sure how to address.

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3160920806

From kcr at openjdk.org  Wed Aug  6 17:35:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Aug 2025 17:35:56 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
Message-ID: <es5OdPdIkz5wSsBmiHiZX6NNOgKPKH5WUcSKs2WSXZc=.b74c2396-6815-4d8b-8b82-4e178a63aaea@github.com>

On Thu, 31 Jul 2025 15:05:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> This PR fixes numerous bugs in the handling of setMaximized() on macOS and also cleans up some issues seen when the user changes the maximized state manually.
>> 
>> - After setMaximized(false) a notifyResize event was never sent so the width and height tracked by JavaFX was wrong.
>> 
>> - During maximize and restore a series of notifyMove events were issued causing the maximized property to flip-flop during the animation.
>> 
>> - Transparent windows were being maximized by passing native screen coordinates to a routine that expected JavaFX screen coordinates so the Y axis was flipped and the window was positioned incorrectly.
>> 
>> - The restored frame is in native screen coordinates which was sent to a routine that expected flipped JavaFX coordinates. That routine corrected this by directly inspecting the call stack to see which routine was calling it.
>> 
>> - When the user maximizes or restores the window a notifyResize event was always sent immediately stating that the window was maximized even when it was not. Then a series of notifyMove events were issued causing the maximized flag to flip-flop during the animation.
>> 
>> This PR cleans all of this up. When using the setMaximized API only one notifyMove and one notifyResize event are sent and transparent windows are positioned correctly. When the user maximizes or restores manually we still see a series of notifyMove and notifyResize events but at least they all report the window?s state correctly.
>> 
>> System tests are currently being written as part of #1789. It?s hard to create a system test that catches things like the mis-alignment of maximized transparent windows so that needs to be tested manually. The reproducer attached to the bug report can be used to verify this and also to see what happens when the user toggles the maximization state manually.
>> 
>> Note that when the test programs tags something as ?unexpected? it just means it saw a property change outside of any JavaFX API call. This is actually expected if the user manipulates the window manually.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up diff against master. Tighted up system test (tested on Windows and Linux)

I did some initial testing and ran a headful test through our CI system and it looks good. I left one comment on the test and will review the native glass code changes next.

tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java line 130:

> 128: 
> 129:         Util.runAndWait(() -> stage.setMaximized(true));
> 130:         Util.waitForIdle(stage.getScene());

I know that @andy-goryachev-oracle suggested its use, but for tests that do various windowing operations (maximize, full screen, restore, etc), `waitForIdle` is too short (its on the order of 160 msec). To make the test more robust, I recommend reverting this back to the `sleep(800)` you had earlier.

Arguably, we should have a utility method for this sort of "wait for windowing changes to settle down", but we don't.

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

PR Review: https://git.openjdk.org/jfx/pull/1860#pullrequestreview-3092704505
PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2257246639

From kcr at openjdk.org  Wed Aug  6 17:35:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Aug 2025 17:35:57 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <m7OY4-NId8uGJFOmxbMKZzVboFMxUV_kAc4LCFyvzro=.17e507a8-c54a-4a75-b310-122894bf24dc@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <m7OY4-NId8uGJFOmxbMKZzVboFMxUV_kAc4LCFyvzro=.17e507a8-c54a-4a75-b310-122894bf24dc@github.com>
Message-ID: <jzNwadPO18xWvrXT95MlnnnDC6d8eedEwRMoTsieS-Q=.46063ef9-2abc-405e-b14b-9462f6156bfe@github.com>

On Wed, 30 Jul 2025 21:39:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaned up diff against master. Tighted up system test (tested on Windows and Linux)
>
> tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java line 130:
> 
>> 128: 
>> 129:         Platform.runLater(() -> stage.setMaximized(true));
>> 130:         Thread.sleep(800);
> 
> Would the `test.util.Util.waitForIdle()` be of use here?  Or `runAndWait()` ?

Yes on the runAndWait (always a good idea in cases like this where you aren't otherwise latching), but no on the change to use waitForIdle (see my other comment).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2257848016

From angorya at openjdk.org  Wed Aug  6 17:46:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 6 Aug 2025 17:46:21 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <es5OdPdIkz5wSsBmiHiZX6NNOgKPKH5WUcSKs2WSXZc=.b74c2396-6815-4d8b-8b82-4e178a63aaea@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
 <es5OdPdIkz5wSsBmiHiZX6NNOgKPKH5WUcSKs2WSXZc=.b74c2396-6815-4d8b-8b82-4e178a63aaea@github.com>
Message-ID: <MQlLJm3UDkcy_B9tEat_AXVPz5ZiUWaiUE6fb-_4l1g=.65b5094e-e9ad-4063-8377-a50aa92b5825@github.com>

On Wed, 6 Aug 2025 13:53:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaned up diff against master. Tighted up system test (tested on Windows and Linux)
>
> tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java line 130:
> 
>> 128: 
>> 129:         Util.runAndWait(() -> stage.setMaximized(true));
>> 130:         Util.waitForIdle(stage.getScene());
> 
> I know that @andy-goryachev-oracle suggested its use, but for tests that do various windowing operations (maximize, full screen, restore, etc), `waitForIdle` is too short (its on the order of 160 msec). To make the test more robust, I recommend reverting this back to the `sleep(800)` you had earlier.
> 
> Arguably, we should have a utility method for this sort of "wait for windowing changes to settle down", but we don't.

There is `Util::waitForIdle(scene, pulseCount)`.

The real question is how to account for the platform-dependent transitions (which may take some time) reliably.  Waiting for a set amount of time might work, but we have to pick a good timeout value.  Is there any other possibility?

I am ok with 800ms - it feels like it should be long enough for any transition to take place.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2257869423

From michaelstrau2 at gmail.com  Wed Aug  6 18:38:11 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 6 Aug 2025 20:38:11 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <BYAPR10MB30130D898F76F636C88F423FE53C2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
Message-ID: <CAJEpuXS6hfqNxmsqMt=QTrcygWZNveEa0JCOVjHSSTeRkBhcuw@mail.gmail.com>

> The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It?s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).
>
> I believe the implementation of Spinner predates focusWithin and focusVisible. I think the natural way to drive the focus indicators these days would be to use focused for the TextEdit and focus-within for the Spinner. In any case I think it?s a good idea to somehow separate these out and not force all of these flags to be set in unison across the entire delegate chain.
>
> If we were to make the Spinner?s TextEdit the focus owner input methods would work, the focused and focus-within pseudo-classes would sort themselves out in a natural way, and the double firing of KeyEvents would go away. The downside is that you would create an information deficit during event processing; the event target would be the TextEdit and not the logical control. But that?s an existing problem that also affects mouse click events. Perhaps we should focus on closing that information gap instead.

I think you might be onto something here:

Let's close down the "Node.setFocused" loophole, no more tampering
with the focused flag. This entails fixing TableView and other
controls that misuse this flag. With this improvement, there's only
ever going to be a single focused node in the scene graph, and
"focused == input focus" is always true.

Then we would need to redefine "Node.requestFocus()" to allow a
control to delegate the focus request to one of its descendants
instead. This means:
1. If a control accepts requestFocus(), the focusWithin flag will
_always_ be set on the control.
2. It _might_ also have the focused flag, but this is
implementation-specific and should not be relied upon.
3. Scene.focusOwner might not point to the control, but to one of its
descendants.

As a consequence, controls that now use the focused style class to
adjust their appearance (with a focus ring) should use focusWithin
instead. The same is true for user code: you should always use
focusWithin on controls, and only use focused if you're sure that you
are interested in the actual input focus owner.

Additionally, there should be an additional Event.originalTarget
property. This property will always correspond to the node that fired
the event, in the case of Spinner this would be the TextField. The
Event.target property, on the other hand, would correspond to the
logical target that an observer would expect, in our example the
Spinner.

I think this approach would still allow us to clean up the skin
implementations, remove the duplicate events, and have logically
consistent events.

From hmeda at openjdk.org  Wed Aug  6 19:02:57 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 6 Aug 2025 19:02:57 GMT
Subject: RFR: 8356982: Update WebKit to 622.1
Message-ID: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>

This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.

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

Commit messages:
 - Update webkit to v622.1

Changes: https://git.openjdk.org/jfx/pull/1865/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8356982
  Stats: 731810 lines in 8687 files changed: 290169 ins; 364225 del; 77416 mod
  Patch: https://git.openjdk.org/jfx/pull/1865.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1865/head:pull/1865

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

From mfox at openjdk.org  Wed Aug  6 19:06:24 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 6 Aug 2025 19:06:24 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <MQlLJm3UDkcy_B9tEat_AXVPz5ZiUWaiUE6fb-_4l1g=.65b5094e-e9ad-4063-8377-a50aa92b5825@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
 <es5OdPdIkz5wSsBmiHiZX6NNOgKPKH5WUcSKs2WSXZc=.b74c2396-6815-4d8b-8b82-4e178a63aaea@github.com>
 <MQlLJm3UDkcy_B9tEat_AXVPz5ZiUWaiUE6fb-_4l1g=.65b5094e-e9ad-4063-8377-a50aa92b5825@github.com>
Message-ID: <p8zrUetU1C3PfdMlwB27EVlisMg930Iba_ycxa3IZko=.b3348780-6268-4bbc-92aa-6a1fc866268e@github.com>

On Wed, 6 Aug 2025 17:43:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java line 130:
>> 
>>> 128: 
>>> 129:         Util.runAndWait(() -> stage.setMaximized(true));
>>> 130:         Util.waitForIdle(stage.getScene());
>> 
>> I know that @andy-goryachev-oracle suggested its use, but for tests that do various windowing operations (maximize, full screen, restore, etc), `waitForIdle` is too short (its on the order of 160 msec). To make the test more robust, I recommend reverting this back to the `sleep(800)` you had earlier.
>> 
>> Arguably, we should have a utility method for this sort of "wait for windowing changes to settle down", but we don't.
>
> There is `Util::waitForIdle(scene, pulseCount)`.
> 
> The real question is how to account for the platform-dependent transitions (which may take some time) reliably.  Waiting for a set amount of time might work, but we have to pick a good timeout value.  Is there any other possibility?
> 
> I am ok with 800ms - it feels like it should be long enough for any transition to take place.

Changes to the maximized state are synchronous on all platforms. By the time `runAndWait` returns the window should be maximized. On Mac and Windows the JavaFX window state properties should be up-to-date because the OS notifications are also synchronous. I added waitForIdle because on Linux the configure events might come in later but we only need to wait long enough for the event loop to receive the events. That should be far less than 800ms.

> The real question is how to account for the platform-dependent transitions (which may take some time) reliably.

I can't think of any window attribute change that performs an asynchronous transition (but maybe I'm forgetting one). runAndWait should be enough on Mac and Windows. On Linux you need to give the event loop a chance to spin a few times.

The only real issue is (was?) fullscreen on macOS. The wait isn't really for the transition (it's done by the time setFullScreen returns) but to avoid scheduling deferred Runnables that might execute during the transition. That's less of an issue since #1797 was integrated.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2258030257

From kcr at openjdk.org  Wed Aug  6 19:17:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Aug 2025 19:17:27 GMT
Subject: RFR: 8356982: Update WebKit to 622.1
In-Reply-To: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
Message-ID: <v1Gsy13CMqFonm7DZ6nZTTZjsn8XzQlY-_nmyXrE5-0=.070af30a-3b6b-4aae-b7da-9fb8ff08d36b@github.com>

On Wed, 6 Aug 2025 17:51:44 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.

Reviewers: @kevinrushforth @jaybhaskar @tiainen

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

PR Comment: https://git.openjdk.org/jfx/pull/1865#issuecomment-3161300922

From kcr at openjdk.org  Wed Aug  6 19:57:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 6 Aug 2025 19:57:21 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <p8zrUetU1C3PfdMlwB27EVlisMg930Iba_ycxa3IZko=.b3348780-6268-4bbc-92aa-6a1fc866268e@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
 <es5OdPdIkz5wSsBmiHiZX6NNOgKPKH5WUcSKs2WSXZc=.b74c2396-6815-4d8b-8b82-4e178a63aaea@github.com>
 <MQlLJm3UDkcy_B9tEat_AXVPz5ZiUWaiUE6fb-_4l1g=.65b5094e-e9ad-4063-8377-a50aa92b5825@github.com>
 <p8zrUetU1C3PfdMlwB27EVlisMg930Iba_ycxa3IZko=.b3348780-6268-4bbc-92aa-6a1fc866268e@github.com>
Message-ID: <NSmViEX92VGlRFTFOZyXdFfOPVC6dJdTetPPMnUbXhY=.68346e57-ee48-427b-a5ed-4290efa6affb@github.com>

On Wed, 6 Aug 2025 19:03:54 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is `Util::waitForIdle(scene, pulseCount)`.
>> 
>> The real question is how to account for the platform-dependent transitions (which may take some time) reliably.  Waiting for a set amount of time might work, but we have to pick a good timeout value.  Is there any other possibility?
>> 
>> I am ok with 800ms - it feels like it should be long enough for any transition to take place.
>
> Changes to the maximized state are synchronous on all platforms. By the time `runAndWait` returns the window should be maximized. On Mac and Windows the JavaFX window state properties should be up-to-date because the OS notifications are also synchronous. I added waitForIdle because on Linux the configure events might come in later but we only need to wait long enough for the event loop to receive the events. That should be far less than 800ms.
> 
>> The real question is how to account for the platform-dependent transitions (which may take some time) reliably.
> 
> I can't think of any window attribute change that performs an asynchronous transition (but maybe I'm forgetting one). runAndWait should be enough on Mac and Windows. On Linux you need to give the event loop a chance to spin a few times.
> 
> The only real issue is (was?) fullscreen on macOS. The wait isn't really for the transition (it's done by the time setFullScreen returns) but to avoid scheduling deferred Runnables that might execute during the transition. That's less of an issue since #1797 was integrated.

Yes, full-screen is the one I know does (or did) have some async behavior. If maximize is reliably synchronous then OK to keep the test the way you have it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2258142820

From duke at openjdk.org  Wed Aug  6 21:11:23 2025
From: duke at openjdk.org (=?UTF-8?B?Q2zDqW1lbnQ=?= de Tastes)
Date: Wed, 6 Aug 2025 21:11:23 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
Message-ID: <UALLHqgJpYSbxAPhCy8Bxisx0RX-9jVQd4J4keSnPeU=.bdc22055-eefa-41e9-822b-3763a1bc78f0@github.com>

On Tue, 5 Aug 2025 11:45:50 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove additional space

`com.sun.javafx.PlatformUtil::isHeadless` returns `true` for any case matching `"headless"`, which is not what i provided in my original suggestion.
So maybe we could reuse it :


            if (userPlatform != null) {
                if (userPlatform.equals("macosx"))
                    type = MAC;
                else if (userPlatform.equals("windows"))
                    type = WINDOWS;
                else if (userPlatform.equals("linux"))
                    type = GTK;
                else if (userPlatform.equals("gtk"))
                    type = GTK;
                else if (userPlatform.equals("ios"))
                    type = IOS;
                else
                    if (PlatformUtil.isHeadless())
                        type = HEADLESS
                    else
                        type = userPlatform;
                return type;
            }


Makes the code a bit clumsy to me, but has the benefit of reusing logic.

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3161620246

From john.hendrikx at gmail.com  Wed Aug  6 22:54:18 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 7 Aug 2025 00:54:18 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
Message-ID: <9ae2bd90-9bbc-4edd-a24d-88235e301336@gmail.com>


On 06/08/2025 18:06, Martin Fox wrote:
>> On Aug 5, 2025, at 4:07?PM, John Hendrikx <john.hendrikx at gmail.com> wrote:
>>
>>
>> On 05/08/2025 22:01, Martin Fox wrote:
>>> I have some questions related to the spec. I think some of this has been addressed in the PR but not in the documentation.
>>>
>>> - This spec goes through some trouble to ensure that the target of a KeyEvent is the ComboBox/Spinner and not its TextField.
>> This is not new in this spec though.  KeyEvents are delivered to the
>> focused control.  The focused node has always been the Control, and not
>> any part of its Skin.
> The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It?s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).

I disagree.? A ComboBox and Spinner are primitives.? Their
implementation via replacable Skins may or may not use a TextField,
that's completely up to the Skin.? Some details do leak out, but those
mainly used to enable CSS styling.? CSS is built for this and will
leniently ignore untargetable styles.

>From the perspective of the user, the Control is a leaf Node, the only
target for focus and?should (IMHO) also be the only target for mouse
clicks.? Control goes through great lengths to construct a black box
here, integrating CSS properties supplied by the Skin and forwarding
methods like `compute` and `layoutChildren` to the Skin.? Changing this
now means Controls are?just Regions and there is no point in even having
the class.? The fact that some of this currently is leaky (I'm looking
at listeners and event handlers added by skins and behaviors that
intermix with user handlers) does not take away that it was always
intended to be a skinnable black box, where no assumptions can and
should be made as to what the Skin supplies or how it is implemented.

> I believe the implementation of Spinner predates focusWithin and focusVisible. I think the natural way to drive the focus indicators these days would be to use focused for the TextEdit and focus-within for the Spinner. In any case I think it?s a good idea to somehow separate these out and not force all of these flags to be set in unison across the entire delegate chain.

I think that?Controls fill two roles, as a leaf node for users and as an
extension point (a Parent) for Skins.? This has become intermixed in FX
by reusing existing API's because they were conveniently available, yet
not quite suited for purpose.

- Controls are or should be leaf nodes for focus, events and for users
querying children; users should never be concerned with the
implementation provided by the Skin.? Events should be forwarded to a
Control's children decided by the Control (or actually its Behavior).?
This can be also be done without having that Event traverse down from
Scene, by building a custom event dispatch chain that only travels from
Control to one of its descendants.? The fact that some behaviors/skins
currently don't realize that this is possible is very telling.?
Michael's solution just makes this re-usable, but Behaviors can easily
install handlers on Control, and do their own event forwarding without
going down from Scene (they still "duplicate" the event, but no Node
ever sees the same event twice).?

- Skins supply additional controls (optionally) that are added to the
children list of Control -- this was a mistake, they should have been
added to a separate list only available for CSS styling and SceneGraph
rendering -- the children of a control supplied by the Skin are not even
there yet until the first CSS pass completes...

- Skins re-use listener and event handler endpoints on the Control,
leaving users baffled by events sometimes being consumed before they see
them (if they added their handler late) or after they see them (if they
were the first to add their handler, or if the Skin was replaced causing
a re-ordering -- something very interesting to deal with); for listeners
this is relatively safe, as they don't have a consumption mechanism, but
not for events --? another mistake; skin event handlers should have been
part of a separate list so there can never be any intermixing of user
and skin event handlers

What we're currently seeing is that there are some leaks in the black
box that is supposed to be Control, and what you seem to be proposing is
that instead of plugging those leaks we create more.

> If we were to make the Spinner?s TextEdit the focus owner input methods would work, the focused and focus-within pseudo-classes would sort themselves out in a natural way, and the double firing of KeyEvents would go away. The downside is that you would create an information deficit during event processing; the event target would be the TextEdit and not the logical control. But that?s an existing problem that also affects mouse click events. Perhaps we should focus on closing that information gap instead.
>
> Martin
>
>

From john.hendrikx at gmail.com  Wed Aug  6 23:03:50 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 7 Aug 2025 01:03:50 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <CAJEpuXS6hfqNxmsqMt=QTrcygWZNveEa0JCOVjHSSTeRkBhcuw@mail.gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
 <CAJEpuXS6hfqNxmsqMt=QTrcygWZNveEa0JCOVjHSSTeRkBhcuw@mail.gmail.com>
Message-ID: <123089c5-e3af-42f4-af63-8bd14422ab34@gmail.com>


On 06/08/2025 20:38, Michael Strau? wrote:
>> The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It?s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).
>>
>> I believe the implementation of Spinner predates focusWithin and focusVisible. I think the natural way to drive the focus indicators these days would be to use focused for the TextEdit and focus-within for the Spinner. In any case I think it?s a good idea to somehow separate these out and not force all of these flags to be set in unison across the entire delegate chain.
>>
>> If we were to make the Spinner?s TextEdit the focus owner input methods would work, the focused and focus-within pseudo-classes would sort themselves out in a natural way, and the double firing of KeyEvents would go away. The downside is that you would create an information deficit during event processing; the event target would be the TextEdit and not the logical control. But that?s an existing problem that also affects mouse click events. Perhaps we should focus on closing that information gap instead.
> I think you might be onto something here:
>
> Let's close down the "Node.setFocused" loophole, no more tampering
> with the focused flag. This entails fixing TableView and other
> controls that misuse this flag. With this improvement, there's only
> ever going to be a single focused node in the scene graph, and
> "focused == input focus" is always true.
>
> Then we would need to redefine "Node.requestFocus()" to allow a
> control to delegate the focus request to one of its descendants
> instead. This means:
> 1. If a control accepts requestFocus(), the focusWithin flag will
> _always_ be set on the control.
> 2. It _might_ also have the focused flag, but this is
> implementation-specific and should not be relied upon.
> 3. Scene.focusOwner might not point to the control, but to one of its
> descendants.
I think that for purposes of focus, the Control should still be regarded
as a leaf node.? Letting focusOwner point to a descendant is just adding
more leaks to the Control black box.? The fact that Nodes happen to be
Parents for rendering purposes that can have children added by Skins was
just a convenient way to apply styling and do further rendering.? For
the user world, Controls should be black boxes that preferably even hide
the fact they have any children at all.? This is already the case at
construction time, as the children are only added after the Skin is
applied.? For rendering, children was just a convenient place to add
more nodes, but it should have been kept separate, also because the user
can't really manipulate the control's children without interfering with
what Skins are doing (it's basically undefined -- perhaps Control should
not have been based on Region, but on Parent, or some intermediate class
that still kept `getChildren` read-only...)

--John

From nlisker at openjdk.org  Wed Aug  6 23:20:35 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 6 Aug 2025 23:20:35 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <Lu_n8c-MnQ1dOO0mWclvgSHpqpU5sXyJY0YbEz12XrY=.d63991c6-5314-4448-85e4-106068bed384@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>
 <BFGIzdexd_qWqjDGRfDd5PvSij6xOLYllmS0SfAgWIQ=.cdee1712-1839-4a4e-9566-c88c2aafecb5@github.com>
 <Lu_n8c-MnQ1dOO0mWclvgSHpqpU5sXyJY0YbEz12XrY=.d63991c6-5314-4448-85e4-106068bed384@github.com>
Message-ID: <lbX2_XYVlJBTPBGXA5SAPAsmZr0RWqL0OGKPVPdcMnU=.e3224581-f3d8-46a0-850d-7c7d58a55b00@github.com>

On Tue, 5 Aug 2025 11:01:27 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> I'm not sure I understand where is it used? I see that the same `MTLMesh` can be passed to multiple `MTLMeshView`s, but what do they do with it?
>
> MTLMesh is the geometry i.e. vertex buffer, index buffer required to render a 3D Shape. So, if we create say 10 Spheres as `Sphere(50)`, then it creates 10 MTLMeshView and only 1 MTLMesh shared among MTLMeshView.
> 
> The mesh is used on native side, Please check MetalMesh.render() method in the PR. 
> This aligns very much with D3DMesh, ES2Mesh.

Ah, it's used in the native side. Please add a comment saying so because it's flagged as an unused field in Java.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2258508771

From nlisker at openjdk.org  Wed Aug  6 23:29:28 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 6 Aug 2025 23:29:28 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <u45a-EpT9itG19jslxlqirTjFHzC-wZcbyV9Y-qZDzc=.a04e442b-3546-4338-bc8e-368a8b37768a@github.com>
Message-ID: <VqSBud4snsi__8A3Hz8Z7nc2ug4x3OMEZkx5aDiw_Xk=.bf83e8aa-258e-49a1-a5f9-ccd535fff439@github.com>

On Mon, 4 Aug 2025 22:44:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr-andy: review comments
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 197:
> 
>> 195:         // contentX and contentY is set as 0 unlike D3D/ES2.
>> 196:         // The wrap mode are addressed, can be mapped to D3D/ES2 only if necessary.
>> 197:         return new MTLTexture(getContext(), resource, formatHint, wrapMode, allocw, alloch, 0, 0, allocw, alloch, useMipmap);
> 
> Same raw type.

Minor: This could just be `MTLTexture<>` instead of `MTLTexture<MTLTextureData>` because the type is inferred.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2258521498

From nlisker at openjdk.org  Wed Aug  6 23:29:29 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 6 Aug 2025 23:29:29 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <LJkm3Apf0qQksK-jU1TogORJUOsdsvb-wFvd5y6-YAg=.9e8740e7-61bc-4d78-9d5b-a9c7c3d6c475@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <LJkm3Apf0qQksK-jU1TogORJUOsdsvb-wFvd5y6-YAg=.9e8740e7-61bc-4d78-9d5b-a9c7c3d6c475@github.com>
Message-ID: <dSfb3p_cZlcasXT-Pf8NVF_QwD10vZa0YDFMtZnfslw=.5a7ffb3d-155b-4dc5-9286-2257c6d17931@github.com>

On Mon, 4 Aug 2025 22:54:13 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 87:
>> 
>>> 85:     @Override
>>> 86:     protected Texture createSharedTexture(WrapMode newMode) {
>>> 87:         return new MTLTexture(this, newMode);
>> 
>> Raw type
>
> Same, needs to be `MTLTexture<>`.

Minor: Also here `MTLTexture<T>` can be `MTLTexture<>`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2258522719

From arapte at openjdk.org  Thu Aug  7 05:01:51 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 7 Aug 2025 05:01:51 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:

  nir: comment and raw type

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/cc3dffc4..b6ce51e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=21
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=20-21

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

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

From arapte at openjdk.org  Thu Aug  7 05:10:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 7 Aug 2025 05:10:29 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v17]
In-Reply-To: <MCI8ow6dNse_NmA2U8EE1CnGE9y82ARw9iRRHriv16E=.91b3fdbb-82df-4e91-b0d9-2056867bf244@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-2AApqTTiiq30tUzZ6ton-A6W0YrHsp2NzEb5pilLjk=.8895104a-ed83-4dfa-8c56-7570d5bb0c73@github.com>
 <MCI8ow6dNse_NmA2U8EE1CnGE9y82ARw9iRRHriv16E=.91b3fdbb-82df-4e91-b0d9-2056867bf244@github.com>
Message-ID: <PuqtgC3ZdeipYs-3V4PDWabixxZ1sqpRWK5Fed5WdLQ=.6ae31a14-d574-494a-b3fd-a6c07e4f87d9@github.com>

On Mon, 4 Aug 2025 16:48:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kcr-andy: review comments
>
> I'll try to do a second pass on the Java section changes later today. A quick look shows no concerns on my part.

@nlisker  made the changes as you suggested. please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3162497018

From arapte at openjdk.org  Thu Aug  7 05:10:30 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 7 Aug 2025 05:10:30 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <lbX2_XYVlJBTPBGXA5SAPAsmZr0RWqL0OGKPVPdcMnU=.e3224581-f3d8-46a0-850d-7c7d58a55b00@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>
 <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>
 <BFGIzdexd_qWqjDGRfDd5PvSij6xOLYllmS0SfAgWIQ=.cdee1712-1839-4a4e-9566-c88c2aafecb5@github.com>
 <Lu_n8c-MnQ1dOO0mWclvgSHpqpU5sXyJY0YbEz12XrY=.d63991c6-5314-4448-85e4-106068bed384@github.com>
 <lbX2_XYVlJBTPBGXA5SAPAsmZr0RWqL0OGKPVPdcMnU=.e3224581-f3d8-46a0-850d-7c7d58a55b00@github.com>
Message-ID: <JpYAupi6F0Zm3j527jC-2zuwwcqrFAQPuMB0Jybd1lg=.a82bdf3c-1ad1-4edc-8dcf-f2e524362008@github.com>

On Wed, 6 Aug 2025 23:17:35 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> MTLMesh is the geometry i.e. vertex buffer, index buffer required to render a 3D Shape. So, if we create say 10 Spheres as `Sphere(50)`, then it creates 10 MTLMeshView and only 1 MTLMesh shared among MTLMeshView.
>> 
>> The mesh is used on native side, Please check MetalMesh.render() method in the PR. 
>> This aligns very much with D3DMesh, ES2Mesh.
>
> Ah, it's used in the native side. Please add a comment saying so because it's flagged as an unused field in Java.

Added a short comment and another line that is present in D3DMeshView and ES2MeshView.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2259062227

From nlisker at openjdk.org  Thu Aug  7 08:48:38 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 7 Aug 2025 08:48:38 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
Message-ID: <tEvGOFG6Ac6qQY93aGmhDO9Gv5DTkcgwS4mQ-PUKMIw=.4d8adc57-8a18-4794-ba25-d4826be4f9b3@github.com>

On Thu, 7 Aug 2025 05:01:51 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nir: comment and raw type

Great job!

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

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3096076040

From kcr at openjdk.org  Thu Aug  7 10:54:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 10:54:30 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
Message-ID: <8ou1dJCIv5WO7QuSiXag5lhQx5USv0LVZ2MD3PIPkoI=.0266c2ac-9184-4bfd-831d-7100c590e2ca@github.com>

On Thu, 7 Aug 2025 05:01:51 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nir: comment and raw type

LGTM

Lowering the (re)-reviewers requirement to 1 since this is a trivial change.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3096528573

From kcr at openjdk.org  Thu Aug  7 14:27:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 14:27:21 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>
Message-ID: <PhOWivsJFe_FOaLAOMkJJvFxeekeykurEHwgXv4Vgac=.d4fef72c-20a2-456c-a5d3-71f3550ae71e@github.com>

On Thu, 31 Jul 2025 15:05:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> This PR fixes numerous bugs in the handling of setMaximized() on macOS and also cleans up some issues seen when the user changes the maximized state manually.
>> 
>> - After setMaximized(false) a notifyResize event was never sent so the width and height tracked by JavaFX was wrong.
>> 
>> - During maximize and restore a series of notifyMove events were issued causing the maximized property to flip-flop during the animation.
>> 
>> - Transparent windows were being maximized by passing native screen coordinates to a routine that expected JavaFX screen coordinates so the Y axis was flipped and the window was positioned incorrectly.
>> 
>> - The restored frame is in native screen coordinates which was sent to a routine that expected flipped JavaFX coordinates. That routine corrected this by directly inspecting the call stack to see which routine was calling it.
>> 
>> - When the user maximizes or restores the window a notifyResize event was always sent immediately stating that the window was maximized even when it was not. Then a series of notifyMove events were issued causing the maximized flag to flip-flop during the animation.
>> 
>> This PR cleans all of this up. When using the setMaximized API only one notifyMove and one notifyResize event are sent and transparent windows are positioned correctly. When the user maximizes or restores manually we still see a series of notifyMove and notifyResize events but at least they all report the window?s state correctly.
>> 
>> System tests are currently being written as part of #1789. It?s hard to create a system test that catches things like the mis-alignment of maximized transparent windows so that needs to be tested manually. The reproducer attached to the bug report can be used to verify this and also to see what happens when the user toggles the maximization state manually.
>> 
>> Note that when the test programs tags something as ?unexpected? it just means it saw a property change outside of any JavaFX API call. This is actually expected if the user manipulates the window manually.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up diff against master. Tighted up system test (tested on Windows and Linux)

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1860#pullrequestreview-3097410950

From tsayao at openjdk.org  Thu Aug  7 14:29:05 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 7 Aug 2025 14:29:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v51]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <PO7vSErCmKlFzDBtwtd26u4oTZZhi3UEaRx6HywTPTw=.fa4cc39b-9338-47bd-89c0-129a7c0af5d7@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

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 62 commits:

 - Fix failing tests + review adjustments
 - Merge branch 'master' into 8354943
 - Simplify notify_fullscreen
 - Merge branch 'master' into 8354943
 - Remove repaint call (8351867 is fixed)
 - Merge branch 'master' into 8354943
 - Remove unused const
 - Remove wrong call to enter_fullscreen
 - Review changes
 - Use process_expose
 - ... and 52 more: https://git.openjdk.org/jfx/compare/f9532842...4cf43916

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=50
  Stats: 4241 lines in 28 files changed: 2844 ins; 784 del; 613 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From kcr at openjdk.org  Thu Aug  7 14:45:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 14:45:24 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <AUcNl52Bz-klgqjfVbhBe_3GPgmoPjGIgCWkwyeFiUE=.47a91d23-a10c-491e-b2d3-cfe210c38094@github.com>
References: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
 <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@github.com>
 <AUcNl52Bz-klgqjfVbhBe_3GPgmoPjGIgCWkwyeFiUE=.47a91d23-a10c-491e-b2d3-cfe210c38094@github.com>
Message-ID: <cPfs7x8wQDaiS8Fs5fTT97-j5bovXbCiW5Joan1DyPc=.0a724fc3-c971-4323-94fe-267b2d89cbc9@github.com>

On Mon, 14 Jul 2025 18:26:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted manual tests, added system test, changed check for fake performKeyEquivalent event.
>
> Heads up, I just submitted a PR (#1848) that fixes this bug in an entirely different way. The fix in this PR is much simpler and safer (I would not be afraid to back port it) and so I think it should go forward even if it turns out to be an interim fix. In any case it might take a while for #1848 to get vetted and there's the non-zero chance it will get rejected. But if anyone reviews both you'll see the same area of code affected in GlassView3D.m (the performKeyEquivalent: handling).

@beldenfox In case you missed it, this is ready for integration.

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

PR Comment: https://git.openjdk.org/jfx/pull/1837#issuecomment-3164486341

From angorya at openjdk.org  Thu Aug  7 14:55:35 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Aug 2025 14:55:35 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
Message-ID: <T8q0HdOs0M7Q1EQKLVXx85JOr_8P8ElMT2AYRkl-YKI=.cb39f094-acae-48fa-908d-029965e3d82a@github.com>

On Thu, 7 Aug 2025 05:01:51 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
>> 
>> ### Details about the changes
>> 
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
>> 
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>> 
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation which use Metal APIs
>> - Java side changes:
>>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
>> - Native side changes:
>>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
>> 
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
>> - Added Metal specific Glass implementation.
>> 
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>>   - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>>   - All headful tests pass with Metal pipeline.
>>   - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
>> 
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nir: comment and raw type

I wish we introduced an annotation for that (native use).
lgtm.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3097523032

From nlisker at openjdk.org  Thu Aug  7 15:29:35 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 7 Aug 2025 15:29:35 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <T8q0HdOs0M7Q1EQKLVXx85JOr_8P8ElMT2AYRkl-YKI=.cb39f094-acae-48fa-908d-029965e3d82a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
 <T8q0HdOs0M7Q1EQKLVXx85JOr_8P8ElMT2AYRkl-YKI=.cb39f094-acae-48fa-908d-029965e3d82a@github.com>
Message-ID: <iWZDP3BRZUVrwnpNcBynTk8-NLndbu-Rw7yrfYDVArs=.e45dab23-4d6c-4877-8ab2-37c939af6c9d@github.com>

On Thu, 7 Aug 2025 14:52:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I wish we introduced an annotation for that (native use). lgtm.

How widespread are the cases of unused Java fields/methods/classes that are used in the native code?

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3164691496

From mfox at openjdk.org  Thu Aug  7 15:31:24 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 7 Aug 2025 15:31:24 GMT
Subject: Integrated: 8355990: [macOS] Restoring a maximized stage does not
 update the window size
In-Reply-To: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
Message-ID: <ZkPorA3Sm1iPBeAHw7swyaL9k2ronU6tzq7IzHvNLpY=.1a7466ca-869b-49ae-aca4-8e1fc03dbb3e@github.com>

On Tue, 29 Jul 2025 14:45:36 GMT, Martin Fox <mfox at openjdk.org> wrote:

> This PR fixes numerous bugs in the handling of setMaximized() on macOS and also cleans up some issues seen when the user changes the maximized state manually.
> 
> - After setMaximized(false) a notifyResize event was never sent so the width and height tracked by JavaFX was wrong.
> 
> - During maximize and restore a series of notifyMove events were issued causing the maximized property to flip-flop during the animation.
> 
> - Transparent windows were being maximized by passing native screen coordinates to a routine that expected JavaFX screen coordinates so the Y axis was flipped and the window was positioned incorrectly.
> 
> - The restored frame is in native screen coordinates which was sent to a routine that expected flipped JavaFX coordinates. That routine corrected this by directly inspecting the call stack to see which routine was calling it.
> 
> - When the user maximizes or restores the window a notifyResize event was always sent immediately stating that the window was maximized even when it was not. Then a series of notifyMove events were issued causing the maximized flag to flip-flop during the animation.
> 
> This PR cleans all of this up. When using the setMaximized API only one notifyMove and one notifyResize event are sent and transparent windows are positioned correctly. When the user maximizes or restores manually we still see a series of notifyMove and notifyResize events but at least they all report the window?s state correctly.
> 
> System tests are currently being written as part of #1789. It?s hard to create a system test that catches things like the mis-alignment of maximized transparent windows so that needs to be tested manually. The reproducer attached to the bug report can be used to verify this and also to see what happens when the user toggles the maximization state manually.
> 
> Note that when the test programs tags something as ?unexpected? it just means it saw a property change outside of any JavaFX API call. This is actually expected if the user manipulates the window manually.

This pull request has now been integrated.

Changeset: 657d34f8
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/657d34f82480f985f4d3d0477c907879ef30af79
Stats:     61 lines in 5 files changed: 22 ins; 33 del; 6 mod

8355990: [macOS] Restoring a maximized stage does not update the window size
8352999: [macOS] Conditional behavior by directly querying the Objective-C call stack

Reviewed-by: angorya, kcr

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

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

From mfox at openjdk.org  Thu Aug  7 15:31:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 7 Aug 2025 15:31:23 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <AUcNl52Bz-klgqjfVbhBe_3GPgmoPjGIgCWkwyeFiUE=.47a91d23-a10c-491e-b2d3-cfe210c38094@github.com>
References: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
 <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@github.com>
 <AUcNl52Bz-klgqjfVbhBe_3GPgmoPjGIgCWkwyeFiUE=.47a91d23-a10c-491e-b2d3-cfe210c38094@github.com>
Message-ID: <c7Z_hDlQ0CC6KInVLkYfEEJlfpGFNJeXQ9ICXLPx-u8=.ef68b4f3-157c-4c58-b0b5-745603535e14@github.com>

On Mon, 14 Jul 2025 18:26:34 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverted manual tests, added system test, changed check for fake performKeyEquivalent event.
>
> Heads up, I just submitted a PR (#1848) that fixes this bug in an entirely different way. The fix in this PR is much simpler and safer (I would not be afraid to back port it) and so I think it should go forward even if it turns out to be an interim fix. In any case it might take a while for #1848 to get vetted and there's the non-zero chance it will get rejected. But if anyone reviews both you'll see the same area of code affected in GlassView3D.m (the performKeyEquivalent: handling).

> @beldenfox In case you missed it, this is ready for integration.

Thanks. Lately I haven't been getting e-mail notifications when my pull requests transition to the ready state.

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

PR Comment: https://git.openjdk.org/jfx/pull/1837#issuecomment-3164697035

From mfox at openjdk.org  Thu Aug  7 15:31:24 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 7 Aug 2025 15:31:24 GMT
Subject: Integrated: 8360886: Cmd + plus shortcut does not work reliably
In-Reply-To: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
References: <de7oV-ITtdGKEv-kOHIFsxWZiEoG-BNTNuJOVwY_GYM=.991b0450-06ce-4480-ae78-201180b902fc@github.com>
Message-ID: <ypOXS96fEb5vKua7KoHtOv5jsW62DxOT2wXmB5t0fFQ=.d0339f74-eafb-4ba7-b79b-0a803678018f@github.com>

On Mon, 30 Jun 2025 16:58:00 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The Mac platform code figures out where characters are on the keyboard as the user types. The character table is updated on every key press by calling a registerKeyEvent: in GlassApplication. This character table is used to resolve KeyCharacterCombination accelerators like Cmd + "+".
> 
> On a US English layout when the user types Cmd + "+" on the main keyboard they're actually typing Cmd + "=". There's special handling in macOS for this combination that can cause two NSEvents to be sent and so there's special handling in the Glass code so we don't process both events. When this special case is invoked registerKeyEvent: isn't being called to update the character table. This bug was introduced when code was consolidated in PR #1528.
> 
> The fix is a simple one-liner. I've added a test for this in the KeyboardTest.java program. It's an isolated test because it requires the Robot to send events to hold down a modifier while a character key is pressed. I also updated some obsolete comments and tweaked it to test all KeyCharacterCombinations since they should now work reliably on all platforms.

This pull request has now been integrated.

Changeset: 457d9cd9
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/457d9cd997192d870090d88323486d83413bf926
Stats:     319 lines in 2 files changed: 292 ins; 18 del; 9 mod

8360886: Cmd + plus shortcut does not work reliably

Reviewed-by: angorya, mstrauss

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

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

From angorya at openjdk.org  Thu Aug  7 15:37:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Aug 2025 15:37:32 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <iWZDP3BRZUVrwnpNcBynTk8-NLndbu-Rw7yrfYDVArs=.e45dab23-4d6c-4877-8ab2-37c939af6c9d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
 <T8q0HdOs0M7Q1EQKLVXx85JOr_8P8ElMT2AYRkl-YKI=.cb39f094-acae-48fa-908d-029965e3d82a@github.com>
 <iWZDP3BRZUVrwnpNcBynTk8-NLndbu-Rw7yrfYDVArs=.e45dab23-4d6c-4877-8ab2-37c939af6c9d@github.com>
Message-ID: <JKIDYM0DkFSioQjEicHBlmxS6z1T5iA_0ltefBhvuII=.657d7034-6b2b-4692-afd3-c8bac41c9fb6@github.com>

On Thu, 7 Aug 2025 15:26:22 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> How widespread are the cases of unused Java fields/methods/classes that are used in the native code?

Probably a few cases.  The main benefit is maintainability in the long run.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3164735617

From martinfox656 at gmail.com  Thu Aug  7 15:40:35 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 7 Aug 2025 08:40:35 -0700
Subject: Anyone else seeing robot test failures on macOS?
Message-ID: <253CE2ED-D614-4EAC-AD44-BFE937B0CE1D@gmail.com>

When I do a complete run of the robot tests there?s a small set that consistently fail. The same tests pass if I run them individually. I haven?t dug into this yet but it looks like mouse events are getting lost (DualWindowTest) and key events are getting garbled (KeyEventClosesStageTest). But only on this small handful of tests and only when doing a full run. Has anyone else seen this?

macOS 15.5. The command I use:

	caffeinate -dim bash ./gradlew --no-daemon -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test

The tests that fail:

	TreeTableViewChangeRootTest. testChangeRoot()
	DualWindowTest. testTwoStages()
	FocusParentWindowOnChildCloseTest. focusRightParentOnChildWindowClose()
	KeyEventClosesStageTest. pressedEventClosesStage()
	KeyEventClosesStageTest. typedEventNeverArrives()



From martinfox656 at gmail.com  Thu Aug  7 15:45:11 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Thu, 7 Aug 2025 08:45:11 -0700
Subject: [External] : Re: Focus delegation API
In-Reply-To: <9ae2bd90-9bbc-4edd-a24d-88235e301336@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
 <9ae2bd90-9bbc-4edd-a24d-88235e301336@gmail.com>
Message-ID: <9A6D0794-D1A5-45CE-9CF9-838D9A55016E@gmail.com>



> On Aug 6, 2025, at 3:54?PM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> 
> On 06/08/2025 18:06, Martin Fox wrote:
>> 
>> The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It?s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).
> 
> I disagree.  A ComboBox and Spinner are primitives.  Their
> implementation via replacable Skins may or may not use a TextField,
> that's completely up to the Skin.

As I mentioned in my earlier e-mail (in the paragraph you quoted) the TextField is part of the ComboBox and Spinner API. Accessing it is the only way to, say, attach a TextFormatter to a Spinner. Consult the docs starting at version 2.2.

The proposal (lifted from WPF) is to provide a mechanism which would allow a Control to replace an event?s original target with itself. This is a low-cost way of making the control appear to be a black box at the event level. It would certainly have a lower cost than, say, trying to hide skin nodes from the rest of the scene graph. I?m not aware of any toolkit that even attempts that.

> - Skins re-use listener and event handler endpoints on the Control,
> leaving users baffled by events sometimes being consumed before they see
> them (if they added their handler late) or after they see them (if they
> were the first to add their handler, or if the Skin was replaced causing
> a re-ordering -- something very interesting to deal with); for listeners
> this is relatively safe, as they don't have a consumption mechanism, but
> not for events --  another mistake; skin event handlers should have been
> part of a separate list so there can never be any intermixing of user
> and skin event handlers

This is a known pain point for developers that can be fixed without re-writing the underpinnings of JavaFX (in other words, with a reasonable cost/benefit ratio). I?m not sure why it hasn?t been done already.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250807/67d161d4/attachment.htm>

From tsayao at openjdk.org  Thu Aug  7 15:54:32 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 7 Aug 2025 15:54:32 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v51]
In-Reply-To: <PO7vSErCmKlFzDBtwtd26u4oTZZhi3UEaRx6HywTPTw=.fa4cc39b-9338-47bd-89c0-129a7c0af5d7@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <PO7vSErCmKlFzDBtwtd26u4oTZZhi3UEaRx6HywTPTw=.fa4cc39b-9338-47bd-89c0-129a7c0af5d7@github.com>
Message-ID: <fgPdD-1dwR3F0vhjtIxOGoPUJ5AcFoanf13uPrcbl88=.ba0b2137-2f4e-4b64-b5e3-dfdd4b63ad14@github.com>

On Thu, 7 Aug 2025 14:29:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> 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 62 commits:
> 
>  - Fix failing tests + review adjustments
>  - Merge branch 'master' into 8354943
>  - Simplify notify_fullscreen
>  - Merge branch 'master' into 8354943
>  - Remove repaint call (8351867 is fixed)
>  - Merge branch 'master' into 8354943
>  - Remove unused const
>  - Remove wrong call to enter_fullscreen
>  - Review changes
>  - Use process_expose
>  - ... and 52 more: https://git.openjdk.org/jfx/compare/f9532842...4cf43916

I did a commit that fixed some issues, but there are still some left - I will get back to this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3164802313

From kcr at openjdk.org  Thu Aug  7 15:55:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 15:55:32 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v22]
In-Reply-To: <JKIDYM0DkFSioQjEicHBlmxS6z1T5iA_0ltefBhvuII=.657d7034-6b2b-4692-afd3-c8bac41c9fb6@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <KxsqjeHypH-YEUh8tSFBLWv7jZ0fz-CTwZBWcvtmTeA=.651ebac4-b01e-446f-be2a-feecee61ff5f@github.com>
 <T8q0HdOs0M7Q1EQKLVXx85JOr_8P8ElMT2AYRkl-YKI=.cb39f094-acae-48fa-908d-029965e3d82a@github.com>
 <iWZDP3BRZUVrwnpNcBynTk8-NLndbu-Rw7yrfYDVArs=.e45dab23-4d6c-4877-8ab2-37c939af6c9d@github.com>
 <JKIDYM0DkFSioQjEicHBlmxS6z1T5iA_0ltefBhvuII=.657d7034-6b2b-4692-afd3-c8bac41c9fb6@github.com>
Message-ID: <UIPiQbFOtWPu8_-0CJ7RScoyX_VhHYd0vGA5vCtRKiU=.bf1c777a-59ca-43c6-b8d2-a996ff7ea394@github.com>

On Thu, 7 Aug 2025 15:34:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > How widespread are the cases of unused Java fields/methods/classes that are used in the native code?
> 
> Probably a few cases. The main benefit is maintainability in the long run.

WebKit is the main place where we do this. By convention, all methods in WebView impl classes that are named `fwk*` are called via JNI from native code. Outside WebKit we have a handful of cases. I hope they are all documented.

As for an annotation, we wouldn't define one for JavaFX. If the JDK had some sort of `@UsedByNative` annotation (which would be the converse of `@Native`), we could consider using it.

Unless / until we have such an annotation, a clear comment is in order.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3164805775

From zelmidaoui at openjdk.org  Thu Aug  7 16:14:02 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 7 Aug 2025 16:14:02 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest on Linux
Message-ID: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>

Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`

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

Commit messages:
 - Disabled Test nonMacMenuBarComesBeforeScene()

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

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

From angorya at openjdk.org  Thu Aug  7 16:28:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Aug 2025 16:28:26 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest on Linux
In-Reply-To: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
Message-ID: <sfylJg0sqZcUAXD8PUaCLNEN5krvtkhGehlaISBzfMg=.c34dbf40-77df-4f87-9ce7-ceec4dc432a0@github.com>

On Thu, 7 Aug 2025 16:07:05 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`

tests/system/src/test/java/test/robot/javafx/scene/MenuDoubleShortcutTest.java line 108:

> 106:     // On platforms other than Mac the menu bar should process the event
> 107:     // and the scene should not.
> 108:     @Disabled("JDK-8364825")

`@Disabled` must refer to the reason this test is skipped, in this case JDK-8364405

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1867#discussion_r2260834425

From kcr at openjdk.org  Thu Aug  7 17:04:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 17:04:23 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest on Linux
In-Reply-To: <sfylJg0sqZcUAXD8PUaCLNEN5krvtkhGehlaISBzfMg=.c34dbf40-77df-4f87-9ce7-ceec4dc432a0@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <sfylJg0sqZcUAXD8PUaCLNEN5krvtkhGehlaISBzfMg=.c34dbf40-77df-4f87-9ce7-ceec4dc432a0@github.com>
Message-ID: <fAmUW8kxgbgWntaiARg_vPRVYGSqsVBZ2ZVkIaT_l84=.18a759aa-08a5-45c4-934f-878861b77dc0@github.com>

On Thu, 7 Aug 2025 16:25:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`
>
> tests/system/src/test/java/test/robot/javafx/scene/MenuDoubleShortcutTest.java line 108:
> 
>> 106:     // On platforms other than Mac the menu bar should process the event
>> 107:     // and the scene should not.
>> 108:     @Disabled("JDK-8364825")
> 
> `@Disabled` must refer to the reason this test is skipped, in this case JDK-8364405

Also, this will skip the test on all platforms. That might be a reasonable thing to do, but if that's what you propose, then please change the title (in JBS and the PR) to drop the "on Linux" part.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1867#discussion_r2260916887

From zelmidaoui at openjdk.org  Thu Aug  7 17:45:40 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 7 Aug 2025 17:45:40 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
Message-ID: <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>

> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Minor update to MenuDoubleShortcutTest

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1867/files
  - new: https://git.openjdk.org/jfx/pull/1867/files/77113f86..daae1ce9

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

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

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

From zelmidaoui at openjdk.org  Thu Aug  7 17:45:41 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 7 Aug 2025 17:45:41 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <fAmUW8kxgbgWntaiARg_vPRVYGSqsVBZ2ZVkIaT_l84=.18a759aa-08a5-45c4-934f-878861b77dc0@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <sfylJg0sqZcUAXD8PUaCLNEN5krvtkhGehlaISBzfMg=.c34dbf40-77df-4f87-9ce7-ceec4dc432a0@github.com>
 <fAmUW8kxgbgWntaiARg_vPRVYGSqsVBZ2ZVkIaT_l84=.18a759aa-08a5-45c4-934f-878861b77dc0@github.com>
Message-ID: <rsRVHfG0ryeND5GwfK_us8RU8oVkHGN80WPCldh7iE4=.8acd15dc-2b80-47ec-93cf-e5b1b2ab93ca@github.com>

On Thu, 7 Aug 2025 17:01:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/MenuDoubleShortcutTest.java line 108:
>> 
>>> 106:     // On platforms other than Mac the menu bar should process the event
>>> 107:     // and the scene should not.
>>> 108:     @Disabled("JDK-8364825")
>> 
>> `@Disabled` must refer to the reason this test is skipped, in this case JDK-8364405
>
> Also, this will skip the test on all platforms. That might be a reasonable thing to do, but if that's what you propose, then please change the title (in JBS and the PR) to drop the "on Linux" part.

The test is skipped on Mac by default with `Assumptions.assumeFalse(PlatformUtil.isMac());` , and now it will be also on Linux so skipping it on all platforms won't have critical impact I suppose

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1867#discussion_r2261010606

From kcr at openjdk.org  Thu Aug  7 17:57:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 17:57:19 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
Message-ID: <xKKF-_59hE8wUh1Uatl6Ab0LBYM9yVfPXc_NZMlUFeo=.21d3082e-c67c-452f-9469-9bcbe6e562ec@github.com>

On Thu, 7 Aug 2025 17:45:40 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update to MenuDoubleShortcutTest

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1867#pullrequestreview-3098228953

From kcr at openjdk.org  Thu Aug  7 17:57:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 17:57:20 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <rsRVHfG0ryeND5GwfK_us8RU8oVkHGN80WPCldh7iE4=.8acd15dc-2b80-47ec-93cf-e5b1b2ab93ca@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <sfylJg0sqZcUAXD8PUaCLNEN5krvtkhGehlaISBzfMg=.c34dbf40-77df-4f87-9ce7-ceec4dc432a0@github.com>
 <fAmUW8kxgbgWntaiARg_vPRVYGSqsVBZ2ZVkIaT_l84=.18a759aa-08a5-45c4-934f-878861b77dc0@github.com>
 <rsRVHfG0ryeND5GwfK_us8RU8oVkHGN80WPCldh7iE4=.8acd15dc-2b80-47ec-93cf-e5b1b2ab93ca@github.com>
Message-ID: <ap-7EAT8A6J9AGoffsPh7TyY7rvTmq3Ik1odS7NI2nw=.0038a9d8-9033-4792-830e-f08b4ba32f4a@github.com>

On Thu, 7 Aug 2025 17:36:49 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Also, this will skip the test on all platforms. That might be a reasonable thing to do, but if that's what you propose, then please change the title (in JBS and the PR) to drop the "on Linux" part.
>
> The test is skipped on Mac by default with `Assumptions.assumeFalse(PlatformUtil.isMac());` , and now it will be also on Linux so skipping it on all platforms won't have critical impact I suppose

It means that this test also won't run on Windows platforms, but that seems OK. When the underlying bug, JDK-8364405, is fixed this test can be reenabled for both Linux and Windows by removing the `@Disabled` annotation.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1867#discussion_r2261055089

From angorya at openjdk.org  Thu Aug  7 18:00:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 7 Aug 2025 18:00:23 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
Message-ID: <VHzKFS57BcrzmccqoQ9cf8D9UxH2cl3DibUaXDDtVTg=.0f81e545-4229-459a-a1d0-fb220e3e3823@github.com>

On Thu, 7 Aug 2025 17:45:40 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update to MenuDoubleShortcutTest

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1867#pullrequestreview-3098238704

From kcr at openjdk.org  Thu Aug  7 18:44:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 7 Aug 2025 18:44:49 GMT
Subject: RFR: 8364825: Skip failing MenuDoubleShortcutTest [v2]
In-Reply-To: <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
 <veUFsYgit__AV6vpUj7gjlhGF3l_kUzGUyaUQFttBA0=.bf3cecce-70e8-4a97-8882-05a42ce2af14@github.com>
Message-ID: <tqkpLsi2qhyuLhuMsbgBDDUJ7mNuH6Aq4WlBWeggeeE=.d7981db9-c9d9-469b-93c8-5d3569c567c1@github.com>

On Thu, 7 Aug 2025 17:45:40 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor update to MenuDoubleShortcutTest

Since this is a test-only fix to skip a failing test, I waive the usual 24-hour rule.

@Ziad-Mid Please integrate this when ready.

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

PR Comment: https://git.openjdk.org/jfx/pull/1867#issuecomment-3165291674

From michaelstrau2 at gmail.com  Thu Aug  7 19:35:14 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 7 Aug 2025 21:35:14 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <9A6D0794-D1A5-45CE-9CF9-838D9A55016E@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <CAJEpuXS0L2=DSwOAupDB_-b8N2yju+WVAcHogYCC+qT=OVHqRw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
 <9ae2bd90-9bbc-4edd-a24d-88235e301336@gmail.com>
 <9A6D0794-D1A5-45CE-9CF9-838D9A55016E@gmail.com>
Message-ID: <CAJEpuXQYiy4d0cJiZ9dVWODpH2FGZWhHQOsC4MVqpZ4p71_nrQ@mail.gmail.com>

> The proposal (lifted from WPF) is to provide a mechanism which would allow a Control to replace an event?s original target with itself. This is a low-cost way of making the control appear to be a black box at the event level. It would certainly have a lower cost than, say, trying to hide skin nodes from the rest of the scene graph. I?m not aware of any toolkit that even attempts that.

Shadow DOM is an example of sub-node isolation. It also has focus delegation.

From kevin.rushforth at oracle.com  Thu Aug  7 23:44:10 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 7 Aug 2025 16:44:10 -0700
Subject: JavaFX 25 is in Rampdown Phase Two (RDP2)
Message-ID: <15195863-5095-434f-9d0b-2e009feb3608@oracle.com>

To: JavaFX Developers

As a reminder, JavaFX 25 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 jfx25 
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 25. 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 25 release. As an obvious choice, derived from the 
JBS fix version, we will use "jfx25-fix-request", "jfx25-fix-yes", 
"jfx25-fix-no" and "jfx25-fix-nmi", "jfx25-enhancement-request", 
"jfx25-enhancement-yes", "jfx25-enhancement-no" and 
"jfx25-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 jfx25 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 26 as of today). This is usually what we 
want. A backport PR should be targeted to `jfx25` if, and only if, it is 
intended for JavaFX 25 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 `jfx25`. If 
there is a concern, then a reviewer can as part of the review indicate 
that the PR should be retargeted to `master` for 26 (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 jfx25 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 jfx25 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/2025-May/054252.html

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

[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 sproket at videotron.ca  Fri Aug  8 11:12:59 2025
From: sproket at videotron.ca (Dan Howard)
Date: Fri, 8 Aug 2025 07:12:59 -0400
Subject: FX 24.0.2 Some wav sounds don't play
Message-ID: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>

Hi all,

Has anyone see this issue?

FX version 24.0.2
Windows 11 Version 10.0.26100 Build 26100
wav file 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit


Prior versions of JavaFX played this file properly. Somehow I'm finding 
a few files which don't play.? I hear them fine with apps like audacity.

Can I attach a zip of this file for someone to try it?? ?I have a large 
set of various wav files, most of which do play correctly.

TIA







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

From john.hendrikx at gmail.com  Fri Aug  8 13:14:05 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 8 Aug 2025 15:14:05 +0200
Subject: [External] : Re: Focus delegation API
In-Reply-To: <9A6D0794-D1A5-45CE-9CF9-838D9A55016E@gmail.com>
References: <CAJEpuXTpoYp3fSL-Cp_U-h3ryrm7RyavENrUfa2FJTa4Q1DMfw@mail.gmail.com>
 <DM6PR10MB30179679EFE6A261AF4036DCE53D2@DM6PR10MB3017.namprd10.prod.outlook.com>
 <CAJEpuXQU1FVzu72nsbnznAQ3qPcT5Ht8vzDawTzUy+sGJMqFxg@mail.gmail.com>
 <BYAPR10MB30132F443C1EF9DB86C60262E53D2@BYAPR10MB3013.namprd10.prod.outlook.com>
 <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com>
 <BYAPR10MB3013C8E0345A5E0D5FE39792E5042@BYAPR10MB3013.namprd10.prod.outlook.com>
 <1632013B-9B2D-4C74-8011-C8A62C6FC241@gmail.com>
 <CAJEpuXQ5XA9GGq3NM+fTnn3J_nU45dQdqX66BxvESTp6fcziDA@mail.gmail.com>
 <F0D32F30-CAFE-4DBD-8948-1EB13414DDA7@gmail.com>
 <CAJEpuXSa6OYSiF9=g1SMM_=TxdA4MV8DTLatuWkCKCnL_TbCxQ@mail.gmail.com>
 <F0C58AF9-05FA-4F28-9DAF-B4043EFEDA7B@gmail.com>
 <6EDDE99A-5DF5-46C4-A25B-2AFCF457D622@gmail.com>
 <160b321d-af6b-4837-bfeb-ae482de1adaf@gmail.com>
 <CB48D605-CBFD-4AA1-B991-2340B6ED3723@gmail.com>
 <9ae2bd90-9bbc-4edd-a24d-88235e301336@gmail.com>
 <9A6D0794-D1A5-45CE-9CF9-838D9A55016E@gmail.com>
Message-ID: <78087c64-9fe5-4791-9f80-0c22ef0c2e36@gmail.com>


On 07/08/2025 17:45, Martin Fox wrote:
>
>
>> On Aug 6, 2025, at 3:54?PM, John Hendrikx <john.hendrikx at gmail.com>
>> wrote:
>>
>>
>> On 06/08/2025 18:06, Martin Fox wrote:
>>> The TextField of a ComboBox or Spinner is not just an artifact of
>>> its skin. They are both explicitly composite controls that contains
>>> a TextField inside. It?s part of the API. And if you were to install
>>> some filters on the Scene to track Key and InputMethod events you
>>> could easily conclude that that TextField is the focus owner (it
>>> walks like the focus owner, it quacks like the focus owner).
>>
>> I disagree.? A ComboBox and Spinner are primitives.? Their
>> implementation via replacable Skins may or may not use a TextField,
>> that's completely up to the Skin.
>
> As I mentioned in my earlier e-mail (in the paragraph you quoted) the
> TextField is part of the ComboBox and Spinner API. Accessing it is the
> only way to, say, attach a TextFormatter to a Spinner. Consult the
> docs starting at version 2.2.

I took another look here, and printed this field.

- It's a FakeFocusTextField (sigh)
- It was available immediately even before a Skin was applied
- It remains available even if another Skin is applied that doesn't have
a TextField

This really?is only another example of lazy design, exposing part of the
inner workings of a Control to avoid having to duplicate some properties
that are relevant to Spinners as a primitive.? The returned TextField is
not mandated to be used by the Skin, and so it can just do nothing (ie.
if the Skin prefers using a Label).? The TextFormatter would be relevant
in either case, and should have been a top level property, that the Skin
may bind to.

All I'm seeing is a brilliant design idea (skinnable controls, with
separated behaviors) executed poorly:

- Behavior and Skins referring to each other
- Skins given too much access to Controls (write access to any property
should not be allowed, nor should Skins be allowed to install event
handlers on their host Control)
- Behaviors installing Event Handlers directly mixing with user handlers
- Controls exposing sub controls that it can't guarantee will be there
or used, per how Skins work
- Events not being targetted at the Control black box
- Internal Skin level Events leaking to the outside world (completely
unnecessarily as this can be 100% avoided already now)
- Skins not being isolated properly so replacing Skins can leave old
listeners behind (it requires co-operation of the Skin, while it should
be automatic)
- Behavior's handling navigation events directly instead of letting them
bubble up often blocking users from handling them first
- ... and now another: failure to hoist up relevant properties to the
main Control (or make them styleable and part of the Skin provided
properties)

> The proposal (lifted from WPF) is to provide a mechanism which would
> allow a Control to replace an event?s original target with itself.
> This is a low-cost way of making the control appear to be a black box
> at the event level. It would certainly have a lower cost than, say,
> trying to hide skin nodes from the rest of the scene graph. I?m not
> aware of any toolkit that even attempts that.
Skins by their definition have free reign what nodes they create.? It's
not hiding anything when you simply can't, nor should rely on anything
being there specifically.? It therefore makes sense to disallow access
to these nodes programmatically for the user. These extra nodes (if they
exist) are only targettable by CSS, which is fine in my book as CSS can
set a Skin, or know what Skins are present by default for a default
stylesheet.?

I'm not saying this can be changed still, I'm saying what it should have
been had the idea of Skins not been subverted into its current state.? I
would like to prevent adding any more leaks, and plugging leaks that we can.

Adding an extra field to events to support the internal event
dispatching system (preferably not public API) is fine with me.
>
>> - Skins re-use listener and event handler endpoints on the Control,
>> leaving users baffled by events sometimes being consumed before they see
>> them (if they added their handler late) or after they see them (if they
>> were the first to add their handler, or if the Skin was replaced causing
>> a re-ordering -- something very interesting to deal with); for listeners
>> this is relatively safe, as they don't have a consumption mechanism, but
>> not for events --? another mistake; skin event handlers should have been
>> part of a separate list so there can never be any intermixing of user
>> and skin event handlers
>
> This is a known pain point for developers that can be fixed without
> re-writing the underpinnings of JavaFX (in other words, with a
> reasonable cost/benefit ratio). I?m not sure why it hasn?t been done
> already.
I have no idea either, it's a no-brainer.

--John
>
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250808/4f353c26/attachment-0001.htm>

From kevin.rushforth at oracle.com  Fri Aug  8 13:24:04 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 Aug 2025 06:24:04 -0700
Subject: Anyone else seeing robot test failures on macOS?
In-Reply-To: <253CE2ED-D614-4EAC-AD44-BFE937B0CE1D@gmail.com>
References: <253CE2ED-D614-4EAC-AD44-BFE937B0CE1D@gmail.com>
Message-ID: <27e52317-a518-42d3-8541-c46dbdb421ad@oracle.com>

Yes, we have seen failures in the same set of tests you mention, 
although on our nightly test systems, it's intermittent.

https://bugs.openjdk.org/browse/JDK-8359154

-- Kevin


On 8/7/2025 8:40 AM, Martin Fox wrote:
> When I do a complete run of the robot tests there?s a small set that consistently fail. The same tests pass if I run them individually. I haven?t dug into this yet but it looks like mouse events are getting lost (DualWindowTest) and key events are getting garbled (KeyEventClosesStageTest). But only on this small handful of tests and only when doing a full run. Has anyone else seen this?
>
> macOS 15.5. The command I use:
>
> 	caffeinate -dim bash ./gradlew --no-daemon -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test
>
> The tests that fail:
>
> 	TreeTableViewChangeRootTest. testChangeRoot()
> 	DualWindowTest. testTwoStages()
> 	FocusParentWindowOnChildCloseTest. focusRightParentOnChildWindowClose()
> 	KeyEventClosesStageTest. pressedEventClosesStage()
> 	KeyEventClosesStageTest. typedEventNeverArrives()
>
>


From zelmidaoui at openjdk.org  Fri Aug  8 13:36:23 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 8 Aug 2025 13:36:23 GMT
Subject: Integrated: 8364825: Skip failing MenuDoubleShortcutTest
In-Reply-To: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
References: <_byLndGsQx4kSSiXPJqG6q-hU8taH_NNAFUTKHLeU_E=.2a19b120-8cf8-4a75-b484-6d49df670cf4@github.com>
Message-ID: <P4AUhK86etfxDBTPzz2yG-x9sEI4DxgTv3TOfbm0B50=.b3477435-7cf5-4024-9fec-9b86a5f80792@github.com>

On Thu, 7 Aug 2025 16:07:05 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Skipping failing `MenuDoubleShortcutTest#nonMacMenuBarComesBeforeScene()`

This pull request has now been integrated.

Changeset: 00820f4f
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/00820f4f2d299f3050d2da28c06e4d3e4f2bc101
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8364825: Skip failing MenuDoubleShortcutTest

Reviewed-by: kcr, angorya

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

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

From andy.goryachev at oracle.com  Fri Aug  8 15:03:55 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 8 Aug 2025 15:03:55 +0000
Subject: FX 24.0.2 Some wav sounds don't play
In-Reply-To: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
References: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
Message-ID: <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Can you post a link?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Dan Howard <sproket at videotron.ca>
Date: Friday, August 8, 2025 at 04:13
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: FX 24.0.2 Some wav sounds don't play


Hi all,

Has anyone see this issue?

FX version 24.0.2
Windows 11 Version 10.0.26100 Build 26100
wav file 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit




Prior versions of JavaFX played this file properly. Somehow I'm finding a few files which don't play.  I hear them fine with apps like audacity.

Can I attach a zip of this file for someone to try it?   I have a large set of various wav files, most of which do play correctly.

TIA







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

From sproket at videotron.ca  Fri Aug  8 15:43:02 2025
From: sproket at videotron.ca (Dan Howard)
Date: Fri, 8 Aug 2025 11:43:02 -0400
Subject: FX 24.0.2 Some wav sounds don't play
In-Reply-To: <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
 <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <5ab94572-61f9-42d0-890f-ce3bc7325c1a@videotron.ca>

Sure, here you go

https://drive.google.com/drive/folders/1-Mx8RZqmrHZiQl3P8EvdBJOKGZA4OjId?usp=sharing

These are the 2 I found. Both with that same sample rate and sample size.

I solved by opening and exporting out as 16 bit sample size with audacity.

Thanks!


On 2025-08-08 11:03 a.m., Andy Goryachev wrote:
> Can you post a link?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Dan 
> Howard <sproket at videotron.ca>
> *Date: *Friday, August 8, 2025 at 04:13
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *FX 24.0.2 Some wav sounds don't play
>
> Hi all,
>
> Has anyone see this issue?
>
> FX version 24.0.2 Windows 11 Version 10.0.26100 Build 26100 wav file 
> 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit
>
>
> Prior versions of JavaFX played this file properly. Somehow I'm 
> finding a few files which don't play.? I hear them fine with apps like 
> audacity.
>
> Can I attach a zip of this file for someone to try it?? ?I have a 
> large set of various wav files, most of which do play correctly.
>
> TIA
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250808/d48868b5/attachment.htm>

From andy.goryachev at oracle.com  Fri Aug  8 16:37:49 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 8 Aug 2025 16:37:49 +0000
Subject: [External] : Re: FX 24.0.2 Some wav sounds don't play
In-Reply-To: <5ab94572-61f9-42d0-890f-ce3bc7325c1a@videotron.ca>
References: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
 <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <5ab94572-61f9-42d0-890f-ce3bc7325c1a@videotron.ca>
Message-ID: <CY8PR10MB72658F9905AFC7528B958EACE52FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Created https://bugs.openjdk.org/browse/JDK-8365173

If these files are unencumbered by licensing, I can attach them to the ticket.

-andy


From: Dan Howard <sproket at videotron.ca>
Date: Friday, August 8, 2025 at 08:43
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: FX 24.0.2 Some wav sounds don't play


Sure, here you go

https://drive.google.com/drive/folders/1-Mx8RZqmrHZiQl3P8EvdBJOKGZA4OjId?usp=sharing<https://urldefense.com/v3/__https://drive.google.com/drive/folders/1-Mx8RZqmrHZiQl3P8EvdBJOKGZA4OjId?usp=sharing__;!!ACWV5N9M2RV99hQ!L92uNMAZZDcKQLb2VPkNPAX_ezxQJYgS6obr65vlX-1EWJ6GlhON0DljfHK1jJHOqoDkllavDbd4YJJAVWu5Twg8$>

These are the 2 I found. Both with that same sample rate and sample size.

I solved by opening and exporting out as 16 bit sample size with audacity.

Thanks!


On 2025-08-08 11:03 a.m., Andy Goryachev wrote:
Can you post a link?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Dan Howard <sproket at videotron.ca><mailto:sproket at videotron.ca>
Date: Friday, August 8, 2025 at 04:13
To: openjfx-dev <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: FX 24.0.2 Some wav sounds don't play


Hi all,

Has anyone see this issue?

FX version 24.0.2
Windows 11 Version 10.0.26100 Build 26100
wav file 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit




Prior versions of JavaFX played this file properly. Somehow I'm finding a few files which don't play.  I hear them fine with apps like audacity.

Can I attach a zip of this file for someone to try it?   I have a large set of various wav files, most of which do play correctly.

TIA







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

From sproket at videotron.ca  Fri Aug  8 21:57:02 2025
From: sproket at videotron.ca (Dan Howard)
Date: Fri, 8 Aug 2025 17:57:02 -0400
Subject: [External] : Re: FX 24.0.2 Some wav sounds don't play
In-Reply-To: <CY8PR10MB72658F9905AFC7528B958EACE52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
 <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <5ab94572-61f9-42d0-890f-ce3bc7325c1a@videotron.ca>
 <CY8PR10MB72658F9905AFC7528B958EACE52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <346f9795-6bc7-4b86-aa22-ec924ebd7b7b@videotron.ca>

The files came from

https://sourceforge.net/projects/uaf/

It's GPL license.

Thanks!


On 2025-08-08 12:37 p.m., Andy Goryachev wrote:
> Created https://bugs.openjdk.org/browse/JDK-8365173
>
> If these files are unencumbered by licensing, I can attach them to the 
> ticket.
>
> -andy
>
>
> *From: *Dan Howard <sproket at videotron.ca>
> *Date: *Friday, August 8, 2025 at 08:43
> *To: *Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev 
> <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: FX 24.0.2 Some wav sounds don't play
>
> Sure, here you go
>
> https://drive.google.com/drive/folders/1-Mx8RZqmrHZiQl3P8EvdBJOKGZA4OjId?usp=sharing
>
> These are the 2 I found. Both with that same sample rate and sample size.
>
> I solved by opening and exporting out as 16 bit sample size with audacity.
>
> Thanks!
>
>
> On 2025-08-08 11:03 a.m., Andy Goryachev wrote:
>
>     Can you post a link?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>?on behalf of
>     Dan Howard <sproket at videotron.ca>
>     *Date: *Friday, August 8, 2025 at 04:13
>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>     *Subject: *FX 24.0.2 Some wav sounds don't play
>
>     Hi all,
>
>     Has anyone see this issue?
>
>     FX version 24.0.2 Windows 11 Version 10.0.26100 Build 26100 wav
>     file 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit
>
>
>     Prior versions of JavaFX played this file properly. Somehow I'm
>     finding a few files which don't play.? I hear them fine with apps
>     like audacity.
>
>     Can I attach a zip of this file for someone to try it?? ?I have a
>     large set of various wav files, most of which do play correctly.
>
>     TIA
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250808/b7b73184/attachment.htm>

From kevin.rushforth at oracle.com  Fri Aug  8 23:47:43 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 8 Aug 2025 16:47:43 -0700
Subject: [External] : Re: FX 24.0.2 Some wav sounds don't play
In-Reply-To: <346f9795-6bc7-4b86-aa22-ec924ebd7b7b@videotron.ca>
References: <beb21c99-7ea8-4307-9fcd-27039d3f3050@videotron.ca>
 <CY8PR10MB7265225F3317A9C0394FA157E52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <5ab94572-61f9-42d0-890f-ce3bc7325c1a@videotron.ca>
 <CY8PR10MB72658F9905AFC7528B958EACE52FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <346f9795-6bc7-4b86-aa22-ec924ebd7b7b@videotron.ca>
Message-ID: <403bc6af-763c-4bd4-b416-c5152acdeb0c@oracle.com>

In that case, we can test them, but we cannot attach them to JBS, put 
them in a repo, etc.

Thanks.

-- Kevin


On 8/8/2025 2:57 PM, Dan Howard wrote:
>
> The files came from
>
> https://sourceforge.net/projects/uaf/
>
> It's GPL license.
>
> Thanks!
>
>
> On 2025-08-08 12:37 p.m., Andy Goryachev wrote:
>> Created https://bugs.openjdk.org/browse/JDK-8365173
>>
>> If these files are unencumbered by licensing, I can attach them to 
>> the ticket.
>>
>> -andy
>>
>>
>> *From: *Dan Howard <sproket at videotron.ca>
>> *Date: *Friday, August 8, 2025 at 08:43
>> *To: *Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev 
>> <openjfx-dev at openjdk.org>
>> *Subject: *[External] : Re: FX 24.0.2 Some wav sounds don't play
>>
>> Sure, here you go
>>
>> https://drive.google.com/drive/folders/1-Mx8RZqmrHZiQl3P8EvdBJOKGZA4OjId?usp=sharing
>>
>> These are the 2 I found. Both with that same sample rate and sample 
>> size.
>>
>> I solved by opening and exporting out as 16 bit sample size with 
>> audacity.
>>
>> Thanks!
>>
>>
>> On 2025-08-08 11:03 a.m., Andy Goryachev wrote:
>>
>>     Can you post a link?
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>?on behalf of
>>     Dan Howard <sproket at videotron.ca>
>>     *Date: *Friday, August 8, 2025 at 04:13
>>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>>     *Subject: *FX 24.0.2 Some wav sounds don't play
>>
>>     Hi all,
>>
>>     Has anyone see this issue?
>>
>>     FX version 24.0.2 Windows 11 Version 10.0.26100 Build 26100 wav
>>     file 88kbps, 1 channel, sample rate 11.025 kHz, sample size 8 bit
>>
>>
>>     Prior versions of JavaFX played this file properly. Somehow I'm
>>     finding a few files which don't play.? I hear them fine with apps
>>     like audacity.
>>
>>     Can I attach a zip of this file for someone to try it?? ?I have a
>>     large set of various wav files, most of which do play correctly.
>>
>>     TIA
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250808/5a3c3817/attachment-0001.htm>

From tsayao at openjdk.org  Sat Aug  9 10:06:25 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 9 Aug 2025 10:06:25 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
Message-ID: <lb_e9lU2IffproTQSfG2Hnwf_BrLu404Wc10PbbfNpY=.95b3cdf5-c397-4dbc-9a76-4a2ad81f138e@github.com>

On Wed, 30 Jul 2025 22:46:32 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 60 commits:
>> 
>>  - Simplify notify_fullscreen
>>  - Merge branch 'master' into 8354943
>>  - Remove repaint call (8351867 is fixed)
>>  - Merge branch 'master' into 8354943
>>  - Remove unused const
>>  - Remove wrong call to enter_fullscreen
>>  - Review changes
>>  - Use process_expose
>>  - Min / Max size improvements
>>  - Invalidate view size on new view
>>  - ... and 50 more: https://git.openjdk.org/jfx/compare/bc433da8...d1842395
>
> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 184:
> 
>> 182:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>> 183:     @MethodSource("getTestsParams")
>> 184:     void openingModalChildStageWhileMaximizedShouldHaveFocus(StageStyle stageStyle, Modality modality)
> 
> This test includes "Focus" in the title but you don't seem to be asserting that the expected window has focus. This is true for several of the other tests in this file.

Fixed the method naming

> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 287:
> 
>> 285:                 () -> {
>> 286:                     assertTrue(stage0.isIconified());
>> 287:                     assertColorDoesNotEqual(COLOR0, stage0);
> 
> Are these the correct tests? If all stages are iconified you'll be picking up random colors from the desktop. One of those random colors might just match one of the color constants here.

I fixed the method name, but I think the test is correct - it does get a random color, but it tests for no match.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2264639868
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2264640207

From sykora at openjdk.org  Sat Aug  9 11:57:23 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Sat, 9 Aug 2025 11:57:23 GMT
Subject: RFR: 8356982: Update WebKit to 622.1
In-Reply-To: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
Message-ID: <7klWrt4l_ZUpSlImVWISwTHhcOylfj6IkttkDU6zGIY=.72e1e83f-021b-4576-874e-db8de02f1dd3@github.com>

On Wed, 6 Aug 2025 17:51:44 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.

Successfully built on all major platforms.

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

Marked as reviewed by sykora (Author).

PR Review: https://git.openjdk.org/jfx/pull/1865#pullrequestreview-3102932793

From tsayao at openjdk.org  Sat Aug  9 18:01:03 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 9 Aug 2025 18:01:03 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v52]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <2tbUZ-spAY61lNnVSfY4zui77p1XPdvS04bCbzmBWlA=.1efb7d4d-84e5-4609-8095-4a2313b95c74@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

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 63 commits:

 - Merge branch 'master' into 8354943
 - Fix failing tests + review adjustments
 - Merge branch 'master' into 8354943
 - Simplify notify_fullscreen
 - Merge branch 'master' into 8354943
 - Remove repaint call (8351867 is fixed)
 - Merge branch 'master' into 8354943
 - Remove unused const
 - Remove wrong call to enter_fullscreen
 - Review changes
 - ... and 53 more: https://git.openjdk.org/jfx/compare/00820f4f...f75d1cc2

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=51
  Stats: 4241 lines in 28 files changed: 2844 ins; 784 del; 613 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Sat Aug  9 18:24:06 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 9 Aug 2025 18:24:06 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v53]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <86F75XI78LS4tIMiLDk2Wcex-rt0uYOirF6H81Wh1ko=.b2e1ab9b-52a7-4dab-b19e-df7f63b31f6b@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Add hint about macOS beeps
  - Disable some tests on specific platforms

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/f75d1cc2..08984fb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=52
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=51-52

  Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1789/head:pull/1789

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

From tsayao at openjdk.org  Sat Aug  9 18:33:23 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 9 Aug 2025 18:33:23 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
Message-ID: <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>

On Wed, 30 Jul 2025 22:22:02 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 60 commits:
>> 
>>  - Simplify notify_fullscreen
>>  - Merge branch 'master' into 8354943
>>  - Remove repaint call (8351867 is fixed)
>>  - Merge branch 'master' into 8354943
>>  - Remove unused const
>>  - Remove wrong call to enter_fullscreen
>>  - Review changes
>>  - Use process_expose
>>  - Min / Max size improvements
>>  - Invalidate view size on new view
>>  - ... and 50 more: https://git.openjdk.org/jfx/compare/bc433da8...d1842395
>
> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 155:
> 
>> 153:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>> 154:     @EnumSource(names = {"DECORATED", "UNDECORATED", "EXTENDED", "TRANSPARENT", "UTILITY"})
>> 155:     void minSize(StageStyle stageStyle) {
> 
> The minSize test is failing on Windows for all stage styles. This is a legitimate bug; the platform is not correctly reporting back to the system that the size change failed. I will enter a bug and you can disable this test until the bug is fixed. (macOS is also failing the minSize and maxSize tests).

I've put an `assumeTrue(PlatformUtil.isWindows());` referencing JDK-8364547. Is it the correct bug?

> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 204:
> 
>> 202:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>> 203:     @MethodSource("getTestsParams")
>> 204:     void openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle stageStyle, Modality modality)
> 
> This test is passing on macOS but it's causing beeps. When the test is being torn down it's trying to hide the fullscreen window first even though it owns a visible modal window. After the window exits fullscreen the OS always tries to make it the key window (!?) even though JavaFX considers it disabled and this is causing Glass to beep and issue the FOCUS_DISABLED message.
> 
> There's nothing wrong with this test but it is inadvertently testing how the system deals with hiding a window while it owns a modal. But my main concern is that other macOS developers are going to be repeatedly tracking down where the beeps are coming from.

Added a text description on the full screen exit hint. Will also show up if searching for "beep".

> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 267:
> 
>> 265:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>> 266:     @EnumSource(names = {"DECORATED", "UNDECORATED", "EXTENDED"})
>> 267:     void iconifyParentShouldHideChildren(StageStyle style) {
> 
> These tests are failing on Windows for DECORATED and EXTENDED stages. You've got two levels of owned windows and the second level windows aren't getting minimized. This is due to an OS bug, it doesn't recurse through multiple ownership levels.
> 
> I suppose we could enter a bug on this but I doubt it would ever get fixed. It might make more sense to reduce the test to a single level of ownership.

Did an `assumeTrue(PlatformUtil.isWindows());` if style is `EXTENDED` or `UNDECORATED`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2264912292
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2264909365
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2264911706

From tsayao at openjdk.org  Sat Aug  9 20:46:57 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 9 Aug 2025 20:46:57 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v54]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <heVcaWo1vOpSgMIaJrJ0m3CgUploF0pcKZ5wYYN9CKI=.b5e9d962-56fc-4c13-94cd-b9dae6908177@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Fix mistake (assertTrue -> assumeTrue)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/08984fb0..b0339605

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=53
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=52-53

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

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

From tsayao at openjdk.org  Sun Aug 10 00:49:45 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 10 Aug 2025 00:49:45 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v55]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <livegaKLC93HT41lF4HtUYuRJE6UrS3iveTw4btPVrU=.6f473ab0-c597-4126-8a32-8264b00c5836@github.com>

> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
> 
> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
> 
> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
> 
> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
> 
> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
> 
> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
> 
> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
> 
> While this is focused on XWayland, everything works on pure Xorg as well.
> 
> List of fixed issues:
> 
> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
> 8. [DualWindowTest fails intermittently on Linux](https://bugs.openj...

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  - Fix (SetSceneScalingTest)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1789/files
  - new: https://git.openjdk.org/jfx/pull/1789/files/b0339605..f2a00117

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=54
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=53-54

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

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

From tsayao at openjdk.org  Sun Aug 10 22:11:22 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 10 Aug 2025 22:11:22 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v55]
In-Reply-To: <livegaKLC93HT41lF4HtUYuRJE6UrS3iveTw4btPVrU=.6f473ab0-c597-4126-8a32-8264b00c5836@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <livegaKLC93HT41lF4HtUYuRJE6UrS3iveTw4btPVrU=.6f473ab0-c597-4126-8a32-8264b00c5836@github.com>
Message-ID: <ouSJuX11aiWuMlsxjOOBghMaDqi8yfUaFbmpEPUWJ4w=.d8235da9-e69f-445c-ae5d-effbd63e7289@github.com>

On Sun, 10 Aug 2025 00:49:45 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Fix (SetSceneScalingTest)

The only remaining failing test (besides some that intermittently fails and works) is `DatePickerUpdateOnAlertCloseTest`. 

Seems to be focus related. It ends up getting the focus on different order and invalidates the value, calling (on line 179):


  datePicker.valueProperty().addListener(event -> {
        dialog.close();
    });

This causes the dialog to be closed before expected.

The test does not seem correct, because it re-uses the dialog, but the latches are not set up to be re-used.

Changing to `datePicker.valueProperty().addListener((obs, oldV, newV) -> { });` fixes it (but does not fix all the test in my opinion)

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3172923567

From arapte at openjdk.org  Mon Aug 11 03:47:36 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 11 Aug 2025 03:47:36 GMT
Subject: Integrated: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <3D7uWFC5OX4lxq_jN3YRZdr-Zm3-CiX36vTEqXF2J7w=.aac158fd-b90c-4abb-806a-187fd9dab136@github.com>

On Thu, 12 Jun 2025 05:41:23 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> ### Description
> This is the implementation of new graphics rendering pipeline for JavaFX using Metal APIs on MacOS.
> We released two Early Access (EA) builds and have reached a stage where it is ready to be integrated.
> Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose (by providing  `-Dprism.order=mtl`)
> The `-Dprism.verbose=true` option can be used to verify the rendering pipeline in use.
> 
> ### Details about the changes
> 
> **Shader changes**
> - MSLBackend class: This is the primary class that parses (Prism and Decora) jsl shaders into Metal shaders(msl)
> - There are a few additional Metal shader files added under directory : modules/javafx.graphics/src/main/native-prism-mtl/msl
> 
> **Build changes** - There are new tasks added to build.gradle for
> - Generation/ Compilation/ linking of Metal shaders
> - Compilation of Prism Java and Objective C files
> 
> **Prism** - Prism is the rendering engine of JavaFX.
> - Added Metal specific Java classes and respective native implementation which use Metal APIs
> - Java side changes:
>   - New Metal specific classes: Classes prefixed with MTL, are added here : modules/javafx.graphics/src/main/java/com/sun/prism/mtl 
>   - Modification to Prism common classes: A few limited changes were required in Prism common classes to support Metal classes. 
> - Native side changes:
>   - New Metal specific Objective C implementation is added here: modules/javafx.graphics/src/main/native-prism-mtl
> 
> **Glass** - Glass is the windowing toolkit of JavaFX
> - Existing Glass classes are refactored to support both OpenGL and Metal pipelines
> - Added Metal specific Glass implementation.
> 
> ### Testing
> - Testing performed on different hardware and macOS versions.
>   - HW - macBooks with Intel, Intel with discrete graphics card, Apple Silicon (M1, M2 and M4)
>   - macOS versions - macOS 13, macOS 14 and macOS 15
> - Functional Testing:
>   - All headful tests pass with Metal pipeline.
>   - Verified samples applications: Ensemble and toys
> - Performance Testing:
>   - Tested with RenderPerfTest: Almost all tests match/exceed es2 performance except a few that fall a little short on different hardwares. These will be addressed separately (there are open bugs already filed)
> 
> ### Note to reviewers :
> - Providing `-Dprism.order=mtl` option is a must for testing the Metal pipeline
> - It would be a good idea to test both OpenGL and Metal pipelines
> - Known issues and tasks ...

This pull request has now been integrated.

Changeset: f0312b0e
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f0312b0e3d384d5e1cfe905408983c66a61dd2bf
Stats:     12325 lines in 106 files changed: 11457 ins; 709 del; 159 mod

8271024: Implement macOS Metal Rendering Pipeline

Co-authored-by: Kevin Rushforth <kcr at openjdk.org>
Co-authored-by: Ajit Ghaisas <aghaisas at openjdk.org>
Co-authored-by: Jayathirth D V <jdv at openjdk.org>
Co-authored-by: Ambarish Rapte <arapte at openjdk.org>
Reviewed-by: angorya, nlisker, kcr, lkostyra

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

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

From jvos at openjdk.org  Mon Aug 11 12:11:21 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 11 Aug 2025 12:11:21 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
Message-ID: <ywMsSzwvrOoOQurc8ZHunQJUBC_rFkDOrXEzveHpEFA=.bf21e444-f3a7-409e-9a38-8e6a1c6d69ba@github.com>

On Tue, 5 Aug 2025 11:45:50 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove additional space

Both your original code as the patch you mention above work. I'm unsure what is the best (most elegant and most consistent approach).

The code in `com.sun.glass.ui.Platform` first checks if the property *"glass.platform"* is set, and only if that is not set, there is a fallback to `PlatformUtil`. 

`PlatformUtil` relies mainly on the value of the System Property *"os.name"*. 

But I believe there is an inconsistency in `PlatformUtil`. Some of the code uses the "glass.platform" as well, and I think that goes against the idea that "glass.platform" is glass-specific, where glass is part of the `javafx.graphics` module, hence it should be used in the `javafx.graphics` module, and *not* in the `javafx.base` module.
That would require a major refactory, where the overlap between the javafx.base `PlafformUtil` and the javafx.graphics `Platform` is removed.
@kevinrushforth Do you have any thoughts about this?

Since the current proposed PR is simple and useful (using `headless` instead of `Headless` should work indeed), I am ok with this PR, unless there is an easy solution that provides more consistency?

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3174485799

From hmeda at openjdk.org  Mon Aug 11 14:57:00 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 11 Aug 2025 14:57:00 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
Message-ID: <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>

> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  additional fixes for webkit

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1865/files
  - new: https://git.openjdk.org/jfx/pull/1865/files/0b9dd7d8..78e2be2e

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1865&range=00-01

  Stats: 6169 lines in 38 files changed: 1 ins; 6167 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1865.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1865/head:pull/1865

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

From kcr at openjdk.org  Mon Aug 11 15:29:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 11 Aug 2025 15:29:26 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
Message-ID: <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>

On Mon, 11 Aug 2025 14:57:00 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional fixes for webkit

I left a couple questions about your most recent commit. Also, can you add a comment about removing the unused "skia" files (as we discussed offline)?

modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 81:

> 79: #if !PLATFORM(JAVA)
> 80:     return !m_zstream.getPlatformStream().avail_in && (!m_didFinish || (m_didFinish && result == Z_STREAM_END));
> 81: #endif

I presume this came from upstream code? Was it just missed in the earlier set of updates?

In any case, this is a no-op, since it is "ifdef"ed out for our build of WebKit.

modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 91:

> 89:     return result != Z_OK && result != Z_STREAM_END && result != Z_BUF_ERROR;
> 90: #endif
> 91:     return true;

How did this even compile previously? Is this file actually included in our build?

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

PR Review: https://git.openjdk.org/jfx/pull/1865#pullrequestreview-3106412589
PR Review Comment: https://git.openjdk.org/jfx/pull/1865#discussion_r2267123640
PR Review Comment: https://git.openjdk.org/jfx/pull/1865#discussion_r2267125502

From hmeda at openjdk.org  Mon Aug 11 16:11:17 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 11 Aug 2025 16:11:17 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
 <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>
Message-ID: <MXRMdWzqKTT3ryBqW2URjVYlk0vqD6fyUVI8anAQC38=.4351d7c4-a631-444b-b34d-5812adf79889@github.com>

On Mon, 11 Aug 2025 15:24:47 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:
>> 
>>   additional fixes for webkit
>
> modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 81:
> 
>> 79: #if !PLATFORM(JAVA)
>> 80:     return !m_zstream.getPlatformStream().avail_in && (!m_didFinish || (m_didFinish && result == Z_STREAM_END));
>> 81: #endif
> 
> I presume this came from upstream code? Was it just missed in the earlier set of updates?
> 
> In any case, this is a no-op, since it is "ifdef"ed out for our build of WebKit.

Yes, this has been missed from the upstream code during update.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1865#discussion_r2267278747

From kcr at openjdk.org  Mon Aug 11 20:53:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 11 Aug 2025 20:53:18 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless
In-Reply-To: <lydbbBWgsqooWhIo6VN8VHLgaQADhyvMXyCtSgQjjUA=.4564066a-ecb7-4baa-a921-1682a8b7006e@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <lydbbBWgsqooWhIo6VN8VHLgaQADhyvMXyCtSgQjjUA=.4564066a-ecb7-4baa-a921-1682a8b7006e@github.com>
Message-ID: <_PMnB1k2ka2KidME8bg7ILv-X2vGthiQ23k4C57foLs=.612a6bb2-480b-4d38-9992-b73c490cfb2c@github.com>

On Tue, 5 Aug 2025 11:39:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Reviewer: @johanvos

> But I believe there is an inconsistency in `PlatformUtil`. Some of the code uses the "glass.platform" as well, and I think that goes against the idea that "glass.platform" is glass-specific, where glass is part of the `javafx.graphics` module, hence it should be used in the `javafx.graphics` module, and _not_ in the `javafx.base` module. That would require a major refactory, where the overlap between the javafx.base `PlafformUtil` and the javafx.graphics `Platform` is removed. @kevinrushforth Do you have any thoughts about this?

Yes it does seems a bit odd for something in `javafx.base` to use a system property that conceptually belongs to `javafx.graphics`. For that matter, methods like `useEGL`,  `isEmbedded`, and `isHeadless` really don't belong in `javafx.base`. I checked and there are no references to `PlatformUtil` in `javafx.base` at all. Perhaps the whole class should move to `javafx.graphics` along with addressing the issue of having two inconsistent ways to do the same thing? That might be a reasonable clean-up bug for the future.

> Since the current proposed PR is simple and useful (using `headless` instead of `Headless` should work indeed), I am ok with this PR, unless there is an easy solution that provides more consistency?

I also think the current patch as it stands is good (and better than the second alternative).

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3176849873

From kcr at openjdk.org  Mon Aug 11 21:45:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 11 Aug 2025 21:45:18 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
 <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>
Message-ID: <YwVPx8mg5BGUdGMt7wu2233J_mS_y7iAGfwmpXPSJl4=.2f8cd554-cb27-408b-89d6-b648f86938ae@github.com>

On Mon, 11 Aug 2025 15:25:28 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:
>> 
>>   additional fixes for webkit
>
> modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 91:
> 
>> 89:     return result != Z_OK && result != Z_STREAM_END && result != Z_BUF_ERROR;
>> 90: #endif
>> 91:     return true;
> 
> How did this even compile previously? Is this file actually included in our build?

Independent of how the code compiled before, it was clearly wrong.

So the more interesting question is: Is `true` the right return value for our port of WebKit? That appears to be an error return for this method.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1865#discussion_r2268084256

From kcr at openjdk.org  Mon Aug 11 21:45:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 11 Aug 2025 21:45:17 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
Message-ID: <oc__EtvP2aT6HScQHXeAxmX_wQRhnF6gRsiCBob_u0M=.836cd85e-2dfb-4b9e-a737-3f5955ba18f7@github.com>

On Mon, 11 Aug 2025 14:57:00 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional fixes for webkit

All my testing looks good. The diffs look good as well, although I have one pending question before I approve.

As for the removal of the unused skia code, my question was really a comment: this was removed because it is unused (which is good).

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

PR Review: https://git.openjdk.org/jfx/pull/1865#pullrequestreview-3107871812

From jbhaskar at openjdk.org  Tue Aug 12 03:32:23 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 12 Aug 2025 03:32:23 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <YwVPx8mg5BGUdGMt7wu2233J_mS_y7iAGfwmpXPSJl4=.2f8cd554-cb27-408b-89d6-b648f86938ae@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
 <VZiFvjfer7pReblzidG_uAAQswkK4PFsBs0ETEiRa-E=.48bf7a41-73d1-4c55-a967-8e3a9cf9391c@github.com>
 <YwVPx8mg5BGUdGMt7wu2233J_mS_y7iAGfwmpXPSJl4=.2f8cd554-cb27-408b-89d6-b648f86938ae@github.com>
Message-ID: <YQHvKHWIGPYkwgu97_rEvA8rh44qwdCx1xiHj2YXWjo=.1bdcb42b-1335-4d80-9f56-0c3aabe8f2cc@github.com>

On Mon, 11 Aug 2025 21:40:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.web/src/main/native/Source/WebCore/Modules/compression/CompressionStreamEncoder.cpp line 91:
>> 
>>> 89:     return result != Z_OK && result != Z_STREAM_END && result != Z_BUF_ERROR;
>>> 90: #endif
>>> 91:     return true;
>> 
>> How did this even compile previously? Is this file actually included in our build?
>
> Independent of how the code compiled before, it was clearly wrong.
> 
> So the more interesting question is: Is `true` the right return value for our port of WebKit? That appears to be an error return for this method.

zlib is not supported on our platform due to zlib dependency, so m_zstream is unused. didDeflateFinish() always returns true to indicate immediate completion with no side effects. 
m_zstream is never initialized or used in your MYP port
No compression work is done at all
Returning true simply tells the caller ?we?re done,? which is correct for a no-op compression path

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1865#discussion_r2268492223

From hmeda at openjdk.org  Tue Aug 12 04:30:19 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 12 Aug 2025 04:30:19 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <oc__EtvP2aT6HScQHXeAxmX_wQRhnF6gRsiCBob_u0M=.836cd85e-2dfb-4b9e-a737-3f5955ba18f7@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
 <oc__EtvP2aT6HScQHXeAxmX_wQRhnF6gRsiCBob_u0M=.836cd85e-2dfb-4b9e-a737-3f5955ba18f7@github.com>
Message-ID: <LteiyNHWRZS5TuyFR7svGrx8HOvzPcQBBPemuk-mPOw=.73e7b354-749d-443e-9b8a-681982cf6bc6@github.com>

On Mon, 11 Aug 2025 21:43:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> All my testing looks good. The diffs look good as well, although I have one pending question before I approve.
> 
> As for the removal of the unused skia code, my question was really a comment: this was removed because it is unused (which is good).

Yes, the unused skia files have been removed

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

PR Comment: https://git.openjdk.org/jfx/pull/1865#issuecomment-3177652744

From hmeda at openjdk.org  Tue Aug 12 04:30:20 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 12 Aug 2025 04:30:20 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <7klWrt4l_ZUpSlImVWISwTHhcOylfj6IkttkDU6zGIY=.72e1e83f-021b-4576-874e-db8de02f1dd3@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <7klWrt4l_ZUpSlImVWISwTHhcOylfj6IkttkDU6zGIY=.72e1e83f-021b-4576-874e-db8de02f1dd3@github.com>
Message-ID: <CUWD9qrJJFnk2ttmAyNFDjNP04MOgOSO775onZ93QYM=.2a4a60f2-b419-443d-8a0b-f4da7445e0ba@github.com>

On Sat, 9 Aug 2025 11:55:07 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional fixes for webkit
>
> Successfully built on all major platforms.

@tiainen Could you please re-approve the PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1865#issuecomment-3177654158

From jvos at openjdk.org  Tue Aug 12 08:18:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 12 Aug 2025 08:18:25 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
Message-ID: <2MtyuGIAvpSC8tx1cl5bzpRM7OQrQAms-m-6VkRQ6so=.47ee3371-0142-4ce5-9e86-e34ee9726ff6@github.com>

On Tue, 5 Aug 2025 11:45:50 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove additional space

Marked as reviewed by jvos (Reviewer).

I filed https://bugs.openjdk.org/browse/JDK-8365309 as a follow-up.

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

PR Review: https://git.openjdk.org/jfx/pull/1864#pullrequestreview-3109185683
PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3178227700

From kcr at openjdk.org  Tue Aug 12 11:54:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 12 Aug 2025 11:54:27 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
Message-ID: <vGBSESOQev6L0Gp00rRa2_NbwpHgfYPzY--1SvLGWfU=.096a1d08-d712-419b-a102-eb11c3bd97fc@github.com>

On Mon, 11 Aug 2025 14:57:00 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional fixes for webkit

LGTM with the additional explanation.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1865#pullrequestreview-3110087327

From sykora at openjdk.org  Tue Aug 12 16:13:24 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Tue, 12 Aug 2025 16:13:24 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <7klWrt4l_ZUpSlImVWISwTHhcOylfj6IkttkDU6zGIY=.72e1e83f-021b-4576-874e-db8de02f1dd3@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <7klWrt4l_ZUpSlImVWISwTHhcOylfj6IkttkDU6zGIY=.72e1e83f-021b-4576-874e-db8de02f1dd3@github.com>
Message-ID: <0grWv1mCFDMhkS-Z9eTVSbWbvxBHE0Q1Cf5orXMRWfc=.55c9e555-74bb-4711-8305-06c18aeed7bb@github.com>

On Sat, 9 Aug 2025 11:55:07 GMT, Joeri Sykora <sykora at openjdk.org> wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional fixes for webkit
>
> Successfully built on all major platforms.

> @tiainen Could you please re-approve the PR.

I've ran the build and tests again and everything worked fine.

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

PR Comment: https://git.openjdk.org/jfx/pull/1865#issuecomment-3180075518

From sykora at openjdk.org  Tue Aug 12 16:59:24 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Tue, 12 Aug 2025 16:59:24 GMT
Subject: RFR: 8356982: Update WebKit to 622.1 [v2]
In-Reply-To: <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
 <Tgnnl_hcJRU7VTwGPo9ZimSnCUommXu6iX2wlhYYbsc=.7dcff67e-e796-41e2-bd69-7a87add59bc5@github.com>
Message-ID: <-D8tHO8lvLcBkQqJWWUkwxPRP98-rBQ14INhORbUFpg=.e20421b5-bc3c-493c-8436-3e52d7668caa@github.com>

On Mon, 11 Aug 2025 14:57:00 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional fixes for webkit

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1865#pullrequestreview-3111885962

From hmeda at openjdk.org  Wed Aug 13 04:19:23 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 13 Aug 2025 04:19:23 GMT
Subject: Integrated: 8356982: Update WebKit to 622.1
In-Reply-To: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
References: <yH-worpRdDaY8hX010B2bUU-VnuPlYo2L2nPXs8wMSQ=.8d1f32f4-3375-4ff3-b262-d24c76d12686@github.com>
Message-ID: <xrTlm73xTHrUBwAzCFkEQ3VBm5ia_ILz7ivlswlBqUs=.0d7659a9-64ce-4e99-b4a5-0fb8fa33979f@github.com>

On Wed, 6 Aug 2025 17:51:44 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> This PR updates Webkit to v622.1. Verified sanity and build on Mac, Linux and windows platforms. No issue seen.

This pull request has now been integrated.

Changeset: 4a8f3abc
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4a8f3abc8ee665d1702df8d0bd63e9f663207ff1
Stats:     725643 lines in 8650 files changed: 284002 ins; 364224 del; 77417 mod

8356982: Update WebKit to 622.1
8328684: HellowWebView demo crashes when a webpage is scrolled
8360270: Websocket communication issues with Vaadin applications through webview

Co-authored-by: Jay Bhaskar <jbhaskar at openjdk.org>
Reviewed-by: sykora, kcr

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

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

From hmeda at openjdk.org  Wed Aug 13 06:36:57 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 13 Aug 2025 06:36:57 GMT
Subject: [jfx25u] RFR: 8356982: Update WebKit to 622.1
Message-ID: <DPpMTeza777pPaBoqxAUoMqRrnF7S-UbOTZP0e68qxU=.cf59835c-167f-4cd6-9624-da12327c178a@github.com>

clean backport

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

Commit messages:
 - Backport 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

Changes: https://git.openjdk.org/jfx25u/pull/5/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8356982
  Stats: 725643 lines in 8650 files changed: 284002 ins; 364224 del; 77417 mod
  Patch: https://git.openjdk.org/jfx25u/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/5/head:pull/5

PR: https://git.openjdk.org/jfx25u/pull/5

From johan.vos at gluonhq.com  Wed Aug 13 10:06:17 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 13 Aug 2025 12:06:17 +0200
Subject: StackOverflowError in recursive Subscription.unsubscribe
Message-ID: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>

Hi,

The current implementation of Subscription.unsubscribe() uses recursion to
unsubscribe the chain of subscriptions. This can lead to a
StackOverflowError in case there are many chained subscriptions. Running
the following code demonstrates this:

```
    void testSubs() {
        SimpleStringProperty prop = new SimpleStringProperty("simpel");
        Subscription s = prop.subscribe(() -> {});
        for (int i = 0; i < 100000; i++) {
            Subscription t = prop.subscribe(() -> {});
            s = s.and(t);
        }
        s.unsubscribe();
    }
```

This results in
```
java.lang.StackOverflowError
at javafx.base at 26-ea
/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
at javafx.base at 26-ea
/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
at javafx.base at 26-ea
/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
...
```

While it's unusual (and in most cases a very bad idea) to chain that many
Subscriptions, I don't think this should give a StackOverflow Error. I
believe it is better to avoid recursion in the implementation. If people
agree, I'll file an issue for this.

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250813/dc3e2ce0/attachment.htm>

From kcr at openjdk.org  Wed Aug 13 10:53:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 13 Aug 2025 10:53:21 GMT
Subject: [jfx25u] RFR: 8356982: Update WebKit to 622.1
In-Reply-To: <DPpMTeza777pPaBoqxAUoMqRrnF7S-UbOTZP0e68qxU=.cf59835c-167f-4cd6-9624-da12327c178a@github.com>
References: <DPpMTeza777pPaBoqxAUoMqRrnF7S-UbOTZP0e68qxU=.cf59835c-167f-4cd6-9624-da12327c178a@github.com>
Message-ID: <rQXuhiz0-RGjXpicTD6dsa0_0Noz1PPlIGhPoDice8g=.9866f3d8-a5a3-4467-9d51-ba2603037e40@github.com>

On Wed, 13 Aug 2025 06:25:57 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> clean backport

I verified that this is clean backport (Skara was unable to, since it is a large patch).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx25u/pull/5#pullrequestreview-3115219103

From hmeda at openjdk.org  Wed Aug 13 12:09:21 2025
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 13 Aug 2025 12:09:21 GMT
Subject: [jfx25u] Integrated: 8356982: Update WebKit to 622.1
In-Reply-To: <DPpMTeza777pPaBoqxAUoMqRrnF7S-UbOTZP0e68qxU=.cf59835c-167f-4cd6-9624-da12327c178a@github.com>
References: <DPpMTeza777pPaBoqxAUoMqRrnF7S-UbOTZP0e68qxU=.cf59835c-167f-4cd6-9624-da12327c178a@github.com>
Message-ID: <gst8ePftekCB6FQZKaqyz21fb5tZFS9w5KWwsekXtUQ=.a8208cc2-aa98-4ca2-83e7-d5dd908e5ae2@github.com>

On Wed, 13 Aug 2025 06:25:57 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> clean backport

This pull request has now been integrated.

Changeset: 5fe621ea
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/5fe621ea83969566352e9aa9185534caf0f11a5e
Stats:     725643 lines in 8650 files changed: 284002 ins; 364224 del; 77417 mod

8356982: Update WebKit to 622.1
8328684: HellowWebView demo crashes when a webpage is scrolled
8360270: Websocket communication issues with Vaadin applications through webview

Reviewed-by: kcr
Backport-of: 4a8f3abc8ee665d1702df8d0bd63e9f663207ff1

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

PR: https://git.openjdk.org/jfx25u/pull/5

From jdv at openjdk.org  Wed Aug 13 13:15:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Aug 2025 13:15:41 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
Message-ID: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>

We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.

Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.

This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then pass it to glass code. When SWPipeline is used based on this flag we will use appropriate hardware pipeline in glass.

Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

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

Commit messages:
 - 8350479: SW pipeline should use default pipeline in Glass

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

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

From john.hendrikx at gmail.com  Wed Aug 13 20:11:48 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 13 Aug 2025 22:11:48 +0200
Subject: StackOverflowError in recursive Subscription.unsubscribe
In-Reply-To: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>
References: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>
Message-ID: <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>

You're right, this should preferably not happen.? The implementation is
simple, but it does limit how many subscriptions you can chain.

The `combine` variant does not have the same issue.

I can rewrite it to avoid recursion, but it needs to be done very
carefully as the subscriptions chained with `and` basically form a
graph, and unsubscribing an older reference should not unsubscribe more
than it would have done before calling `and`.

--John

On 13/08/2025 12:06, Johan Vos wrote:
> Hi,
>
> The current implementation of Subscription.unsubscribe() uses
> recursion?to unsubscribe the chain of subscriptions. This can lead to
> a StackOverflowError in case there are many chained subscriptions.
> Running the following code demonstrates this:
>
> ```
> ? ? void testSubs() {
> ? ? ? ? SimpleStringProperty prop = new SimpleStringProperty("simpel");
> ? ? ? ? Subscription s = prop.subscribe(() -> {});
> ? ? ? ? for (int i = 0; i < 100000; i++) {
> ? ? ? ? ? ? Subscription t = prop.subscribe(() -> {});
> ? ? ? ? ? ? s = s.and(t);
> ? ? ? ? }
> ? ? ? ? s.unsubscribe();
> ? ? }
> ```
>
> This results in
> ```
> java.lang.StackOverflowError
> at
> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> at
> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> at
> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> ...
> ```
>
> While it's unusual (and in most cases a very bad idea) to chain that
> many Subscriptions, I don't think this should give a StackOverflow
> Error. I believe it is better to avoid recursion in the
> implementation. If people agree, I'll file an issue for this.
>
> - Johan

From john.hendrikx at gmail.com  Wed Aug 13 21:17:43 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 13 Aug 2025 23:17:43 +0200
Subject: StackOverflowError in recursive Subscription.unsubscribe
In-Reply-To: <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>
References: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>
 <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>
Message-ID: <57641b0f-3902-46f7-89cc-dc358945711c@gmail.com>

It's an interesting problem. I wrote some test cases, and came to this
solution to allow large amounts of chained subscriptions, while
maintaining Subscriptions as immutable constructs that will only
unsubscribe exactly the right subscriptions when using older references:

defaultSubscription and(Subscription other) {

Objects.requireNonNull(other, "other cannot be null");

returnnewNodeSubscription(this, other);

}

// TODOmove to package to make it package private

staticclassNodeSubscription implementsSubscription {

privatefinalSubscription s1;

privatefinalSubscription s2;

publicNodeSubscription(Subscription s1, Subscription s2) {

booleanshouldSwap = s1 instanceofNodeSubscription; // attempt to avoid
growing stack as much as possible

this.s1= shouldSwap ? s2 : s1;

this.s2= shouldSwap ? s1 : s2;

}

@Override

publicvoidunsubscribe() {

List<Subscription> stack = newArrayList<>();

stack.add(this);

while(!stack.isEmpty()) {

Subscription s = stack.removeLast();

if(s instanceofNodeSubscription n) {

stack.add(n.s1);

stack.add(n.s2);

}

else{

s.unsubscribe();

}

}

}

}

Note: as prescribed by the specification,?`unsubscribe` is idempotent.

--John


On 13/08/2025 22:11, John Hendrikx wrote:
> You're right, this should preferably not happen.? The implementation is
> simple, but it does limit how many subscriptions you can chain.
>
> The `combine` variant does not have the same issue.
>
> I can rewrite it to avoid recursion, but it needs to be done very
> carefully as the subscriptions chained with `and` basically form a
> graph, and unsubscribing an older reference should not unsubscribe more
> than it would have done before calling `and`.
>
> --John
>
> On 13/08/2025 12:06, Johan Vos wrote:
>> Hi,
>>
>> The current implementation of Subscription.unsubscribe() uses
>> recursion?to unsubscribe the chain of subscriptions. This can lead to
>> a StackOverflowError in case there are many chained subscriptions.
>> Running the following code demonstrates this:
>>
>> ```
>> ? ? void testSubs() {
>> ? ? ? ? SimpleStringProperty prop = new SimpleStringProperty("simpel");
>> ? ? ? ? Subscription s = prop.subscribe(() -> {});
>> ? ? ? ? for (int i = 0; i < 100000; i++) {
>> ? ? ? ? ? ? Subscription t = prop.subscribe(() -> {});
>> ? ? ? ? ? ? s = s.and(t);
>> ? ? ? ? }
>> ? ? ? ? s.unsubscribe();
>> ? ? }
>> ```
>>
>> This results in
>> ```
>> java.lang.StackOverflowError
>> at
>> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>> at
>> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>> at
>> javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>> ...
>> ```
>>
>> While it's unusual (and in most cases a very bad idea) to chain that
>> many Subscriptions, I don't think this should give a StackOverflow
>> Error. I believe it is better to avoid recursion in the
>> implementation. If people agree, I'll file an issue for this.
>>
>> - Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250813/d284d6ea/attachment-0001.htm>

From jdv at openjdk.org  Thu Aug 14 07:26:04 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 14 Aug 2025 07:26:04 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Pick default pipeline from PrismSettings

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1868/files
  - new: https://git.openjdk.org/jfx/pull/1868/files/0fabc106..859d4266

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

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

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

From jvos at openjdk.org  Thu Aug 14 09:48:24 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 14 Aug 2025 09:48:24 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <UALLHqgJpYSbxAPhCy8Bxisx0RX-9jVQd4J4keSnPeU=.bdc22055-eefa-41e9-822b-3763a1bc78f0@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
 <UALLHqgJpYSbxAPhCy8Bxisx0RX-9jVQd4J4keSnPeU=.bdc22055-eefa-41e9-822b-3763a1bc78f0@github.com>
Message-ID: <xk9FFdm4jl7dtvutMHa909FNHsLgVrro6_QpLMiVjqU=.9ed169d5-6dec-425f-98d0-843c386cee4b@github.com>

On Wed, 6 Aug 2025 21:08:30 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove additional space
>
> `com.sun.javafx.PlatformUtil::isHeadless` returns `true` for any case matching `"headless"`, which is not what i provided in my original suggestion.
> So maybe we could reuse it :
> 
> 
>             if (userPlatform != null) {
>                 if (userPlatform.equals("macosx"))
>                     type = MAC;
>                 else if (userPlatform.equals("windows"))
>                     type = WINDOWS;
>                 else if (userPlatform.equals("linux"))
>                     type = GTK;
>                 else if (userPlatform.equals("gtk"))
>                     type = GTK;
>                 else if (userPlatform.equals("ios"))
>                     type = IOS;
>                 else
>                     if (PlatformUtil.isHeadless())
>                         type = HEADLESS;
>                     else
>                         type = userPlatform;
>                 return type;
>             }
> 
> 
> Makes the code a bit clumsy to me, but has the benefit of reusing logic.

@CodeSimcoe Feel free to integrate this PR at your convenience.

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3187820961

From duke at openjdk.org  Thu Aug 14 09:51:29 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 09:51:29 GMT
Subject: RFR: 8364687: Enable headless with -Dglass.platform=headless [v2]
In-Reply-To: <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
 <0Gw9mIGOHfSrUhe_XmHXmzMXQaAwUEFhyv02oYhVWm4=.7274fd66-dd3b-4f28-8483-a315602cedc2@github.com>
Message-ID: <fb3WNcNC93jFPUOaUYzQfWBmBmTG1junNUxLnyCMuu4=.13003842-5566-41e4-859f-6e53ce846678@github.com>

On Tue, 5 Aug 2025 11:45:50 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

>> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
>> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.
>
> Cl?ment de Tastes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove additional space

@CodeSimcoe 
Your change (at version 91d6076d1316e4a406cd619b23092304877ce1e1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1864#issuecomment-3187829603

From duke at openjdk.org  Thu Aug 14 10:14:20 2025
From: duke at openjdk.org (=?UTF-8?B?Q2zDqW1lbnQ=?= de Tastes)
Date: Thu, 14 Aug 2025 10:14:20 GMT
Subject: Integrated: 8364687: Enable headless with -Dglass.platform=headless
In-Reply-To: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
References: <2O6a7SHL1W6Ey4PQYzqh9ObWVB1fg-2uWuJraRKdzzc=.2c14adc6-3179-45f5-a789-fe1fd9d1c866@github.com>
Message-ID: <WwTNme21oEaz_jFBElCPit79EkTdh0qdKa1SuDSoe40=.53d8468e-8d7e-456c-9c8d-8093b74ebeda@github.com>

On Tue, 5 Aug 2025 07:45:34 GMT, Cl?ment de Tastes <duke at openjdk.org> wrote:

> Basically allow -Dglass.platform=headless to enable headless, not only -Dglass.platform=Headless.
> This makes it consistent with other options (macosx, windows, linux, gtk and ios) as well was less error-prone for enabling it.

This pull request has now been integrated.

Changeset: 1dda20b7
Author:    Cl?ment de Tastes <clement.detastes at gmail.com>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1dda20b72eae2b9e12eb1217504977b45ddff6b8
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8364687: Enable headless with -Dglass.platform=headless

Reviewed-by: jvos

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

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

From ltorroja at cass.ad  Thu Aug 14 13:00:27 2025
From: ltorroja at cass.ad (ltorroja at cass.ad)
Date: Thu, 14 Aug 2025 15:00:27 +0200
Subject: =?ISO-8859-1?Q?AUTO=3A_Lluis_Torroja_Fontanet_=E9s_fora_de_l'oficina_?=
Message-ID: <OF2DB82FF7.5EA82A7D-ONC1258CE6.004773D9-C1258CE6.004773D9@cass.ad>


S?c fora de l'oficina de Dj 08/14/2025 a Dt 09/09/2025.

Hola,

Gr?cies pel teu missatge. Actualment estic fora de l?oficina i no tindr?
acc?s al correu electr?nic fins al [09/09/2025].
Et respondr? tan aviat com sigui possible a la meva tornada.

Gr?cies per la comprensi?.

Salutacions,


Nota: Aquesta ?s una resposta autom?tica al vostre missatge  "openjfx-dev
Digest, Vol 165, Issue 49" enviat el 08/14/2025 12:14:25 PM.

Aquesta ?s l'?nica notificaci? que rebreu mentre aquesta persona sigui
fora.

From kcr at openjdk.org  Thu Aug 14 13:29:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Aug 2025 13:29:25 GMT
Subject: [jfx25u] RFR: Merge jfx:jfx25
Message-ID: <0WLHdtMX2cye0maHEiCum8SvzTW55BrH1F1Kpq6f0Fk=.5f674ea0-ec9a-46d7-befe-0e5279e4ba2b@github.com>

Clean merge of `jfx:jfx25` into `jfx25u:master`.

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

Commit messages:
 - Merge remote-tracking branch 'jfx/jfx25' into merge-jfx-jfx25-to-master-2025-08-14
 - 8364049: ToolBar shows overflow menu with fractional scale
 - 8364088: ToolBarSkin: NPE in select()

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx25u/pull/6/files
  Stats: 64 lines in 2 files changed: 54 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jfx25u/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/6/head:pull/6

PR: https://git.openjdk.org/jfx25u/pull/6

From kcr at openjdk.org  Thu Aug 14 13:35:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 14 Aug 2025 13:35:19 GMT
Subject: [jfx25u] Integrated: Merge jfx:jfx25
In-Reply-To: <0WLHdtMX2cye0maHEiCum8SvzTW55BrH1F1Kpq6f0Fk=.5f674ea0-ec9a-46d7-befe-0e5279e4ba2b@github.com>
References: <0WLHdtMX2cye0maHEiCum8SvzTW55BrH1F1Kpq6f0Fk=.5f674ea0-ec9a-46d7-befe-0e5279e4ba2b@github.com>
Message-ID: <Mm_B8Io6oQKez6dYuoib78jiY0AsXH7_A6-G_QXw_PQ=.7ac5f17d-4bec-4b78-9011-fdfc6c5d8ef4@github.com>

On Thu, 14 Aug 2025 13:24:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of `jfx:jfx25` into `jfx25u:master`.

This pull request has now been integrated.

Changeset: 87adc616
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/87adc616534c037ac1fd961e98001d2981ed3f71
Stats:     64 lines in 2 files changed: 54 ins; 3 del; 7 mod

Merge

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

PR: https://git.openjdk.org/jfx25u/pull/6

From mfox at openjdk.org  Thu Aug 14 15:16:29 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 15:16:29 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
 <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
Message-ID: <ZoSZbppnnoXcNyvTMtelu5dba54b8x8PBmRYy9i6btU=.86a22374-9c72-45b2-b630-94b73806cafa@github.com>

On Sat, 9 Aug 2025 18:25:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 204:
>> 
>>> 202:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>>> 203:     @MethodSource("getTestsParams")
>>> 204:     void openingModalChildStageWhileFullScreenShouldHaveFocus(StageStyle stageStyle, Modality modality)
>> 
>> This test is passing on macOS but it's causing beeps. When the test is being torn down it's trying to hide the fullscreen window first even though it owns a visible modal window. After the window exits fullscreen the OS always tries to make it the key window (!?) even though JavaFX considers it disabled and this is causing Glass to beep and issue the FOCUS_DISABLED message.
>> 
>> There's nothing wrong with this test but it is inadvertently testing how the system deals with hiding a window while it owns a modal. But my main concern is that other macOS developers are going to be repeatedly tracking down where the beeps are coming from.
>
> Added a text description on the full screen exit hint. Will also show up if searching for "beep".

Good enough. Thanks.

>> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 287:
>> 
>>> 285:                 () -> {
>>> 286:                     assertTrue(stage0.isIconified());
>>> 287:                     assertColorDoesNotEqual(COLOR0, stage0);
>> 
>> Are these the correct tests? If all stages are iconified you'll be picking up random colors from the desktop. One of those random colors might just match one of the color constants here.
>
> I fixed the method name, but I think the test is correct - it does get a random color, but it tests for no match.

Since it picks up a random color it could get a match by accident. Highly unlikely but possible.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276920131
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276923455

From mfox at openjdk.org  Thu Aug 14 15:30:27 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 15:30:27 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
 <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
Message-ID: <iKTVR5zKzaC6vGk7b4uQDSEd4ns23_UIqClvY6oGlU8=.1dce0a9c-0a12-46ff-9845-f820d2f438a3@github.com>

On Sat, 9 Aug 2025 18:30:10 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/stage/SizingTest.java line 155:
>> 
>>> 153:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>>> 154:     @EnumSource(names = {"DECORATED", "UNDECORATED", "EXTENDED", "TRANSPARENT", "UTILITY"})
>>> 155:     void minSize(StageStyle stageStyle) {
>> 
>> The minSize test is failing on Windows for all stage styles. This is a legitimate bug; the platform is not correctly reporting back to the system that the size change failed. I will enter a bug and you can disable this test until the bug is fixed. (macOS is also failing the minSize and maxSize tests).
>
> I've put an `assumeTrue(PlatformUtil.isWindows());` referencing JDK-8364547. Is it the correct bug?

Just remove the assumeTrue call here. I'll submit the fix for JDK-8364547 in the next day or so and then these system tests will just work.

>> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java line 267:
>> 
>>> 265:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
>>> 266:     @EnumSource(names = {"DECORATED", "UNDECORATED", "EXTENDED"})
>>> 267:     void iconifyParentShouldHideChildren(StageStyle style) {
>> 
>> These tests are failing on Windows for DECORATED and EXTENDED stages. You've got two levels of owned windows and the second level windows aren't getting minimized. This is due to an OS bug, it doesn't recurse through multiple ownership levels.
>> 
>> I suppose we could enter a bug on this but I doubt it would ever get fixed. It might make more sense to reduce the test to a single level of ownership.
>
> Did an `assumeTrue(PlatformUtil.isWindows());` if style is `EXTENDED` or `UNDECORATED`

I think you use assumeTrue to check whether the test should proceed. So you want `assumeTrue(!PlatformUtil.isWindows())` or `assumeFalse(PlatformUtil.isWindows())`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276964751
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276965466

From mfox at openjdk.org  Thu Aug 14 15:36:30 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 15:36:30 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
Message-ID: <A6SLVZQERnvvpivyWGTcC6tp0hUFTLr6LXvWN3uXIdI=.f15271a1-dff3-4a76-8d19-68412bc2638c@github.com>

On Wed, 30 Jul 2025 22:17:15 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 60 commits:
>> 
>>  - Simplify notify_fullscreen
>>  - Merge branch 'master' into 8354943
>>  - Remove repaint call (8351867 is fixed)
>>  - Merge branch 'master' into 8354943
>>  - Remove unused const
>>  - Remove wrong call to enter_fullscreen
>>  - Review changes
>>  - Use process_expose
>>  - Min / Max size improvements
>>  - Invalidate view size on new view
>>  - ... and 50 more: https://git.openjdk.org/jfx/compare/bc433da8...d1842395
>
> tests/system/src/test/java/test/javafx/stage/CenterOnScreenTest.java line 108:
> 
>> 106:     }
>> 107: 
>> 108:     private void assertStageCentered(StageStyle stageStyle, boolean useSceneSize) {
> 
> On Windows the size of a DECORATED or EXTENDED window includes an area around the window containing the invisible drag handles. After sizeToScene is called on my Windows 11 system a DECORATED or EXTENDED window will be 26 units wider than the scene to account for these handles (on my Mac the window will be the same width as the scene).
> 
> In this test you use a hefty delta for DECORATED windows and a smaller one for EXTENDED and you use the same delta for both width and height. This is causing the centerOnScreenAfterShownWithSceneSize and centerOnScreenWhenShownWithSceneSize test to fail along the X axis for EXTENDED stages since the delta isn't big enough.
> 
> You might consider querying the stage for it's frame and ensure that the center of the frame is where you expect it rather than make any assumptions about how the scene width relates to the window width.

The test still looks incorrect. You're passing in posX and posY as the tolerance deltas.

I'm not sure what you're testing here. There's an internal algorithm that sets the window's x and y coordinate to center it. You're replicating that algorithm here and testing whether the window has the same x and y values. If you're concerned that the platform code didn't actually move the window you would need to use a robot to sample a pixel and verify that the window is where you expect. Or was there some other centering problem you saw on Linux?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276980571

From mfox at openjdk.org  Thu Aug 14 15:40:26 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 15:40:26 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <iKTVR5zKzaC6vGk7b4uQDSEd4ns23_UIqClvY6oGlU8=.1dce0a9c-0a12-46ff-9845-f820d2f438a3@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
 <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>
 <4zHQ3O35bEGkawopury3gtKBqmOowu6lQlHbUWXnSE0=.e66103cd-6a29-4f45-95cf-4bfee8e46238@github.com>
 <iKTVR5zKzaC6vGk7b4uQDSEd4ns23_UIqClvY6oGlU8=.1dce0a9c-0a12-46ff-9845-f820d2f438a3@github.com>
Message-ID: <vKVzXdFvpymr1u5lAyONbLtcP-lbNqa4QoCXtBiwG_w=.b8fdd823-f543-4974-bee7-6d3e76aca28f@github.com>

On Thu, 14 Aug 2025 15:26:59 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> I've put an `assumeTrue(PlatformUtil.isWindows());` referencing JDK-8364547. Is it the correct bug?
>
> Just remove the assumeTrue call here. I'll submit the fix for JDK-8364547 in the next day or so and then these system tests will just work.

BTW, it's both the minSize and maxSize tests that are failing on both Mac and Windows. It's really just easier to fix these bugs in advance of submitting this system test.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2276991893

From mfox at openjdk.org  Thu Aug 14 15:48:25 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 15:48:25 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v55]
In-Reply-To: <livegaKLC93HT41lF4HtUYuRJE6UrS3iveTw4btPVrU=.6f473ab0-c597-4126-8a32-8264b00c5836@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <livegaKLC93HT41lF4HtUYuRJE6UrS3iveTw4btPVrU=.6f473ab0-c597-4126-8a32-8264b00c5836@github.com>
Message-ID: <w9xtxHyc20gXAliiJuMDrYl9BHbUo_2jN0If52d70MY=.26d32188-b8ab-4240-a438-f6946b576929@github.com>

On Sun, 10 Aug 2025 00:49:45 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This is a continuation to [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to stabilize the linux glass gtk backend.
>> 
>> This is a refactor of the Glass GTK implementation, primarily focused on window size, positioning, and state management to resolve numerous issues.
>> 
>> The main change is that GtkWindow (which is a GtkWidget) has been replaced with a direct use of GdkWindow for windows. This makes sense because GTK includes its own rendering pipeline, whereas JavaFX renders directly to the underlying system window (such as the X11 window) via Prism ES2 using GL and GLX. Most GTK window-related calls have equivalent GDK calls. Since GDK serves as an abstraction over the system window and input events, it aligns better with the purposes of Glass. Additionally, using GTK required various workarounds to integrate with Glass, which are no longer necessary when using GDK directly.
>> 
>> It uses a simple C++ Observable to notify the Java side about changes. This approach is more straightforward, as notifications occur at many points and the previous implementation was becoming cluttered.
>> 
>> Previously, there were three separate context classes, two of which were used for Java Web Start and Applets. These have now been unified, as they are no longer required.
>> 
>> Many tests were added to ensure everything is working correctly. I noticed that some tests produced different results depending on the StageStyle, so they now use @ParameterizedTest to vary the StageStyle.
>> 
>> A manual test is also provided. I did not use MonkeyTester for this, as it was quicker to simply run and test manually:`java @build/run.args tests/manual/stage/TestStage.java `
>> 
>> While this is focused on XWayland, everything works on pure Xorg as well.
>> 
>> List of fixed issues:
>> 
>> 1. [[Linux] Stage.setMaximized() before show() does not persist](https://bugs.openjdk.org/browse/JDK-8316425)
>> 3. [[Linux] Intermittent test failure in IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-8316891)
>> 4. [[Linux] Initial window position is not centered on Ubuntu 24.04 / Xorg](https://bugs.openjdk.org/browse/JDK-8337400)
>> 5. [[Linux] Some of the SizeToSceneTest fail in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353612)
>> 6. [[Linux] View size glitch when resizing past max window size](https://bugs.openjdk.org/browse/JDK-8355073)
>> 7. [RestoreSceneSizeTest fails in Ubuntu 24.04](https://bugs.openjdk.org/browse/JDK-8353556)
>> 8. [DualWindowTest...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Fix (SetSceneScalingTest)

I took a look at DatePickerUpdateOnAlertCloseTest and agree it looks wrong. It does seem to be re-using latches incorrectly.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3188932328

From mfox at openjdk.org  Thu Aug 14 16:31:33 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 14 Aug 2025 16:31:33 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min or
 max
Message-ID: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>

When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.

This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.

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

Commit messages:
 - If min/max window size enforced send notification to correct Window properties
 - Merge remote-tracking branch 'upstream/master' into sendcorrectsize
 - Comment cleanup
 - Notify WindowStage if setBounds didn't change the size as expected

Changes: https://git.openjdk.org/jfx/pull/1870/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364547
  Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1870.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1870/head:pull/1870

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

From zelmidaoui at openjdk.org  Thu Aug 14 20:28:38 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Thu, 14 Aug 2025 20:28:38 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
Message-ID: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>

The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue

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

Commit messages:
 - Merge branch 'openjdk:master' into 8322486.colorpicker
 - Changing -fx-snap-to-pixel to true

Changes: https://git.openjdk.org/jfx/pull/1869/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1869&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322486
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1869.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1869/head:pull/1869

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

From mhanl at openjdk.org  Fri Aug 15 09:15:20 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 15 Aug 2025 09:15:20 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
Message-ID: <L8zHl4UuQyBKIJF6gxaEXB50diExWQ2h1vEoQOsd6O0=.e36b9dc5-732c-41e1-8c49-d9aae92b6946@github.com>

On Wed, 13 Aug 2025 12:31:32 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
> This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue

modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 1982:

> 1980: .color-palette > .color-picker-grid {
> 1981:     -fx-padding: 0.5px;
> 1982:     -fx-snap-to-pixel: true;

I guess we can completely remove this line then?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1869#discussion_r2278626123

From johan.vos at gluonhq.com  Fri Aug 15 10:39:59 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 15 Aug 2025 12:39:59 +0200
Subject: StackOverflowError in recursive Subscription.unsubscribe
In-Reply-To: <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>
References: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>
 <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>
Message-ID: <CABxFH2Fajhv5a=wdXeTQmr69s4PPL25xBtB+ynWu3NKw3MWpcA@mail.gmail.com>

Adding to this, I investigated what was exactly happening in my case. There
was a Subscription with a few thousands recursive subscriptions, which were
created by `and`.
However, only a few of those subscriptions were still "active".
When calling Subscription.unsubscribe() in case of a combined subscription,
the listeners will be removed, but the inner Subscription objects are not
removed, so the combined subscription keeps having multiple inner
subscriptions.
This is a different, but related issue. The following pattern is thus wrong
and dangerous:
```
Subscription s = Subscription.EMPTY;
for (int i = 0; i < 100; i++) {
    s.unsubscribe();
    s = s.and(fooProperty.subscribe(val -> ...));
    s = s.and(barProperty.subscribe(val -> ...));
 }
```

The `s.unsubscribe` keeps strong references to all previously added
subscriptions. It has to recursively loop over a growing list of
Subscription.unsubscribe() calls.
Adding `s = Subscription.EMPTY` after `s.unsubscribe()` fixes that problem.

So I believe there are 2 different issues:
1. as reported in the original post, the recursive approach in unsubscribe
can lead to StackOverflowErrors in case of many chained subscriptions
2. it is not clear from the documentation that Subscription.unsubscribe()
is not removing the subscriptions (it just unsubscribes, but keeps the
whole structure on the heap).

- Johan


On Wed, Aug 13, 2025 at 10:12?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> You're right, this should preferably not happen.  The implementation is
> simple, but it does limit how many subscriptions you can chain.
>
> The `combine` variant does not have the same issue.
>
> I can rewrite it to avoid recursion, but it needs to be done very
> carefully as the subscriptions chained with `and` basically form a
> graph, and unsubscribing an older reference should not unsubscribe more
> than it would have done before calling `and`.
>
> --John
>
> On 13/08/2025 12:06, Johan Vos wrote:
> > Hi,
> >
> > The current implementation of Subscription.unsubscribe() uses
> > recursion to unsubscribe the chain of subscriptions. This can lead to
> > a StackOverflowError in case there are many chained subscriptions.
> > Running the following code demonstrates this:
> >
> > ```
> >     void testSubs() {
> >         SimpleStringProperty prop = new SimpleStringProperty("simpel");
> >         Subscription s = prop.subscribe(() -> {});
> >         for (int i = 0; i < 100000; i++) {
> >             Subscription t = prop.subscribe(() -> {});
> >             s = s.and(t);
> >         }
> >         s.unsubscribe();
> >     }
> > ```
> >
> > This results in
> > ```
> > java.lang.StackOverflowError
> > at
> > javafx.base at 26-ea
> /javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> > at
> > javafx.base at 26-ea
> /javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> > at
> > javafx.base at 26-ea
> /javafx.util.Subscription.lambda$and$0(Subscription.java:103)
> > ...
> > ```
> >
> > While it's unusual (and in most cases a very bad idea) to chain that
> > many Subscriptions, I don't think this should give a StackOverflow
> > Error. I believe it is better to avoid recursion in the
> > implementation. If people agree, I'll file an issue for this.
> >
> > - Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250815/231f5c38/attachment-0001.htm>

From mhanl at openjdk.org  Fri Aug 15 11:44:19 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 15 Aug 2025 11:44:19 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
Message-ID: <GmDQcfhdTsQUE_j3d-mmk5XZr0XfXiquf94wmWBGmKg=.dbfd7fa6-01f5-4fd7-b929-c96dbd91601f@github.com>

On Thu, 14 Aug 2025 07:26:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
>> 
>> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
>> 
>> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
>> 
>> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pick default pipeline from PrismSettings

modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java line 209:

> 207:         // macDefaultPipeline flag will be used to determine whether to
> 208:         // use es2/mtl pipeline in glass, when sw pipeline is used in prism
> 209:         macDefaultPipeline = macDefaultOrderArr[0];

Since this is a platform independent file, should we name this property in a generic way (even if it is only used for MacOS)?
Something like `defaultPipeline?`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2278848018

From mhanl at openjdk.org  Fri Aug 15 11:51:20 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 15 Aug 2025 11:51:20 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
 [v2]
In-Reply-To: <Po6bwb1qC8ns2ghRckD0PUZAiSJprb1hBMHwwcCS7eE=.0252b8b6-5c8a-4faa-a713-da346a9efd32@github.com>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
 <Po6bwb1qC8ns2ghRckD0PUZAiSJprb1hBMHwwcCS7eE=.0252b8b6-5c8a-4faa-a713-da346a9efd32@github.com>
Message-ID: <8Vbfpx0CN1HTq1YnmCSYFuqfLs24zJjI3vI8o8XkYz8=.3b33a86d-372f-4953-a8ee-ebfd8eaa6a33@github.com>

On Sun, 27 Jul 2025 18:46:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Currently, the color scheme of a system-decorated stage is as follows:
>> * On Windows, the title bar is always light (even if the OS color scheme is dark).
>> * On macOS and Linux, the title bar is light or dark depending on the OS color scheme.
>> 
>> The expected behavior is that the title bar matches the color scheme of the `Scene`.
>> If an application doesn't specify a color scheme, the title bar color should match the OS color scheme.
>> 
>> This PR fixes the behavior for Windows and macOS, but not for Linux (there's no good way to do that).
>> Depending on how you look at it, this is either a bug fix or an enhancement.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into feature/dark-window-frame
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m
>  - Window decorations adapt to color scheme

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1267:

> 1265:     // value 0 to indicate that we don't support this feature.
> 1266:     // See: https://github.com/MicrosoftDocs/sdk-api/commit/c19f1c8a148b930444dce998d3c717c8fb7751e1
> 1267:     static const DWORD DWMWA_USE_IMMERSIVE_DARK_MODE = []() {

This implementation looks correct. For comparison, I checked out the implementation in `Godot`.

Version check: https://github.com/godotengine/godot/blob/master/platform/windows/display_server_windows.cpp#L6853 
Set the attribute: https://github.com/godotengine/godot/blob/master/platform/windows/display_server_windows.cpp#L4708

Note that the `build` numbers differ a little bit from here. But checking your linked commit, your numbers seem to be the right one! Will do some testing later (on Windows 11).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1845#discussion_r2278857413

From john.hendrikx at gmail.com  Fri Aug 15 13:10:38 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 15 Aug 2025 15:10:38 +0200
Subject: StackOverflowError in recursive Subscription.unsubscribe
In-Reply-To: <CABxFH2Fajhv5a=wdXeTQmr69s4PPL25xBtB+ynWu3NKw3MWpcA@mail.gmail.com>
References: <CABxFH2G1eXvg+P19ne094LfHWzN6cknTP+-6GDnziSJnWy4e8w@mail.gmail.com>
 <cb29a0fd-8e4a-4009-b2c3-9944ab76f57c@gmail.com>
 <CABxFH2Fajhv5a=wdXeTQmr69s4PPL25xBtB+ynWu3NKw3MWpcA@mail.gmail.com>
Message-ID: <0539537b-e381-46e4-8068-c8f4c519947a@gmail.com>


On 15/08/2025 12:39, Johan Vos wrote:
> Adding to this, I investigated what was exactly happening in my case.
> There was a Subscription with a few thousands recursive subscriptions,
> which were created by `and`.
> However, only a few of those subscriptions were still "active".
> When calling Subscription.unsubscribe() in case of a combined
> subscription, the listeners will be removed, but the inner
> Subscription objects are not removed, so the combined subscription
> keeps having multiple inner subscriptions.
> This is a different, but related issue. The following pattern is thus
> wrong and dangerous:
> ```
> Subscription s = Subscription.EMPTY;?
> for (int i = 0; i < 100; i++) {?
> ? ? s.unsubscribe();
> ? ? s = s.and(fooProperty.subscribe(val -> ...));
> ? ? s = s.and(barProperty.subscribe(val -> ...));
> ?}
> ```

Yeah, this pattern is not correct use, you need to reset `s` back to
Subscription.EMPTY or just overwrite it.? I have been working with
Subscriptions for a while, and I was thinking it might be really great
if `s.unsubscribe()` returned the empty Subscription, because then you
can write it as:

???? s = s.unsubscribe();

Or even:

???? s = s.unsubscribe().and(fooProperty.subscribe( ... );

I was hesitant to suggest it, but if others feel the same way, we could
consider it. Now that I've used subscriptions a bit more in projects, I
find that returning Subscription.EMPTY could be a huge help.

>
> The `s.unsubscribe` keeps strong references to all previously added
> subscriptions. It has to recursively loop over a growing list of
> Subscription.unsubscribe() calls.
> Adding `s = Subscription.EMPTY` after `s.unsubscribe()` fixes that
> problem.

Indeed :)

I was already wondering how you got into the stack overflow situation,
as you'd need quite a lot of subscriptions.? I sometimes however
subscribe entire models (consisting of 50+ properties), but even then it
would be hard to get a stack overflow, so I was imagining some huge
model or list of properties where each individual property needed a
chained subscription.

Perhaps the doc could mention that `and` chaining is (even after the
fix)?intended for low numbers, while `combine` is more suitable for high
numbers of subscriptions.

>
> So I believe there are 2 different issues:
> 1. as reported in the original post, the recursive approach in
> unsubscribe can lead to StackOverflowErrors in case of many chained
> subscriptions
> 2. it is not clear from the documentation that
> Subscription.unsubscribe() is not removing the subscriptions (it just
> unsubscribes, but keeps the whole structure on the heap).

We can clarify this better, or perhaps it already becomes much more
clear if it returned the empty subscription.? The disconnect here is I
think that people may reason that a Subscription is something that can
be altered and re-used, but in reality it is immutable, and so
`unsubscribe` can't and won't modify it. It doesn't even know the status
of the subscription (still active, or was it unsubscribed already).

The simplicity adds to its power, as you can basically make anything
into a Subscription (it's basically a Runnable), so you can do:

? ??Subscription s = fooProperty.subscribe( ... )
??????? .and(() -> log.info("unsubscribe was called")) // log something
??????? .and(() -> file.close())? // close resources (but be careful of
exceptions, and it must be idempotent)
??????? .and(() -> control.removeEventHandler( ... ));? // remove an
event handler, even though it doesn't support subscriptions

Or with combine:

???? Subscription s = Subscription.combine(
?????????? fooProperty.subscribe(...),
?????????? () -> log.info(),
?????????? () -> file.close(),
?????????? () -> control.removeEventHandler( ... )
???? );
????????
And then unsubscribe basically runs all your clean-up code in one go.

--John

>
> - Johan
>
>
> On Wed, Aug 13, 2025 at 10:12?PM John Hendrikx
> <john.hendrikx at gmail.com> wrote:
>
>     You're right, this should preferably not happen.? The
>     implementation is
>     simple, but it does limit how many subscriptions you can chain.
>
>     The `combine` variant does not have the same issue.
>
>     I can rewrite it to avoid recursion, but it needs to be done very
>     carefully as the subscriptions chained with `and` basically form a
>     graph, and unsubscribing an older reference should not unsubscribe
>     more
>     than it would have done before calling `and`.
>
>     --John
>
>     On 13/08/2025 12:06, Johan Vos wrote:
>     > Hi,
>     >
>     > The current implementation of Subscription.unsubscribe() uses
>     > recursion?to unsubscribe the chain of subscriptions. This can
>     lead to
>     > a StackOverflowError in case there are many chained subscriptions.
>     > Running the following code demonstrates this:
>     >
>     > ```
>     > ? ? void testSubs() {
>     > ? ? ? ? SimpleStringProperty prop = new
>     SimpleStringProperty("simpel");
>     > ? ? ? ? Subscription s = prop.subscribe(() -> {});
>     > ? ? ? ? for (int i = 0; i < 100000; i++) {
>     > ? ? ? ? ? ? Subscription t = prop.subscribe(() -> {});
>     > ? ? ? ? ? ? s = s.and(t);
>     > ? ? ? ? }
>     > ? ? ? ? s.unsubscribe();
>     > ? ? }
>     > ```
>     >
>     > This results in
>     > ```
>     > java.lang.StackOverflowError
>     > at
>     >
>     javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>     > at
>     >
>     javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>     > at
>     >
>     javafx.base at 26-ea/javafx.util.Subscription.lambda$and$0(Subscription.java:103)
>     > ...
>     > ```
>     >
>     > While it's unusual (and in most cases a very bad idea) to chain that
>     > many Subscriptions, I don't think this should give a StackOverflow
>     > Error. I believe it is better to avoid recursion in the
>     > implementation. If people agree, I'll file an issue for this.
>     >
>     > - Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250815/acc7a16e/attachment-0001.htm>

From kcr at openjdk.org  Fri Aug 15 15:22:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Aug 2025 15:22:23 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <GmDQcfhdTsQUE_j3d-mmk5XZr0XfXiquf94wmWBGmKg=.dbfd7fa6-01f5-4fd7-b929-c96dbd91601f@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
 <GmDQcfhdTsQUE_j3d-mmk5XZr0XfXiquf94wmWBGmKg=.dbfd7fa6-01f5-4fd7-b929-c96dbd91601f@github.com>
Message-ID: <Mz6HHgfu0uVfENRWho9uyfCMa9REZiaYsLbK69HQs5A=.2f9f3ed4-73fa-4491-b820-3e25ac6739b7@github.com>

On Fri, 15 Aug 2025 11:41:13 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pick default pipeline from PrismSettings
>
> modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java line 209:
> 
>> 207:         // macDefaultPipeline flag will be used to determine whether to
>> 208:         // use es2/mtl pipeline in glass, when sw pipeline is used in prism
>> 209:         macDefaultPipeline = macDefaultOrderArr[0];
> 
> Since this is a platform independent file, should we name this property in a generic way (even if it is only used for MacOS)?
> Something like `defaultPipeline?`

Since `macDefaultOrderArr` is already mac-specific, I'm not sure how much this helps without also refactoring the rest of the logic.

One possibility would be to move the if-then-else block up (before the check for the `"prism.order"` system property) and then assign the default pipeline after the tryOrder is assigned. I'll leave it up to Jay as whether he wants to do this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2279218113

From kcr at openjdk.org  Fri Aug 15 16:08:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Aug 2025 16:08:23 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
Message-ID: <g4jPv68kt9DDClaS-NpkonLF8ikvhDThncc0-87H2b4=.df863ca7-a7d7-4071-bd43-2e6ec998245a@github.com>

On Thu, 14 Aug 2025 07:26:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
>> 
>> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
>> 
>> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
>> 
>> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pick default pipeline from PrismSettings

Looks good with a few minor comments. I'll reapprove if you make any changes as a result.

@arapte can you be the second reviewer?

modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWPipeline.java line 78:

> 76:             if (PlatformUtil.isMac()) {
> 77:                 HashMap devDetails =
> 78:                     (HashMap)SWPipeline.getInstance().getDeviceDetails();

You're already in an instance method of SWPipeline, so the `SWPipeline.getInstance().` is not needed, and seems odd.

modules/javafx.graphics/src/main/native-glass/mac/GlassLayer.h line 40:

> 38:       withHiDPIAware:(BOOL)HiDPIAware
> 39:         withIsSwPipe:(BOOL)isSwPipe
> 40:        useMTLForBlit:(BOOL)useMTLInGlass;

Minor question on the naming: Since this is only ever set to true when using the SW pipeline, do you think having "Sw" somewhere in the name would be helpful? Given the name, it could be confusing to notice that it is set to false when using the MTL pipeline.

modules/javafx.graphics/src/main/native-glass/mac/GlassLayer.m line 55:

> 53:     {
> 54:         if (mtlCommandQueuePtr != 0l ||
> 55:             useMTLInGlass) { // MTL

Minor: perhaps this would look better with the "if" test all on the same line?

modules/javafx.graphics/src/main/native-glass/mac/GlassViewCGL.m line 178:

> 176:                                       withHiDPIAware:isHiDPIAware
> 177:                                         withIsSwPipe:isSwPipe
> 178:                                        useMTLForBlit:useMTLInGlass];

Minor: indentation isn't consistent.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1868#pullrequestreview-3124193962
PR Comment: https://git.openjdk.org/jfx/pull/1868#issuecomment-3192031026
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2279243883
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2279382183
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2279339570
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2279385548

From kcr at openjdk.org  Fri Aug 15 16:36:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Aug 2025 16:36:18 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
Message-ID: <kmXPxVnl_yUJ642P7kMJfe9JprT5rlyK5RN78OEVwBc=.59d61862-e2f5-4a2a-ab65-c8f88dee0005@github.com>

On Wed, 13 Aug 2025 12:31:32 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
> This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue

Reviewer: @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1869#issuecomment-3192103044

From kcr at openjdk.org  Fri Aug 15 16:51:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Aug 2025 16:51:26 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
Message-ID: <JCLejHKjAwwsHDyVFY4HCN5cwEiZULN_C-9DP_GbuXg=.d0a7d8bd-b298-4074-b9d9-2d7e159f0fa0@github.com>

On Wed, 13 Aug 2025 12:31:32 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
> This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue

`.color-picker-grid` is the only place in `modena.css` that sets snap-to-pixel to false. It was set to false during the initial development of `modena.css` in commit ee4c8a0f95e6148772b0839c95e4348ac8f9e3e0 without any explanation. I also note that the color picker is the only place where a fractional pixel padding is used, so this will need to be tested and carefully inspected visually with different scales to make sure that it looks good after being snapped (with no gaps or visible asymmetry).

If all looks OK, then the change seems reasonable (although @Maran23 is right that it should simply be removed), but I want to know what @andy-goryachev-oracle thinks.

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

PR Comment: https://git.openjdk.org/jfx/pull/1869#issuecomment-3192140922

From kcr at openjdk.org  Fri Aug 15 16:58:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 15 Aug 2025 16:58:18 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max
In-Reply-To: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
References: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
Message-ID: <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>

On Thu, 14 Aug 2025 16:26:07 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
> 
> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.

This looks reasonable although I haven't tested it. I left one question inline. I presume you have run all systems tests?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 161:

> 159:             if (minMaxEnforced) {
> 160:                 notifyResize(WindowEvent.RESIZE, pw, ph);
> 161:             }

Could this lead to two resize commands in some cases? I can see why this new logic is needed for the case where the window was already at max (or min) width and height, but if it wasn't already constrained, wouldn't the resize event have already happened?

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

PR Review: https://git.openjdk.org/jfx/pull/1870#pullrequestreview-3124545046
PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2279485765

From tsayao at openjdk.org  Fri Aug 15 17:23:17 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 15 Aug 2025 17:23:17 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max
In-Reply-To: <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
References: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
 <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
Message-ID: <X4acvu0zIekg3W5ORtF5XEj-5FyxXxZ6E3Wu9LvzNbo=.ed3a43b2-7aaa-4a9d-9b04-130bac3c109b@github.com>

On Fri, 15 Aug 2025 16:53:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
>> 
>> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 161:
> 
>> 159:             if (minMaxEnforced) {
>> 160:                 notifyResize(WindowEvent.RESIZE, pw, ph);
>> 161:             }
> 
> Could this lead to two resize commands in some cases? I can see why this new logic is needed for the case where the window was already at max (or min) width and height, but if it wasn't already constrained, wouldn't the resize event have already happened?

The issue is that the Java side updates the property first, and only afterward requests the Glass native side to apply the change. I've found this to cause many problems and I fixed the same way in  #1789 - when the change can't be applied, it notifies back.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2279535073

From mfox at openjdk.org  Fri Aug 15 20:09:19 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 15 Aug 2025 20:09:19 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max
In-Reply-To: <X4acvu0zIekg3W5ORtF5XEj-5FyxXxZ6E3Wu9LvzNbo=.ed3a43b2-7aaa-4a9d-9b04-130bac3c109b@github.com>
References: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
 <4R9My3krpgl6AVi56e1plvjbrKvm5IoIs9GKbhTXi4w=.cf2ac0f8-5a4f-4acf-856e-7b1fb49f9eeb@github.com>
 <X4acvu0zIekg3W5ORtF5XEj-5FyxXxZ6E3Wu9LvzNbo=.ed3a43b2-7aaa-4a9d-9b04-130bac3c109b@github.com>
Message-ID: <Dne_vAe9K3qFgQGthdTgHeQc1-4xER67kKhaYGTzggU=.3ea7a54b-82e1-494c-a17c-2f3800867512@github.com>

On Fri, 15 Aug 2025 17:21:03 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java line 161:
>> 
>>> 159:             if (minMaxEnforced) {
>>> 160:                 notifyResize(WindowEvent.RESIZE, pw, ph);
>>> 161:             }
>> 
>> Could this lead to two resize commands in some cases? I can see why this new logic is needed for the case where the window was already at max (or min) width and height, but if it wasn't already constrained, wouldn't the resize event have already happened?
>
> The issue is that the Java side updates the property first, and only afterward requests the Glass native side to apply the change. I've found this to cause many problems and I fixed the same way in  #1789 - when the change can't be applied, it notifies back.

> Could this lead to two resize commands in some cases?

Yes, I was trying not to be too clever with my checks. I figured if the second notification wasn't necessary it would be benign. At the very least it won't trigger invalidation of the window's width and height properties.

I will tighten this up since I have to tweak the code a bit anyway. I just verified that on Windows you can alter the size of a maximized window and the OS will keep it in the MAXIMIZED state (as it resizes glass calls notifyResize with WindowEvent.MAXIMIZED). This PR can kick the window out of the MAXIMIZED or MINIMIZED state incorrectly. Unfortunately it puts the window in the wrong internal state without updating the maximized or iconified properties so it's not easy to write a test to detect this.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1870#discussion_r2279798272

From nlisker at gmail.com  Fri Aug 15 23:53:13 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 16 Aug 2025 02:53:13 +0300
Subject: Full press-drag-release done event
Message-ID: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>

Hi all,

I've noticed that the full press-drag-release MouseDragEvent doesn't have
an event type that signals the end of the drag process. In DnD, there is
DragEvent.DRAG_DONE that signals the end of the drag-and-drop process
regardless of the result and the mouse location it was released
at, including outside of the application.

Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications that
want to act when the process finishes regardless of the result. Currently,
the "latest" event that can be delivered is a MOUSE_DRAG_RELEASED type, but
it can only be delivered if the event ends on a node that registered for
it. If the mouse is released outside of the application or on a node that
hasn't registered for it, there will be no notification that the drag chain
ended.

I propose adding this event type and the appropriate property on Scene and
Node. The modification seems rather simple in my prototype.

Thoughts?

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

From mstrauss at openjdk.org  Sat Aug 16 07:09:57 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 16 Aug 2025 07:09:57 GMT
Subject: RFR: 8365632: Remove unused local variable in GlassWindow
Message-ID: <-4KGIekcwJ6l6RbYHQNxQXaaUHK9VlpjXN-XAfIhHF0=.6f4996a8-e40f-4674-8f0e-3a543daee5a9@github.com>

`originalSize` in GlassWindow::HandleNCCalcSizeEvent is not used and can be removed.

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

Commit messages:
 - Remove unused local variable

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

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

From jhendrikx at openjdk.org  Sun Aug 17 15:38:32 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 17 Aug 2025 15:38:32 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
Message-ID: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>

This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):

### Parent::requestLayout

> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.

### Node::managedProperty

> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**

And:

> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**

>From this I conclude that:
- A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
- Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
- Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list

Note that Scene currently does not have a dirty layout list.

Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

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

Commit messages:
 - Add unmanaged nodes in need of layout to a dirty layout root list

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

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

From jhendrikx at openjdk.org  Sun Aug 17 15:38:32 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 17 Aug 2025 15:38:32 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
Message-ID: <q1L1JhrPcg5j8dvcZvGWD71dXq1EGy5_ovT9LDuchaY=.c5effefd-2fa9-4f5a-9ddf-6adad4424beb@github.com>

On Sun, 17 Aug 2025 15:32:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
> 
> ### Parent::requestLayout
> 
>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
> 
> ### Node::managedProperty
> 
>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
> 
> And:
> 
>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
> 
> From this I conclude that:
> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
> 
> Note that Scene currently does not have a dirty layout list.
> 
> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

There is a tiny change in the documentation, but it doesn't change the meaning (a scene root is a layout root, and unmanaged nodes are layout roots; there are no other types of layout roots).  Can do a CSR though if deemed needed.

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3194461635

From john.hendrikx at gmail.com  Sun Aug 17 15:43:56 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 17 Aug 2025 17:43:56 +0200
Subject: Full press-drag-release done event
In-Reply-To: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
References: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
Message-ID: <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>

Seems harmless enough. What is your use case?

On 16/08/2025 01:53, Nir Lisker wrote:
> Hi all,
>
> I've noticed that the full press-drag-release MouseDragEvent doesn't
> have an event type that signals the end of the drag process. In DnD,
> there is DragEvent.DRAG_DONE that signals the end of the drag-and-drop
> process regardless of the result and the mouse location it was
> released at,?including outside of the application.
>
> Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications
> that want to act when the process finishes regardless?of the result.
> Currently, the "latest" event that can be delivered?is a
> MOUSE_DRAG_RELEASED type, but it can only be delivered if the event
> ends on a node that registered?for it. If the mouse is released
> outside of the application or on a node that hasn't registered for it,
> there will be no notification that the drag chain ended.
>
> I propose adding this event type and the appropriate property on Scene
> and Node. The modification seems rather simple in my prototype.
>
> Thoughts?
>
> -- Nir

From nlisker at gmail.com  Mon Aug 18 07:13:39 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 18 Aug 2025 10:13:39 +0300
Subject: Full press-drag-release done event
In-Reply-To: <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>
References: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
 <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>
Message-ID: <CA+0ynh8F1nj0OAeE9nou1AdVf8P54QhviZ=YZLke=Zmsm0EzKQ@mail.gmail.com>

(Replying to the mailing list this time :) )

I have nodes that need to be dragged onto other nodes (in the same
application) and are highlighted for the full drag-press-release
duration, with an additional state change about the "selected" node. If
they are dropped on a target that can accept them, the cleanup can be done
when the drop is done, but if they are dropped outside of the application
or on a node that can't accept them, the process never finishes. There are
workarounds, but DnD shows that it can be much easier to do with the
additional event.

On Sun, Aug 17, 2025 at 8:56?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Seems harmless enough. What is your use case?
>
> On 16/08/2025 01:53, Nir Lisker wrote:
> > Hi all,
> >
> > I've noticed that the full press-drag-release MouseDragEvent doesn't
> > have an event type that signals the end of the drag process. In DnD,
> > there is DragEvent.DRAG_DONE that signals the end of the drag-and-drop
> > process regardless of the result and the mouse location it was
> > released at, including outside of the application.
> >
> > Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications
> > that want to act when the process finishes regardless of the result.
> > Currently, the "latest" event that can be delivered is a
> > MOUSE_DRAG_RELEASED type, but it can only be delivered if the event
> > ends on a node that registered for it. If the mouse is released
> > outside of the application or on a node that hasn't registered for it,
> > there will be no notification that the drag chain ended.
> >
> > I propose adding this event type and the appropriate property on Scene
> > and Node. The modification seems rather simple in my prototype.
> >
> > Thoughts?
> >
> > -- Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/6f79d848/attachment.htm>

From jdv at openjdk.org  Mon Aug 18 07:30:14 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 07:30:14 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <g4jPv68kt9DDClaS-NpkonLF8ikvhDThncc0-87H2b4=.df863ca7-a7d7-4071-bd43-2e6ec998245a@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
 <g4jPv68kt9DDClaS-NpkonLF8ikvhDThncc0-87H2b4=.df863ca7-a7d7-4071-bd43-2e6ec998245a@github.com>
Message-ID: <OENSz50UV51tTvNqU8QRoVNCxE-GfbOr_FZE_oCV8_A=.19e1a1d8-a5a5-4b5d-8477-6960d1553e6e@github.com>

On Fri, 15 Aug 2025 15:24:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pick default pipeline from PrismSettings
>
> modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWPipeline.java line 78:
> 
>> 76:             if (PlatformUtil.isMac()) {
>> 77:                 HashMap devDetails =
>> 78:                     (HashMap)SWPipeline.getInstance().getDeviceDetails();
> 
> You're already in an instance method of SWPipeline, so the `SWPipeline.getInstance().` is not needed, and seems odd.

Thanks, updated.

> modules/javafx.graphics/src/main/native-glass/mac/GlassLayer.h line 40:
> 
>> 38:       withHiDPIAware:(BOOL)HiDPIAware
>> 39:         withIsSwPipe:(BOOL)isSwPipe
>> 40:        useMTLForBlit:(BOOL)useMTLInGlass;
> 
> Minor question on the naming: Since this is only ever set to true when using the SW pipeline, do you think having "Sw" somewhere in the name would be helpful? Given the name, it could be confusing to notice that it is set to false when using the MTL pipeline.

I also had doubts about how to include "SW" in the name. Because it would be very long name.

I have removed the references to "Glass" in the name when we are already in glass code and updated these flags to use "SW" in the name.

> modules/javafx.graphics/src/main/native-glass/mac/GlassLayer.m line 55:
> 
>> 53:     {
>> 54:         if (mtlCommandQueuePtr != 0l ||
>> 55:             useMTLInGlass) { // MTL
> 
> Minor: perhaps this would look better with the "if" test all on the same line?

Sure updated.

> modules/javafx.graphics/src/main/native-glass/mac/GlassViewCGL.m line 178:
> 
>> 176:                                       withHiDPIAware:isHiDPIAware
>> 177:                                         withIsSwPipe:isSwPipe
>> 178:                                        useMTLForBlit:useMTLInGlass];
> 
> Minor: indentation isn't consistent.

We are following https://google.github.io/styleguide/objcguide.html#method-invocations & https://google.github.io/styleguide/objcguide.html#method-declarations-and-definitions. So i have also updated the code where it is inconsistent and we are touching in this PR.

Please correct me if i am wrong.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281515412
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281519271
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281515800
PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281522820

From jdv at openjdk.org  Mon Aug 18 07:30:10 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 07:30:10 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v3]
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <H897NCHQIjf2gUnr2ZHuebq4B9Vm7xLYbEdN3fB4IMQ=.4f8cfeec-d228-4fae-903c-57f99457445f@github.com>

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1868/files
  - new: https://git.openjdk.org/jfx/pull/1868/files/859d4266..db315d15

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

  Stats: 30 lines in 8 files changed: 2 ins; 2 del; 26 mod
  Patch: https://git.openjdk.org/jfx/pull/1868.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1868/head:pull/1868

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

From jdv at openjdk.org  Mon Aug 18 07:30:11 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 07:30:11 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <Mz6HHgfu0uVfENRWho9uyfCMa9REZiaYsLbK69HQs5A=.2f9f3ed4-73fa-4491-b820-3e25ac6739b7@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
 <GmDQcfhdTsQUE_j3d-mmk5XZr0XfXiquf94wmWBGmKg=.dbfd7fa6-01f5-4fd7-b929-c96dbd91601f@github.com>
 <Mz6HHgfu0uVfENRWho9uyfCMa9REZiaYsLbK69HQs5A=.2f9f3ed4-73fa-4491-b820-3e25ac6739b7@github.com>
Message-ID: <d76S5dJ7q_kU8VCHWkJUPBbqOOTroIyKspjWDwSvuD8=.34856cd7-da3d-45de-8078-a2ff20612cc6@github.com>

On Fri, 15 Aug 2025 15:19:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java line 209:
>> 
>>> 207:         // macDefaultPipeline flag will be used to determine whether to
>>> 208:         // use es2/mtl pipeline in glass, when sw pipeline is used in prism
>>> 209:         macDefaultPipeline = macDefaultOrderArr[0];
>> 
>> Since this is a platform independent file, should we name this property in a generic way (even if it is only used for MacOS)?
>> Something like `defaultPipeline?`
>
> Since `macDefaultOrderArr` is already mac-specific, I'm not sure how much this helps without also refactoring the rest of the logic.
> 
> One possibility would be to move the if-then-else block up (before the check for the `"prism.order"` system property) and then assign the default pipeline after the tryOrder is assigned. I'll leave it up to Jay as whether he wants to do this.

if-then-else block requires "order" value to determine whether use is explicitly setting any value.

In case where user is explicitly setting `-Dprism.order=sw`, tryOrderArr will have only "sw" value. So we need macOS prism default order values outside of the if-then-else block.

Since we need this mac specific default order values, i think its okay to keep this mac specific flag.
I would like to keep the code as it is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281512492

From jdv at openjdk.org  Mon Aug 18 08:47:59 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 08:47:59 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v4]
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <lynHxMa4NFKlnw4bgv4k3-1PvVjJBjKXjie7nZfL3hg=.dfa402ba-72ac-4eee-a489-62495eb1d130@github.com>

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Remove mac specific variable from PrismSettings

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1868/files
  - new: https://git.openjdk.org/jfx/pull/1868/files/db315d15..fa8c74fe

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

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

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

From jdv at openjdk.org  Mon Aug 18 08:47:59 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 08:47:59 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <d76S5dJ7q_kU8VCHWkJUPBbqOOTroIyKspjWDwSvuD8=.34856cd7-da3d-45de-8078-a2ff20612cc6@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
 <GmDQcfhdTsQUE_j3d-mmk5XZr0XfXiquf94wmWBGmKg=.dbfd7fa6-01f5-4fd7-b929-c96dbd91601f@github.com>
 <Mz6HHgfu0uVfENRWho9uyfCMa9REZiaYsLbK69HQs5A=.2f9f3ed4-73fa-4491-b820-3e25ac6739b7@github.com>
 <d76S5dJ7q_kU8VCHWkJUPBbqOOTroIyKspjWDwSvuD8=.34856cd7-da3d-45de-8078-a2ff20612cc6@github.com>
Message-ID: <AO2RDIfh-nYGo6qL0OM2cA6BMag6YwFbP2o6vNtgJY4=.0a6f26e2-431a-4ccf-a0a1-977fee3cf9dd@github.com>

On Mon, 18 Aug 2025 07:21:09 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Since `macDefaultOrderArr` is already mac-specific, I'm not sure how much this helps without also refactoring the rest of the logic.
>> 
>> One possibility would be to move the if-then-else block up (before the check for the `"prism.order"` system property) and then assign the default pipeline after the tryOrder is assigned. I'll leave it up to Jay as whether he wants to do this.
>
> if-then-else block requires "order" value to determine whether user is explicitly setting any value.
> 
> In case where user is explicitly setting `-Dprism.order=sw`, tryOrderArr will have only "sw" value. So we need macOS prism default order values outside of the if-then-else block.
> 
> Since we need this mac specific default order values, i think its okay to keep this mac specific flag.
> I would like to keep the code as it is.

Looks like we are talking about `if-then-else-if` block. That will work and it will help us to remove mac specific reference also. Will go ahead and make that change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2281708417

From john.hendrikx at gmail.com  Mon Aug 18 09:36:23 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 18 Aug 2025 11:36:23 +0200
Subject: Full press-drag-release done event
In-Reply-To: <CA+0ynh8F1nj0OAeE9nou1AdVf8P54QhviZ=YZLke=Zmsm0EzKQ@mail.gmail.com>
References: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
 <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>
 <CA+0ynh8F1nj0OAeE9nou1AdVf8P54QhviZ=YZLke=Zmsm0EzKQ@mail.gmail.com>
Message-ID: <1c4610db-602c-4894-9494-ba4270cef223@gmail.com>

Yeah, that sounds reasonable, showing the source of the drag is quite
useful I would think, and you can only do that if you can unhighlight it
at the right time.

--John

On 18/08/2025 09:13, Nir Lisker wrote:
> (Replying to the mailing list this time :) )
>
> I have nodes that need to be dragged onto other nodes (in the same
> application) and are highlighted for the full drag-press-release
> duration,?with an additional state change about the "selected" node.
> If they are dropped on a target that can accept them, the cleanup can
> be done when the drop is done, but if they are dropped outside of the
> application or on a node that can't accept them, the process never
> finishes. There are workarounds, but DnD shows that it can be much
> easier to do with the additional event.
>
> On Sun, Aug 17, 2025 at 8:56?PM John Hendrikx
> <john.hendrikx at gmail.com> wrote:
>
>     Seems harmless enough. What is your use case?
>
>     On 16/08/2025 01:53, Nir Lisker wrote:
>     > Hi all,
>     >
>     > I've noticed that the full press-drag-release MouseDragEvent doesn't
>     > have an event type that signals the end of the drag process. In DnD,
>     > there is DragEvent.DRAG_DONE that signals the end of the
>     drag-and-drop
>     > process regardless of the result and the mouse location it was
>     > released at,?including outside of the application.
>     >
>     > Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications
>     > that want to act when the process finishes regardless?of the result.
>     > Currently, the "latest" event that can be delivered?is a
>     > MOUSE_DRAG_RELEASED type, but it can only be delivered if the event
>     > ends on a node that registered?for it. If the mouse is released
>     > outside of the application or on a node that hasn't registered
>     for it,
>     > there will be no notification that the drag chain ended.
>     >
>     > I propose adding this event type and the appropriate property on
>     Scene
>     > and Node. The modification seems rather simple in my prototype.
>     >
>     > Thoughts?
>     >
>     > -- Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/a8c5e5e3/attachment-0001.htm>

From jdv at openjdk.org  Mon Aug 18 09:51:31 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 09:51:31 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v5]
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <1W4KbUtDxApanhhk_syFwr0bXPj_T-j-v7qWIMgcfNg=.5050d5f9-0ece-4a89-b477-d8c1be00d5c1@github.com>

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1868/files
  - new: https://git.openjdk.org/jfx/pull/1868/files/fa8c74fe..e26ac7d8

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

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1868.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1868/head:pull/1868

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

From arapte at openjdk.org  Mon Aug 18 11:14:20 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 18 Aug 2025 11:14:20 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v5]
In-Reply-To: <1W4KbUtDxApanhhk_syFwr0bXPj_T-j-v7qWIMgcfNg=.5050d5f9-0ece-4a89-b477-d8c1be00d5c1@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <1W4KbUtDxApanhhk_syFwr0bXPj_T-j-v7qWIMgcfNg=.5050d5f9-0ece-4a89-b477-d8c1be00d5c1@github.com>
Message-ID: <JEJjz10kwSJFA3Nr4yTJHZDuEiHoS5HYfDGcy2BddSs=.c5d023f7-e70e-45a2-a463-da8e972e37d8@github.com>

On Mon, 18 Aug 2025 09:51:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
>> 
>> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
>> 
>> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
>> 
>> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

LGTM, Tested with mtl and es2 as default pipeline. Observed no issue in rendering.
suggested a minor change, shall re-approve once changed.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1868#pullrequestreview-3127938722

From jdv at openjdk.org  Mon Aug 18 12:11:36 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 18 Aug 2025 12:11:36 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v6]
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <53KwjkPGATSV9vZn1NWhXbIla_SKIrPH3NjB5sg9nLs=.1fe77c53-d0c3-4df9-8c53-8509351da5a8@github.com>

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  make if one line

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1868/files
  - new: https://git.openjdk.org/jfx/pull/1868/files/e26ac7d8..0307c251

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

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

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

From kevin.rushforth at oracle.com  Mon Aug 18 12:32:14 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 18 Aug 2025 05:32:14 -0700
Subject: Full press-drag-release done event
In-Reply-To: <1c4610db-602c-4894-9494-ba4270cef223@gmail.com>
References: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
 <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>
 <CA+0ynh8F1nj0OAeE9nou1AdVf8P54QhviZ=YZLke=Zmsm0EzKQ@mail.gmail.com>
 <1c4610db-602c-4894-9494-ba4270cef223@gmail.com>
Message-ID: <a1923dd4-2405-4e46-97b6-19749e911193@oracle.com>

Seems reasonable to me, too.

-- Kevin

On 8/18/2025 2:36 AM, John Hendrikx wrote:
>
> Yeah, that sounds reasonable, showing the source of the drag is quite 
> useful I would think, and you can only do that if you can unhighlight 
> it at the right time.
>
> --John
>
> On 18/08/2025 09:13, Nir Lisker wrote:
>> (Replying to the mailing list this time :) )
>>
>> I have nodes that need to be dragged onto other nodes (in the same 
>> application) and are highlighted for the full drag-press-release 
>> duration,?with an additional state change about the "selected" node. 
>> If they are dropped on a target that can accept them, the cleanup can 
>> be done when the drop is done, but if they are dropped outside of the 
>> application or on a node that can't accept them, the process never 
>> finishes. There are workarounds, but DnD shows that it can be much 
>> easier to do with the additional event.
>>
>> On Sun, Aug 17, 2025 at 8:56?PM John Hendrikx 
>> <john.hendrikx at gmail.com> wrote:
>>
>>     Seems harmless enough. What is your use case?
>>
>>     On 16/08/2025 01:53, Nir Lisker wrote:
>>     > Hi all,
>>     >
>>     > I've noticed that the full press-drag-release MouseDragEvent
>>     doesn't
>>     > have an event type that signals the end of the drag process. In
>>     DnD,
>>     > there is DragEvent.DRAG_DONE that signals the end of the
>>     drag-and-drop
>>     > process regardless of the result and the mouse location it was
>>     > released at,?including outside of the application.
>>     >
>>     > Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications
>>     > that want to act when the process finishes regardless?of the
>>     result.
>>     > Currently, the "latest" event that can be delivered?is a
>>     > MOUSE_DRAG_RELEASED type, but it can only be delivered if the event
>>     > ends on a node that registered?for it. If the mouse is released
>>     > outside of the application or on a node that hasn't registered
>>     for it,
>>     > there will be no notification that the drag chain ended.
>>     >
>>     > I propose adding this event type and the appropriate property
>>     on Scene
>>     > and Node. The modification seems rather simple in my prototype.
>>     >
>>     > Thoughts?
>>     >
>>     > -- Nir
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/1ce586fd/attachment-0001.htm>

From dlemmermann at gmail.com  Mon Aug 18 13:00:57 2025
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Mon, 18 Aug 2025 15:00:57 +0200
Subject: TabPane / wrapped text
Message-ID: <C5B83732-C8DB-47CD-BC88-D560D62AE46B@gmail.com>

Hi,

I noticed a difference in the way TabPane behaves when trying version 24.0.2 vs 25-ea+28. It seems that TabPaneSkin.computePrefHeight(?) is no longer working as expected. This might be related to recent changes in the area of content bias and wrapped content. 

When you run the following test app you will notice that the window / the tab pane comes up with different heights depending on the version. In 25-ea+28 the window is not high enough and text gets cut off.

(The bug also exists in the 26 EA releases).

Regards,

Dirk

package com.dlsc.gemsfx.demo;

import javafx.geometry.Insets;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.control.Tab;
import javafx.scene.control.TabPane;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
 * This is a test case to validate whether a TabPane respects the preferred
 * height of its content.
 * @author Dirk Lemmermann
 */
public class TabPaneBug extends GemApplication {

    @Override
    public void start(Stage stage) { super.start(stage);
        Label label = new Label("Lorem ipsum dolor sit amet consectetur adipiscing elit nunc hendrerit purus, nisi dapibus primis nibh volutpat fringilla ad nisl urna pos-uere!\nCubilia sagittis egestas pharetra sociis montes nullam netus erat.\n\nFusce mauris condimentum neque morbi nunc ligula pretium vehicula nulla, platea dictum mus sapien pulvinar eget porta mi praesent, orci hac dignissim suscipit imperdiet sem per a.\nMauris pellentesque dui vitae velit netus venenatis diam felis urna ultrices, potenti pretium sociosqu eros dictumst dis aenean nibh cursus, leo sagittis integer nullam malesuada aliquet et metus vulputate. Interdum facilisis congue ac proin libero mus ullamcorper mauris leo imperdiet eleifend porta, posuere dignissim erat tincidunt vehicula habitant taciti porttitor scelerisque laoreet neque. Habitant etiam cubilia tempor inceptos ad aptent est et varius, vitae imperdiet phasellus feugiat class purus curabitur ullamcorper maecenas, venenatis mollis fusce cras leo eros metus proin. Fusce aenean sociosqu dis habitant mi sapien inceptos, orci lacinia nisi nascetur convallis at erat sociis, purus integer arcu feugiat sollicitudin libero.\n\nLorem ipsum dolor sit amet consectetur adipiscing elit nunc hendrerit purus, nisi dapibus primis nibh volutpat fringilla ad nisl urna posuere. Lorem ipsum dolor sit amet consectetur adipiscing elit nunc hendrerit purus, nisi dapibus primis nibh volutpat fringilla ad nisl urna posuere. Lorem ipsum dolor sit amet consectetur adipiscing elit nunc hendrerit purus, nisi dapibus primis nibh volutpat fringilla ad nisl urna posuere. A");
        label.setWrapText(true);
        label.setMaxWidth(500);

        Tab tab1 = new Tab("Tab 1", label);
        TabPane tabPane = new TabPane(tab1);

        StackPane stackPane = new StackPane(tabPane);
        stackPane.setPadding(new Insets(20));

        stage.setScene(new Scene(stackPane));
        stage.sizeToScene();
        stage.centerOnScreen();
        stage.setTitle("Tab Pane Bug");
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/c98fd8c8/attachment.htm>

From jhendrikx at openjdk.org  Mon Aug 18 14:04:41 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 14:04:41 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images loaded
 from an InputStream
Message-ID: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>

Support background loading of raw input streams

- Fixed generics (mix up of two ImageLoader types)
- Removed unused code for handling headers, methods, request parameters
- Use `long` for progress as streams may exceed 2 GB
- Improved documentation of Image regarding background loading

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

Commit messages:
 - Support background loading of raw input streams

Changes: https://git.openjdk.org/jfx/pull/1875/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1875&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361286
  Stats: 304 lines in 11 files changed: 180 ins; 72 del; 52 mod
  Patch: https://git.openjdk.org/jfx/pull/1875.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1875/head:pull/1875

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

From andy.goryachev at oracle.com  Mon Aug 18 14:18:56 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 18 Aug 2025 14:18:56 +0000
Subject: Full press-drag-release done event
In-Reply-To: <1c4610db-602c-4894-9494-ba4270cef223@gmail.com>
References: <CA+0ynh864fU=V8+X-SuYZMa6jc5BzJtz3OGakDNL_kjjke_aEg@mail.gmail.com>
 <c5d724f1-40fe-4ae8-9abf-82152beffe69@gmail.com>
 <CA+0ynh8F1nj0OAeE9nou1AdVf8P54QhviZ=YZLke=Zmsm0EzKQ@mail.gmail.com>
 <1c4610db-602c-4894-9494-ba4270cef223@gmail.com>
Message-ID: <CY8PR10MB7265402F67597F5A05647AFBE531A@CY8PR10MB7265.namprd10.prod.outlook.com>

I think there was/is more: when the drop happens outside of any accepting node, the drag image scuttles back to the original place, with no way to disable that behavior.

This made the DnD unsuitable for me in the context of a docking framework, where the user expects a new window to be created with the dragged content.

Also, it is impossible to control the scaling of the drag image, for instance, to disable the scaling altogether.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Monday, August 18, 2025 at 02:37
To: Nir Lisker <nlisker at gmail.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Full press-drag-release done event


Yeah, that sounds reasonable, showing the source of the drag is quite useful I would think, and you can only do that if you can unhighlight it at the right time.

--John

On 18/08/2025 09:13, Nir Lisker wrote:
(Replying to the mailing list this time :) )

I have nodes that need to be dragged onto other nodes (in the same application) and are highlighted for the full drag-press-release duration, with an additional state change about the "selected" node. If they are dropped on a target that can accept them, the cleanup can be done when the drop is done, but if they are dropped outside of the application or on a node that can't accept them, the process never finishes. There are workarounds, but DnD shows that it can be much easier to do with the additional event.

On Sun, Aug 17, 2025 at 8:56?PM John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>> wrote:
Seems harmless enough. What is your use case?

On 16/08/2025 01:53, Nir Lisker wrote:
> Hi all,
>
> I've noticed that the full press-drag-release MouseDragEvent doesn't
> have an event type that signals the end of the drag process. In DnD,
> there is DragEvent.DRAG_DONE that signals the end of the drag-and-drop
> process regardless of the result and the mouse location it was
> released at, including outside of the application.
>
> Adding a MouseDragEvent.MOUSE_DRAG_DONE is useful for applications
> that want to act when the process finishes regardless of the result.
> Currently, the "latest" event that can be delivered is a
> MOUSE_DRAG_RELEASED type, but it can only be delivered if the event
> ends on a node that registered for it. If the mouse is released
> outside of the application or on a node that hasn't registered for it,
> there will be no notification that the drag chain ended.
>
> I propose adding this event type and the appropriate property on Scene
> and Node. The modification seems rather simple in my prototype.
>
> Thoughts?
>
> -- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/a864b3a2/attachment-0001.htm>

From angorya at openjdk.org  Mon Aug 18 14:51:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 14:51:22 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <q1L1JhrPcg5j8dvcZvGWD71dXq1EGy5_ovT9LDuchaY=.c5effefd-2fa9-4f5a-9ddf-6adad4424beb@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
 <q1L1JhrPcg5j8dvcZvGWD71dXq1EGy5_ovT9LDuchaY=.c5effefd-2fa9-4f5a-9ddf-6adad4424beb@github.com>
Message-ID: <2AkfbLCI-uRP59W5qalxxty4kWn_--8AG97sMAk0Qs8=.170b6491-0408-459d-9eaa-b640197a667e@github.com>

On Sun, 17 Aug 2025 15:36:06 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
>> 
>> ### Parent::requestLayout
>> 
>>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
>> 
>> ### Node::managedProperty
>> 
>>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
>> 
>> And:
>> 
>>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
>> 
>> From this I conclude that:
>> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
>> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
>> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
>> 
>> Note that Scene currently does not have a dirty layout list.
>> 
>> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."
>
> There is a tiny change in the documentation, but it doesn't change the meaning (a scene root is a layout root, and unmanaged nodes are layout roots; there are no other types of layout roots).  Can do a CSR though if deemed needed.

@hjohn would it be possible to add a unit test?

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3197245454

From angorya at openjdk.org  Mon Aug 18 14:51:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 14:51:23 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
Message-ID: <stAG7e0ZryGTlP4W0meYdqOPM7H1Kj5HFT5cvxoq-b4=.06504a30-f8d4-4aa3-9b9f-611c08c6cac3@github.com>

On Sun, 17 Aug 2025 15:32:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
> 
> ### Parent::requestLayout
> 
>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
> 
> ### Node::managedProperty
> 
>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
> 
> And:
> 
>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
> 
> From this I conclude that:
> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
> 
> Note that Scene currently does not have a dirty layout list.
> 
> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

There is a single word change in the javadoc.  Do we need a CSR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3197249976

From nlisker at openjdk.org  Mon Aug 18 16:20:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 16:20:06 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
Message-ID: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>

Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

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

Commit messages:
 - Initial commit

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

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

From nlisker at openjdk.org  Mon Aug 18 16:20:08 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 16:20:08 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
Message-ID: <vvtpHqGi16JAx_l2Jg6K1Itg_DcUA65SVvHzLs2vkt8=.e3ecdbce-b648-4000-9e07-fd4b0e3a076c@github.com>

On Sat, 16 Aug 2025 20:44:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

I noticed that the `@see` documentation tag doesn't work on properties. I'm not sure if it's a bug in javadoc.

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3197571573

From nlisker at openjdk.org  Mon Aug 18 16:40:22 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 16:40:22 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <stAG7e0ZryGTlP4W0meYdqOPM7H1Kj5HFT5cvxoq-b4=.06504a30-f8d4-4aa3-9b9f-611c08c6cac3@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
 <stAG7e0ZryGTlP4W0meYdqOPM7H1Kj5HFT5cvxoq-b4=.06504a30-f8d4-4aa3-9b9f-611c08c6cac3@github.com>
Message-ID: <z-S9wa7by1zow1GqogE3p82Y32ynRPuZRlyQ0LWjpA4=.00a908a8-2f1c-4288-bede-0781ee9cc572@github.com>

On Mon, 18 Aug 2025 14:48:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> There is a single word change in the javadoc. Do we need a CSR?

No. Even for larger doc fixes I never needed one.

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3197650276

From nlisker at openjdk.org  Mon Aug 18 17:04:25 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 17:04:25 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
Message-ID: <V1yhAPhPU0aujbGDdrQEi1T43M1IAdigs7zE3EOKCu8=.1d6fcfe7-dc28-4830-9b9a-e6925b597ae6@github.com>

On Sun, 17 Aug 2025 15:32:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
> 
> ### Parent::requestLayout
> 
>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
> 
> ### Node::managedProperty
> 
>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
> 
> And:
> 
>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
> 
> From this I conclude that:
> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
> 
> Note that Scene currently does not have a dirty layout list.
> 
> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

If the node is unmanaged, why does it need a relayout in practice?

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3197735579

From mfox at openjdk.org  Mon Aug 18 17:23:43 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 18 Aug 2025 17:23:43 GMT
Subject: RFR: 8364547: Window size may be incorrect when constrained to min
 or max [v2]
In-Reply-To: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
References: <emHN0loCts6DubqTCWRCgqrK3BS_jw_ZZUJozRDOTW8=.deca87f8-ad1a-42e6-9c2b-a7434dbd04bd@github.com>
Message-ID: <ooO_3LEcqWnu7NtDPoaiGvJ12MymHCTYcSom8krf-JA=.43957b6d-4bd2-4e7e-bebb-41c4bbc81433@github.com>

> When changing the width and height of a window the platform code is responsible for enforcing the min and max size constraints. If the final width and height don't match the width and height passed into setBounds the platform needs to call notifyResize to correct the window's properties. This happens naturally if the window size actually changes since that will trigger the OS to send size change notifications. If the platform window size doesn't change the OS notifications won't trigger. We need to catch that case and send notifyResize anyway.
> 
> This PR does this for Mac and Windows. Linux is being handled in PR #1789 which also includes the system tests for these bugs.

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

  Remove double notifications, keep window min/max/normal state unchanged.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1870/files
  - new: https://git.openjdk.org/jfx/pull/1870/files/1c452782..468fd354

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

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

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

From nlisker at gmail.com  Mon Aug 18 17:46:01 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 18 Aug 2025 20:46:01 +0300
Subject: null parameter constructors in StringConverters
Message-ID: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>

Hi all,

In DateTimeStringConverter, NumberStringConverter, and their subclasses,
null parameters sent to the constructors are internally converted to
default values. This is not specified, but it's how the implementation
behaves. I'm working on some changes there and was thinking about changing
the behavior to throw NPEs as it makes no sense to pass null into these and
it's probably a bug more than anything.

The LocalDate/Time converters specified the null-friendly behavior in their
docs even though it doesn't make much sense there either.

Are we allowed to change this?

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

From jhendrikx at openjdk.org  Mon Aug 18 18:04:18 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 18:04:18 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <V1yhAPhPU0aujbGDdrQEi1T43M1IAdigs7zE3EOKCu8=.1d6fcfe7-dc28-4830-9b9a-e6925b597ae6@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
 <V1yhAPhPU0aujbGDdrQEi1T43M1IAdigs7zE3EOKCu8=.1d6fcfe7-dc28-4830-9b9a-e6925b597ae6@github.com>
Message-ID: <Qn0bpb6koPZMblB2ctWMq-uuD3L5rWVZ1amrweJspyw=.2af83a78-29f8-4336-8613-07fbe7856872@github.com>

On Mon, 18 Aug 2025 17:01:59 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> If the node is unmanaged, why does it need a relayout in practice?

The unmanaged node does not need relayout, but its potentially managed children do.  Just like a Scene does not need layout, but its root does.  A node being unmanaged affects its **parent** (the parent must skip it for layout calculations), but does not free it from doing layout on its own children (if I interpret the documentation correctly).

Let's take this hierarchy:

    Region
         StackPane (unmanaged)
               ImageView

The Region will not lay out the stack pane as it is unmanaged, so I position the unmanaged child manually with `resizeRelocate`.  The StackPane now has a defined position and size.  When I add children to it, the StackPane's `layout` (and conversely `layoutChildren`) should still be called to ensure the children nicely fill the StackPane's space.

JavaFX currently will do steps 1 and 2, but does not do step 3:

1. Another child is added to the StackPane (an overlay for the ImageView) this triggers a requestLayout on that child which marks it as needing layout
2. This propagates to the parent, which is also marked as needing layout, but it is considered to be a layout root, so no further propagation occurs
3. Since a layout root was encountered, it should be added to the list of dirty layout roots (implemented in this PR).  This will clear all the needs layout flags (otherwise they stay `true` and never go back to `false` again).

The documentation however seems quite clear that step 3 is also supposed to be done.

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3197898264

From john.hendrikx at gmail.com  Mon Aug 18 18:06:29 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 18 Aug 2025 20:06:29 +0200
Subject: null parameter constructors in StringConverters
In-Reply-To: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
Message-ID: <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>

Aren't these constructors chained???I believe it is quite common
practice to use nulls when calling a chained constructor to get a
default for that parameter.? If a certain type of convenience
constructor is missing, a caller can?pass in `null` for the parameter
they'd like defaulted.? It's not too far-fetched to allow this **if**
there is a constructor where this parameter is omitted and is assigned a
default.

If anything, the constructors IMHO should document that for certain
parameters passing in `null` results in a specific default.

--John

On 18/08/2025 19:46, Nir Lisker wrote:
> Hi all,
>
> In DateTimeStringConverter, NumberStringConverter, and their
> subclasses, null parameters sent to the constructors are internally
> converted to default values. This is not specified, but it's how the
> implementation behaves. I'm working on some changes there and was
> thinking about changing the behavior to throw NPEs as it makes
> no?sense to pass null into these and it's probably a bug more?than
> anything.
>
> The LocalDate/Time converters specified the null-friendly behavior in
> their docs even though it doesn't make much sense there either.
>
> Are we allowed to change this?
>
> - Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/16fb1939/attachment.htm>

From jhendrikx at openjdk.org  Mon Aug 18 18:17:18 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 18:17:18 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
Message-ID: <4cyjrUaGzfSEAFzHwXk3Jou0VgSX1g-w070S16y74Ow=.6c2fe58a-3579-4414-958e-3a3e00a3a311@github.com>

On Sat, 16 Aug 2025 20:44:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

LGTM

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1873#pullrequestreview-3129413087

From nlisker at openjdk.org  Mon Aug 18 18:33:20 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 18:33:20 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
Message-ID: <TfWA8IekDGzY2AYc-w2vhhq_tXbVH9UzbWVpAOiDGNA=.8ee35254-791d-4387-9a8c-8b4c31ba2398@github.com>

On Sat, 16 Aug 2025 20:44:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

Forgot to attach a small manual test application I used for testing full DPR and DnD. Might be helpful for reviewers.

package main;

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

public class MouseTest extends Application {

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

    @Override
    public void start(@SuppressWarnings("exports") Stage stage) throws Exception {
        var sourceMouse = createSourceMouse();
        var sourceDrag = createSourceDrag();
        var target = createTarget();

        var scene = createScene(sourceMouse, sourceDrag, target);
        stage.setScene(scene);
        stage.show();
    }

    private Rectangle createSourceMouse() {
        var sourceMouse = new Rectangle(50, 50);
        sourceMouse.setId("sourceMouse");
        sourceMouse.setFill(Color.RED);
        sourceMouse.setOnDragDetected(e -> {
            sourceMouse.startFullDrag();
            System.out.println(e.getEventType() + " " + sourceMouse.getId());
            e.consume();
        });
        addDragListeners(sourceMouse);
        return sourceMouse;
    }

    private Rectangle createSourceDrag() {
        var sourceDrag = new Rectangle(50, 50);
        sourceDrag.setId("sourceDrag");
        sourceDrag.setFill(Color.GREEN);
        sourceDrag.setOnDragDetected(e -> {
            Dragboard db = sourceDrag.startDragAndDrop(TransferMode.ANY);
            var content = new ClipboardContent();
            content.putString("");
            db.setContent(content);
            System.out.println(e.getEventType() + " " + sourceDrag.getId());
            e.consume();
        });
        addDragListeners(sourceDrag);
        return sourceDrag;
    }

    private Rectangle createTarget() {
        var target = new Rectangle(100, 50);
        target.setId("target");
        target.setFill(Color.BLUE);
        target.setOnDragDetected(MouseEvent::consume);
        addDragListeners(target);
        return target;
    }

    private Scene createScene(Rectangle sourceMouse, Rectangle sourceDrag, Rectangle target) {
        var scene = new Scene(new VBox(10, new HBox(sourceMouse, sourceDrag), target), 300, 200);
        scene.setOnDragDetected(e -> {
            scene.startFullDrag();
            System.out.println(e.getEventType() + " scene");
        });

        scene.setOnDragDone(e -> {
            e.acceptTransferModes(TransferMode.ANY);
            System.out.println(e.getEventType() + " scene");
        });
        scene.setOnMouseDragReleased(e -> System.out.println(e.getEventType() + " scene"));
        scene.setOnMouseDragDone(e -> System.out.println(e.getEventType() + " scene"));
        return scene;
    }

    private static void addDragListeners(Node node) {
        node.setOnDragOver(e -> {
            e.acceptTransferModes(TransferMode.ANY);
            System.out.println(e.getEventType() + " " + node.getId());
        });
        node.setOnMouseDragOver(e -> System.out.println(e.getEventType() + " " + node.getId()));

        node.setOnDragDropped(e -> {
            e.acceptTransferModes(TransferMode.ANY);
            e.setDropCompleted(true);
            System.out.println(e.getEventType() + " " + node.getId());
        });
        node.setOnMouseDragReleased(e -> System.out.println(e.getEventType() + " " + node.getId()));

        node.setOnDragDone(e -> {
            e.acceptTransferModes(TransferMode.ANY);
            System.out.println(e.getEventType() + " " + node.getId());
        });
        node.setOnMouseDragDone(e -> System.out.println(e.getEventType() + " " + node.getId()));
    }
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1873#issuecomment-3197980633

From mstrauss at openjdk.org  Mon Aug 18 18:57:50 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 18 Aug 2025 18:57:50 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
Message-ID: <JDNM00uDD8EoKJuuz5qIPjH7OXZTts_lPM-bYSzqDCc=.3d393ad6-37fa-4a34-bfaa-3b4f328d7176@github.com>

On Sat, 16 Aug 2025 20:44:28 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.

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

> 7716:     }
> 7717: 
> 7718:     /// Defines a function to be called when a full press-drag-release gesture ends with this node as its source.

This is the first instance of markdown-style javadoc comments in JavaFX. Do we need a discussion surrounding their use?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2283161713

From nlisker at gmail.com  Mon Aug 18 19:00:31 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 18 Aug 2025 22:00:31 +0300
Subject: null parameter constructors in StringConverters
In-Reply-To: <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
Message-ID: <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>

>
> Aren't these constructors chained?


Not all of them. There are 3 tangential creation paths for
DateTimeStringConverter and subclasses:
1. Through dateStyle/timeStyle ints with an optional locale that creates
the DateFormat with `DateFormat.getDateTimeInstance(dateStyle, timeStyle,
locale)` (similar for subclasses). There are 4 constructors here for the
combinations of: none, only style(s), only locale, all.
2. Through a String pattern with an optional locale that creates the
DateFormat with `new SimpleDateFormat(pattern, locale)`. If pattern is
null, it uses path 1 above with default styles and the optional locale. If
you wanted to use a pattern to create this converter, passing null makes
little sense. It could be surprising to get a "defaults" converter when you
intended to customize the format with your own pattern to begin with. I
imagine that if you couldn't get a pattern, you'd use your own int styles
as a replacement.
3. Through a DateFormat that is used directly. If it's null, it checks if
the pattern is null (which it will always be), in which case it uses the
defaults of path 1 again (with the default locale since it's not optional
here). I find it odd here too to pass null and rely on the
"defaults" converter.

NumberStringConverter and its subclasses are similar. They have path 2 with
4 combinations: none, only pattern, and locale, and both. And they also
have path 3 that falls on the default if null.

On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Aren't these constructors chained?  I believe it is quite common practice
> to use nulls when calling a chained constructor to get a default for that
> parameter.  If a certain type of convenience constructor is missing, a
> caller can pass in `null` for the parameter they'd like defaulted.  It's
> not too far-fetched to allow this **if** there is a constructor where this
> parameter is omitted and is assigned a default.
>
> If anything, the constructors IMHO should document that for certain
> parameters passing in `null` results in a specific default.
>
> --John
> On 18/08/2025 19:46, Nir Lisker wrote:
>
> Hi all,
>
> In DateTimeStringConverter, NumberStringConverter, and their subclasses,
> null parameters sent to the constructors are internally converted to
> default values. This is not specified, but it's how the implementation
> behaves. I'm working on some changes there and was thinking about changing
> the behavior to throw NPEs as it makes no sense to pass null into these and
> it's probably a bug more than anything.
>
> The LocalDate/Time converters specified the null-friendly behavior in
> their docs even though it doesn't make much sense there either.
>
> Are we allowed to change this?
>
> - Nir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/b374e955/attachment.htm>

From nlisker at openjdk.org  Mon Aug 18 19:33:48 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 19:33:48 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <JDNM00uDD8EoKJuuz5qIPjH7OXZTts_lPM-bYSzqDCc=.3d393ad6-37fa-4a34-bfaa-3b4f328d7176@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <JDNM00uDD8EoKJuuz5qIPjH7OXZTts_lPM-bYSzqDCc=.3d393ad6-37fa-4a34-bfaa-3b4f328d7176@github.com>
Message-ID: <zZD0IJ_U9IL3KaWyqEKFBPZ4KlNwLnlj8My5u7AZTRo=.a1b7b8e2-e54e-49d1-b214-12b55599c6b2@github.com>

On Mon, 18 Aug 2025 18:39:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Adds `MOUSE_DRAG_DONE` event type to `MouseDragEvent` and appropriate handlers.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 7718:
> 
>> 7716:     }
>> 7717: 
>> 7718:     /// Defines a function to be called when a full press-drag-release gesture ends with this node as its source.
> 
> This is the first instance of markdown-style javadoc comments in JavaFX. Do we need a discussion surrounding their use?

They were added in JDK 23, which we can use. I don't know if there's anything special to discuss. The JEP gives standard usage examples, which I've followed, so there's no "feature abuse" here either.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2283265209

From kcr at openjdk.org  Mon Aug 18 19:54:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Aug 2025 19:54:41 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
Message-ID: <anXEaD0y7JY_l7TnJps8ydOIpiW2F7rfhcJkI4ynWkg=.6562e186-81cb-4270-bf83-077ad5a14c5b@github.com>

On Mon, 18 Aug 2025 09:35:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Support background loading of raw input streams
> 
> - Fixed generics (mix up of two ImageLoader types)
> - Removed unused code for handling headers, methods, request parameters
> - Use `long` for progress as streams may exceed 2 GB
> - Improved documentation of Image regarding background loading

Reviewers: @kevinrushforth @jayathirthrao

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198208545

From kcr at openjdk.org  Mon Aug 18 19:57:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Aug 2025 19:57:44 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
Message-ID: <mqTY2mpPLzct1Nbnmc0pxo-tHTMbQ8NkeW-vxF9_ItQ=.d5a2e937-dda2-4487-b8df-c9e6303d4b40@github.com>

On Mon, 18 Aug 2025 09:35:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Support background loading of raw input streams
> 
> - Fixed generics (mix up of two ImageLoader types)
> - Removed unused code for handling headers, methods, request parameters
> - Use `long` for progress as streams may exceed 2 GB
> - Improved documentation of Image regarding background loading

This will need a CSR. The newly proposed constructors should have an `@since` tag.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198218532

From angorya at openjdk.org  Mon Aug 18 20:05:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 20:05:06 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
Message-ID: <EqC8IflHEwNVZdhIzgbd1w5Ec6yZLGTwrsUXopJakqI=.eb2ae226-65ff-4990-9748-6ad40dcc319c@github.com>

On Mon, 18 Aug 2025 09:35:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Support background loading of raw input streams
> 
> - Fixed generics (mix up of two ImageLoader types)
> - Removed unused code for handling headers, methods, request parameters
> - Use `long` for progress as streams may exceed 2 GB
> - Improved documentation of Image regarding background loading

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

> 741:      * @throws NullPointerException if input stream is null
> 742:      */
> 743:     public Image(@NamedArg("is") InputStream is, @NamedArg("backgroundLoading") boolean backgroundLoading) {

suggestion: swap the arguments to avoid explicit typecasting in the case of `(null, boolean)`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2283332179

From jhendrikx at openjdk.org  Mon Aug 18 20:12:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 20:12:54 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <EqC8IflHEwNVZdhIzgbd1w5Ec6yZLGTwrsUXopJakqI=.eb2ae226-65ff-4990-9748-6ad40dcc319c@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <EqC8IflHEwNVZdhIzgbd1w5Ec6yZLGTwrsUXopJakqI=.eb2ae226-65ff-4990-9748-6ad40dcc319c@github.com>
Message-ID: <MCLgxA0i1ZRYJ7CTPblFbpWpk7-hmlpWfSXNeQI8yZI=.5dfc70cc-58f8-4f32-8d3e-be896315f9b5@github.com>

On Mon, 18 Aug 2025 20:01:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Support background loading of raw input streams
>> 
>> - Fixed generics (mix up of two ImageLoader types)
>> - Removed unused code for handling headers, methods, request parameters
>> - Use `long` for progress as streams may exceed 2 GB
>> - Improved documentation of Image regarding background loading
>
> modules/javafx.graphics/src/main/java/javafx/scene/image/Image.java line 743:
> 
>> 741:      * @throws NullPointerException if input stream is null
>> 742:      */
>> 743:     public Image(@NamedArg("is") InputStream is, @NamedArg("backgroundLoading") boolean backgroundLoading) {
> 
> suggestion: swap the arguments to avoid explicit typecasting in the case of `(null, boolean)`

`null` isn't allowed, so this is only in the test.  Also, the cast is only to select the correct method overload, there won't actually be a cast.  I also think it is better to keep the same order (there is another constructor that takes an `InputStream` + parameters, and there are similar constructors for URL + parameters)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1875#discussion_r2283352941

From mstrauss at openjdk.org  Mon Aug 18 20:21:47 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 18 Aug 2025 20:21:47 GMT
Subject: RFR: 8365635: Add MOUSE_DRAG_DONE event type
In-Reply-To: <zZD0IJ_U9IL3KaWyqEKFBPZ4KlNwLnlj8My5u7AZTRo=.a1b7b8e2-e54e-49d1-b214-12b55599c6b2@github.com>
References: <exVGpx1X02b6c22c0nMKcbg2hC9pnr2sA_v__x9u92E=.59b8e562-2c88-4be6-a0cf-20db11b7dbee@github.com>
 <JDNM00uDD8EoKJuuz5qIPjH7OXZTts_lPM-bYSzqDCc=.3d393ad6-37fa-4a34-bfaa-3b4f328d7176@github.com>
 <zZD0IJ_U9IL3KaWyqEKFBPZ4KlNwLnlj8My5u7AZTRo=.a1b7b8e2-e54e-49d1-b214-12b55599c6b2@github.com>
Message-ID: <sJRFcZGoKaTuUDeUtcA1Nc1CXQH54yW9uuye4JXQaZo=.d27dea3f-4ede-4839-a8b2-489923f2b139@github.com>

On Mon, 18 Aug 2025 19:31:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 7718:
>> 
>>> 7716:     }
>>> 7717: 
>>> 7718:     /// Defines a function to be called when a full press-drag-release gesture ends with this node as its source.
>> 
>> This is the first instance of markdown-style javadoc comments in JavaFX. Do we need a discussion surrounding their use?
>
> They were added in JDK 23, which we can use. I don't know if there's anything special to discuss. The JEP gives standard usage examples, which I've followed, so there's no "feature abuse" here either.

Well, they look very different from the other style. Usually matters of style are settled once in a style guide, which we don't have. But I think we should at least consciously agree that we're fine with having two different styles of documentation in the same project. Personally, I value uniformity of style more than the (little) added value that markdown comments bring.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1873#discussion_r2283373284

From jhendrikx at openjdk.org  Mon Aug 18 20:22:16 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 20:22:16 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream [v2]
In-Reply-To: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
Message-ID: <KwuCtSVSYNSCLJoWpV7y4V9HQJ-Whhvtea7NuJN4ybo=.353786a9-ccd4-48e0-a993-317dfce2c603@github.com>

> Support background loading of raw input streams
> 
> - Fixed generics (mix up of two ImageLoader types)
> - Removed unused code for handling headers, methods, request parameters
> - Use `long` for progress as streams may exceed 2 GB
> - Improved documentation of Image regarding background loading

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

  Add since tags

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1875/files
  - new: https://git.openjdk.org/jfx/pull/1875/files/1452b5c1..63e652e5

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

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

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

From nlisker at openjdk.org  Mon Aug 18 20:22:16 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 20:22:16 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
Message-ID: <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>

On Mon, 18 Aug 2025 09:35:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Support background loading of raw input streams
> 
> - Fixed generics (mix up of two ImageLoader types)
> - Removed unused code for handling headers, methods, request parameters
> - Use `long` for progress as streams may exceed 2 GB
> - Improved documentation of Image regarding background loading

Do we still use `@NamedArg`? I thought it's a remnant of pre-Java 8 where parameter names weren't saved.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198286371

From jhendrikx at openjdk.org  Mon Aug 18 20:22:16 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 20:22:16 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>
Message-ID: <wHxPNKRqvWsiS1_haSW_aVS3i5VjcNQS9Hj3A4KgDs8=.1df8d0b1-dbd9-47e6-8afe-c128f110ea5b@github.com>

On Mon, 18 Aug 2025 20:14:48 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Do we still use `@NamedArg`? I thought it's a remnant of pre-Java 8 where parameter names weren't saved.

I don't know about the `NamedArg` specifics, but I do know that saving parameter names is optional and I think still off by default (ie. you need to pass a compiler option to save the names).  Other than that, I just copied what was there and kept the same format.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198290113

From kcr at openjdk.org  Mon Aug 18 20:28:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Aug 2025 20:28:52 GMT
Subject: RFR: 8365632: Remove unused local variable in GlassWindow
In-Reply-To: <-4KGIekcwJ6l6RbYHQNxQXaaUHK9VlpjXN-XAfIhHF0=.6f4996a8-e40f-4674-8f0e-3a543daee5a9@github.com>
References: <-4KGIekcwJ6l6RbYHQNxQXaaUHK9VlpjXN-XAfIhHF0=.6f4996a8-e40f-4674-8f0e-3a543daee5a9@github.com>
Message-ID: <cl5QQCTLDj_fpZ-7tW8AelnONmUFFHCGqlJI1RLFAxA=.093b99c0-1025-4a50-a450-8fcdacc0014c@github.com>

On Sat, 16 Aug 2025 07:04:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `originalSize` in GlassWindow::HandleNCCalcSizeEvent is not used and can be removed.

LGTM

A single reviewer will suffice.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1872#pullrequestreview-3129806281

From john.hendrikx at gmail.com  Mon Aug 18 20:30:09 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 18 Aug 2025 22:30:09 +0200
Subject: null parameter constructors in StringConverters
In-Reply-To: <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
 <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
Message-ID: <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>

If certain patterns make no sense, then I think the master constructor
should reject them (if there is one, or perhaps one should be created as
a private one).

For example, if there is a width/height constructor, but I only specify
width and not height, then I think its fine to reject (null, height) and
(width, null) while accepting (null, null) and (width, height).

But I think I see what you mean better now, for example, there is
(Locale locale, String pattern) and (String pattern). If you intending
to pass `null` as Locale, why not just use the pattern-only
constructor?? I think that still could make sense, especially locale is
say coming from a configuration file or some such.? If the constructor
`null` here, then it makes it easier to use it programmatically (ie. if
my configuration has a Locale then I pass that, if it is null, I pass
that -- compare that to having to check for Locale being null and then
having to select the correct constructor...

--John

On 18/08/2025 21:00, Nir Lisker wrote:
>
>     Aren't these constructors chained?
>
>
> Not all of them. There are 3 tangential creation paths for
> DateTimeStringConverter and subclasses:
> 1. Through dateStyle/timeStyle ints with an optional locale that
> creates the DateFormat with `DateFormat.getDateTimeInstance(dateStyle,
> timeStyle, locale)` (similar for subclasses). There are 4 constructors
> here for the combinations of: none, only style(s), only locale, all.
> 2. Through a String pattern with an optional locale?that creates the
> DateFormat with `new SimpleDateFormat(pattern, locale)`. If pattern is
> null, it uses path 1 above with default styles and the optional
> locale. If you wanted to use a pattern to create this converter,
> passing null makes little sense. It could be?surprising to get a
> "defaults"?converter when you intended to customize?the format with
> your own pattern to begin?with. I imagine that if you couldn't get a
> pattern, you'd use your own int styles as a replacement.
> 3. Through a DateFormat that is used directly. If it's null, it checks
> if the pattern is null (which it will always be), in which case it
> uses the defaults of path 1 again (with the default locale since it's
> not optional here). I find it odd here too to pass null and rely on
> the "defaults"?converter.
>
> NumberStringConverter and its subclasses are similar. They have path 2
> with 4 combinations: none, only pattern, and locale, and both. And
> they also have path 3 that falls on the default if null.
>
> On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx
> <john.hendrikx at gmail.com> wrote:
>
>     Aren't these constructors chained???I believe it is quite common
>     practice to use nulls when calling a chained constructor to get a
>     default for that parameter.? If a certain type of convenience
>     constructor is missing, a caller can?pass in `null` for the
>     parameter they'd like defaulted.? It's not too far-fetched to
>     allow this **if** there is a constructor where this parameter is
>     omitted and is assigned a default.
>
>     If anything, the constructors IMHO should document that for
>     certain parameters passing in `null` results in a specific default.
>
>     --John
>
>     On 18/08/2025 19:46, Nir Lisker wrote:
>>     Hi all,
>>
>>     In DateTimeStringConverter, NumberStringConverter, and their
>>     subclasses, null parameters sent to the constructors are
>>     internally converted to default values. This is not specified,
>>     but it's how the implementation behaves. I'm working on some
>>     changes there and was thinking about changing the behavior to
>>     throw NPEs as it makes no?sense to pass null into these and it's
>>     probably a bug more?than anything.
>>
>>     The LocalDate/Time converters specified the null-friendly
>>     behavior in their docs even though it doesn't make much sense
>>     there either.
>>
>>     Are we allowed to change this?
>>
>>     - Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/df83c13c/attachment.htm>

From kcr at openjdk.org  Mon Aug 18 20:30:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Aug 2025 20:30:52 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
Message-ID: <ofF5Mm9fB4NsSB_rHRoIV9-OKjN7mEqjw6VOPbA-3y4=.47e6f925-c6ab-4ddb-92ae-4e64ca976dc8@github.com>

On Sun, 17 Aug 2025 15:32:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
> 
> ### Parent::requestLayout
> 
>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
> 
> ### Node::managedProperty
> 
>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
> 
> And:
> 
>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
> 
> From this I conclude that:
> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
> 
> Note that Scene currently does not have a dirty layout list.
> 
> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

@arapte Can you review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3198319507

From mstrauss at openjdk.org  Mon Aug 18 20:35:40 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 18 Aug 2025 20:35:40 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <wHxPNKRqvWsiS1_haSW_aVS3i5VjcNQS9Hj3A4KgDs8=.1df8d0b1-dbd9-47e6-8afe-c128f110ea5b@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>
 <wHxPNKRqvWsiS1_haSW_aVS3i5VjcNQS9Hj3A4KgDs8=.1df8d0b1-dbd9-47e6-8afe-c128f110ea5b@github.com>
Message-ID: <0iLnxW2uoL_eQYzdJdxYoRZQMqHgh-wvF9-a_mzDmXE=.17213bf6-6b85-43a1-9b17-78b2142aea95@github.com>

On Mon, 18 Aug 2025 20:16:19 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Do we still use `@NamedArg`? I thought it's a remnant of pre-Java 8 where parameter names weren't saved.

`FXMLoader` uses the `@NamedArg` annotation to associate XML attribute values with constructor arguments.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198333996

From nlisker at gmail.com  Mon Aug 18 20:41:11 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 18 Aug 2025 23:41:11 +0300
Subject: null parameter constructors in StringConverters
In-Reply-To: <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
 <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
 <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>
Message-ID: <CA+0ynh9X3UY2RFnpOLPyYOHw3OPC8SND-G2wFeg9_psrYCa1HQ@mail.gmail.com>

>
> But I think I see what you mean better now, for example, there is (Locale
> locale, String pattern) and (String pattern). If you intending to pass
> `null` as Locale, why not just use the pattern-only constructor?  I think
> that still could make sense,


OK, but what about `pattern` being null in either?

On Mon, Aug 18, 2025 at 11:30?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> If certain patterns make no sense, then I think the master constructor
> should reject them (if there is one, or perhaps one should be created as a
> private one).
>
> For example, if there is a width/height constructor, but I only specify
> width and not height, then I think its fine to reject (null, height) and
> (width, null) while accepting (null, null) and (width, height).
>
> But I think I see what you mean better now, for example, there is (Locale
> locale, String pattern) and (String pattern). If you intending to pass
> `null` as Locale, why not just use the pattern-only constructor?  I think
> that still could make sense, especially locale is say coming from a
> configuration file or some such.  If the constructor `null` here, then it
> makes it easier to use it programmatically (ie. if my configuration has a
> Locale then I pass that, if it is null, I pass that -- compare that to
> having to check for Locale being null and then having to select the correct
> constructor...
>
> --John
>
> On 18/08/2025 21:00, Nir Lisker wrote:
>
> Aren't these constructors chained?
>
>
> Not all of them. There are 3 tangential creation paths for
> DateTimeStringConverter and subclasses:
> 1. Through dateStyle/timeStyle ints with an optional locale that creates
> the DateFormat with `DateFormat.getDateTimeInstance(dateStyle, timeStyle,
> locale)` (similar for subclasses). There are 4 constructors here for the
> combinations of: none, only style(s), only locale, all.
> 2. Through a String pattern with an optional locale that creates the
> DateFormat with `new SimpleDateFormat(pattern, locale)`. If pattern is
> null, it uses path 1 above with default styles and the optional locale. If
> you wanted to use a pattern to create this converter, passing null makes
> little sense. It could be surprising to get a "defaults" converter when you
> intended to customize the format with your own pattern to begin with. I
> imagine that if you couldn't get a pattern, you'd use your own int styles
> as a replacement.
> 3. Through a DateFormat that is used directly. If it's null, it checks if
> the pattern is null (which it will always be), in which case it uses the
> defaults of path 1 again (with the default locale since it's not optional
> here). I find it odd here too to pass null and rely on the
> "defaults" converter.
>
> NumberStringConverter and its subclasses are similar. They have path 2
> with 4 combinations: none, only pattern, and locale, and both. And they
> also have path 3 that falls on the default if null.
>
> On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> Aren't these constructors chained?  I believe it is quite common practice
>> to use nulls when calling a chained constructor to get a default for that
>> parameter.  If a certain type of convenience constructor is missing, a
>> caller can pass in `null` for the parameter they'd like defaulted.  It's
>> not too far-fetched to allow this **if** there is a constructor where this
>> parameter is omitted and is assigned a default.
>>
>> If anything, the constructors IMHO should document that for certain
>> parameters passing in `null` results in a specific default.
>>
>> --John
>> On 18/08/2025 19:46, Nir Lisker wrote:
>>
>> Hi all,
>>
>> In DateTimeStringConverter, NumberStringConverter, and their subclasses,
>> null parameters sent to the constructors are internally converted to
>> default values. This is not specified, but it's how the implementation
>> behaves. I'm working on some changes there and was thinking about changing
>> the behavior to throw NPEs as it makes no sense to pass null into these and
>> it's probably a bug more than anything.
>>
>> The LocalDate/Time converters specified the null-friendly behavior in
>> their docs even though it doesn't make much sense there either.
>>
>> Are we allowed to change this?
>>
>> - Nir
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/508894f4/attachment.htm>

From angorya at openjdk.org  Mon Aug 18 20:41:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 20:41:47 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <0iLnxW2uoL_eQYzdJdxYoRZQMqHgh-wvF9-a_mzDmXE=.17213bf6-6b85-43a1-9b17-78b2142aea95@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>
 <wHxPNKRqvWsiS1_haSW_aVS3i5VjcNQS9Hj3A4KgDs8=.1df8d0b1-dbd9-47e6-8afe-c128f110ea5b@github.com>
 <0iLnxW2uoL_eQYzdJdxYoRZQMqHgh-wvF9-a_mzDmXE=.17213bf6-6b85-43a1-9b17-78b2142aea95@github.com>
Message-ID: <aSr8nqVeYho6_18JHhpurz9ADJ3LFpd00m2RCsYFc8U=.e9f733b9-46fc-445c-aa24-7301fc38f44b@github.com>

On Mon, 18 Aug 2025 20:33:08 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `FXMLoader` uses the `@NamedArg` annotation to associate XML attribute values with constructor arguments.

I wonder if this should be explained in the @NamedArg javadoc.

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198348152

From jhendrikx at openjdk.org  Mon Aug 18 20:44:44 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 20:44:44 GMT
Subject: RFR: 8361286: Allow enabling of background loading for images
 loaded from an InputStream
In-Reply-To: <aSr8nqVeYho6_18JHhpurz9ADJ3LFpd00m2RCsYFc8U=.e9f733b9-46fc-445c-aa24-7301fc38f44b@github.com>
References: <cKcDRyomMdZJAZp0pzH8nbz758iSMIqJ4zuL34yH1BM=.fa95832a-22c0-48e9-b04b-b062e8138202@github.com>
 <jxa8RNSLnBpbFi7yTZal-aC1_IWDToyCZDDAmfw42Ks=.e54e558f-d7ef-4eaa-98d4-2332593d95be@github.com>
 <wHxPNKRqvWsiS1_haSW_aVS3i5VjcNQS9Hj3A4KgDs8=.1df8d0b1-dbd9-47e6-8afe-c128f110ea5b@github.com>
 <0iLnxW2uoL_eQYzdJdxYoRZQMqHgh-wvF9-a_mzDmXE=.17213bf6-6b85-43a1-9b17-78b2142aea95@github.com>
 <aSr8nqVeYho6_18JHhpurz9ADJ3LFpd00m2RCsYFc8U=.e9f733b9-46fc-445c-aa24-7301fc38f44b@github.com>
Message-ID: <KeDEdmyvIS8CbWaHkYBnro5M56jZperHtAuC3w_ALR0=.85dbddad-8e67-493e-a3c8-621bb031828b@github.com>

On Mon, 18 Aug 2025 20:38:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > `FXMLoader` uses the `@NamedArg` annotation to associate XML attribute values with constructor arguments.
> 
> I wonder if this should be explained in the @NamedArg javadoc.

It probably should, I never use FXML, but I should have guessed it was for that purpose :)

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

PR Comment: https://git.openjdk.org/jfx/pull/1875#issuecomment-3198356845

From nlisker at openjdk.org  Mon Aug 18 21:17:43 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 18 Aug 2025 21:17:43 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
Message-ID: <SDCm2cqwAUB0wVN7HXN2_eeHLvK4wLkcqn_hlJO_t-w=.453695f3-bd4c-4c27-8a44-b39f226d441e@github.com>

On Sun, 17 Aug 2025 15:32:24 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR adds the necessary logic to automatically relayout unmanaged nodes when they're dirty as specified by the documentation. Relevant sections (emphasis mine):
> 
> ### Parent::requestLayout
> 
>> If this parent is either a layout root or unmanaged, then it will be added directly to the **scene's dirty layout list**, otherwise requestParentLayout will be invoked.
> 
> ### Node::managedProperty
> 
>> If a managed node's layoutBounds changes, it will **automatically trigger relayout** up the scene-graph to the **nearest layout root**
> 
> And:
> 
>> If an **unmanaged node** is of type `Parent`, it will act as a **"layout root"**
> 
> From this I conclude that:
> - A layout root is any node that is unmanaged (and of type `Parent`), or a Scene's root node
> - Changes requiring layout in managed children that have an unmanaged parent somewhere in their ancestry should cause layout to be triggered for the affected areas
> - Automatic relayout is triggered either by scheduling a pulse (for scene roots) or by adding a layout root to the Scene's dirty layout list
> 
> Note that Scene currently does not have a dirty layout list.
> 
> Note also that the documentation for `requestLayout` probably meant to say "**scene** root or unmanaged" instead of "**layout** root or unmanaged."

Does `SubScene`'s root also count as a layout root?

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3198448900

From john.hendrikx at gmail.com  Mon Aug 18 21:34:08 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 18 Aug 2025 23:34:08 +0200
Subject: null parameter constructors in StringConverters
In-Reply-To: <CA+0ynh9X3UY2RFnpOLPyYOHw3OPC8SND-G2wFeg9_psrYCa1HQ@mail.gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
 <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
 <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>
 <CA+0ynh9X3UY2RFnpOLPyYOHw3OPC8SND-G2wFeg9_psrYCa1HQ@mail.gmail.com>
Message-ID: <07b4544f-585d-4f04-bc09-7a681299e682@gmail.com>

I think it may come down to whether rejecting `null` would be helpful
for users of these constructors to find problems in their code.? I agree
that the DateTimeStringConverter is not really a chained constructor
with a clear (and public) master constructor that is documented to allow
`null` for certain defaults.? It is more a style of programming used
throughout FX to provide many constructors (Image is also like that)
instead of a Builder or static factory method.

I could make arguments that it would make programmatic use easier, but
that never stopped me from rejecting nulls in my own code.? Callers then
should just pick their own defaults, like:

?????? new DateTimeConverter(locale == null ? Locale.DEFAULT : locale,
pattern == null ? "ddMMyy" : pattern)

Personally, I think this is not worth changing, but I do think it should
be documented.? Rejecting nulls now will definitely require a CSR and is
not backwards compatible :/

--John

On 18/08/2025 22:41, Nir Lisker wrote:

>     But I think I see what you mean better now, for example, there
>     is?(Locale locale, String pattern) and?(String pattern). If you
>     intending to pass `null` as Locale, why not just use the
>     pattern-only constructor?? I think that still could make sense,
>
>
> OK, but what about `pattern` being null in either?
>
> On Mon, Aug 18, 2025 at 11:30?PM John Hendrikx
> <john.hendrikx at gmail.com> wrote:
>
>     If certain patterns make no sense, then I think the master
>     constructor should reject them (if there is one, or perhaps one
>     should be created as a private one).
>
>     For example, if there is a width/height constructor, but I only
>     specify width and not height, then I think its fine to reject
>     (null, height) and (width, null) while accepting (null, null) and
>     (width, height).
>
>     But I think I see what you mean better now, for example, there is
>     (Locale locale, String pattern) and (String pattern). If you
>     intending to pass `null` as Locale, why not just use the
>     pattern-only constructor?? I think that still could make sense,
>     especially locale is say coming from a configuration file or some
>     such.? If the constructor `null` here, then it makes it easier to
>     use it programmatically (ie. if my configuration has a Locale then
>     I pass that, if it is null, I pass that -- compare that to having
>     to check for Locale being null and then having to select the
>     correct constructor...
>
>     --John
>
>     On 18/08/2025 21:00, Nir Lisker wrote:
>>
>>         Aren't these constructors chained?
>>
>>
>>     Not all of them. There are 3 tangential creation paths for
>>     DateTimeStringConverter and subclasses:
>>     1. Through dateStyle/timeStyle ints with an optional locale that
>>     creates the DateFormat with
>>     `DateFormat.getDateTimeInstance(dateStyle, timeStyle, locale)`
>>     (similar for subclasses). There are 4 constructors here for the
>>     combinations of: none, only style(s), only locale, all.
>>     2. Through a String pattern with an optional locale?that creates
>>     the DateFormat with `new SimpleDateFormat(pattern, locale)`. If
>>     pattern is null, it uses path 1 above with default styles and the
>>     optional locale. If you wanted to use a pattern to create this
>>     converter, passing null makes little sense. It could
>>     be?surprising to get a "defaults"?converter when you intended to
>>     customize?the format with your own pattern to begin?with. I
>>     imagine that if you couldn't get a pattern, you'd use your own
>>     int styles as a replacement.
>>     3. Through a DateFormat that is used directly. If it's null, it
>>     checks if the pattern is null (which it will always be), in which
>>     case it uses the defaults of path 1 again (with the default
>>     locale since it's not optional here). I find it odd here too to
>>     pass null and rely on the "defaults"?converter.
>>
>>     NumberStringConverter and its subclasses are similar. They have
>>     path 2 with 4 combinations: none, only pattern, and locale, and
>>     both. And they also have path 3 that falls on the default if null.
>>
>>     On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx
>>     <john.hendrikx at gmail.com> wrote:
>>
>>         Aren't these constructors chained???I believe it is quite
>>         common practice to use nulls when calling a chained
>>         constructor to get a default for that parameter.? If a
>>         certain type of convenience constructor is missing, a caller
>>         can?pass in `null` for the parameter they'd like defaulted.?
>>         It's not too far-fetched to allow this **if** there is a
>>         constructor where this parameter is omitted and is assigned a
>>         default.
>>
>>         If anything, the constructors IMHO should document that for
>>         certain parameters passing in `null` results in a specific
>>         default.
>>
>>         --John
>>
>>         On 18/08/2025 19:46, Nir Lisker wrote:
>>>         Hi all,
>>>
>>>         In DateTimeStringConverter, NumberStringConverter, and their
>>>         subclasses, null parameters sent to the constructors are
>>>         internally converted to default values. This is not
>>>         specified, but it's how the implementation behaves. I'm
>>>         working on some changes there and was thinking about
>>>         changing the behavior to throw NPEs as it makes no?sense to
>>>         pass null into these and it's probably a bug more?than
>>>         anything.
>>>
>>>         The LocalDate/Time converters specified the null-friendly
>>>         behavior in their docs even though it doesn't make much
>>>         sense there either.
>>>
>>>         Are we allowed to change this?
>>>
>>>         - Nir
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/2622936a/attachment-0001.htm>

From jhendrikx at openjdk.org  Mon Aug 18 21:58:45 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 18 Aug 2025 21:58:45 GMT
Subject: RFR: 8365637: Unmanaged nodes are not added to the Scene's dirty
 layout list
In-Reply-To: <SDCm2cqwAUB0wVN7HXN2_eeHLvK4wLkcqn_hlJO_t-w=.453695f3-bd4c-4c27-8a44-b39f226d441e@github.com>
References: <KVxlPdN52WmzMvCNTueQ5oU3uy4KigsplTpgn_ky434=.4a792eb1-c8fd-4920-add0-2d81e4172a46@github.com>
 <SDCm2cqwAUB0wVN7HXN2_eeHLvK4wLkcqn_hlJO_t-w=.453695f3-bd4c-4c27-8a44-b39f226d441e@github.com>
Message-ID: <_uA8JInlYi0WdBl1K5IT2wlFipDPPH_daF1H1YIY-2M=.b191aeae-9b74-4119-a07a-cc57fe473bb9@github.com>

On Mon, 18 Aug 2025 21:15:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Does `SubScene`'s root also count as a layout root?

After investigation, it seems that SubScene's are considered **scene roots**, so that would it a layout root as well.  This code in `Parent` (which monitors Scene/SubScene properties) convinces me that's the case:

        sceneRoot = (newSubScene != null && newSubScene.getRoot() == this) ||
                    (newScene != null && newScene.getRoot() == this);
        layoutRoot = !isManaged() || sceneRoot;

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

PR Comment: https://git.openjdk.org/jfx/pull/1874#issuecomment-3198543404

From mstrauss at openjdk.org  Mon Aug 18 22:01:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 18 Aug 2025 22:01:54 GMT
Subject: Integrated: 8365632: Remove unused local variable in GlassWindow
In-Reply-To: <-4KGIekcwJ6l6RbYHQNxQXaaUHK9VlpjXN-XAfIhHF0=.6f4996a8-e40f-4674-8f0e-3a543daee5a9@github.com>
References: <-4KGIekcwJ6l6RbYHQNxQXaaUHK9VlpjXN-XAfIhHF0=.6f4996a8-e40f-4674-8f0e-3a543daee5a9@github.com>
Message-ID: <QYfusnQt4M2mfNciJyhRDVyzgbx_jWbIErY-grfV1Pg=.9bd1d9f3-9b82-4d6a-981b-318d3bacf567@github.com>

On Sat, 16 Aug 2025 07:04:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `originalSize` in GlassWindow::HandleNCCalcSizeEvent is not used and can be removed.

This pull request has now been integrated.

Changeset: 6337d186
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6337d186f948017cb258cfd6a27493863b544008
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8365632: Remove unused local variable in GlassWindow

Reviewed-by: kcr

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

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

From mstrauss at openjdk.org  Mon Aug 18 22:06:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 18 Aug 2025 22:06:35 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v5]
In-Reply-To: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
References: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@github.com>
Message-ID: <11MgxedhdxgS_08W3FAJ-NY0qEiaMqVM_12dgqtHyY0=.6a823be9-3d4c-406f-83e6-a9efe9d84254@github.com>

> Implementation of [viewport characteristics media features](https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics):
> * `width`
> * `height`
> * `aspect-ratio`: width / height
> * `orientation`: `portrait`, `landscape`
> * `display-mode`: `fullscreen`, `standalone` (note: `browser` and `minimal-ui` are not supported in JavaFX)

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 six additional commits since the last revision:

 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Merge branch 'master' into feature/media-features-viewport-characteristics
 - Clarify and test handling of text case
 - documentation
 - Replace context awareness flags with EnumSet
 - Add viewport characteristics media features

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/0ce8703b..d93fc2d0

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

  Stats: 751174 lines in 8883 files changed: 302586 ins; 366722 del; 81866 mod
  Patch: https://git.openjdk.org/jfx/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1844/head:pull/1844

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

From kevin.rushforth at oracle.com  Mon Aug 18 22:42:57 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 18 Aug 2025 15:42:57 -0700
Subject: null parameter constructors in StringConverters
In-Reply-To: <07b4544f-585d-4f04-bc09-7a681299e682@gmail.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
 <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
 <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>
 <CA+0ynh9X3UY2RFnpOLPyYOHw3OPC8SND-G2wFeg9_psrYCa1HQ@mail.gmail.com>
 <07b4544f-585d-4f04-bc09-7a681299e682@gmail.com>
Message-ID: <2ea6791d-70e7-4d14-89cd-a28f4ba6adeb@oracle.com>

I am not sure it is worth changing the behavior either. It allowing null 
were ambiguous (or harmful), then it might be worth it. As it is, it 
seems better to just document the current behavior.

-- Kevin


On 8/18/2025 2:34 PM, John Hendrikx wrote:
>
> I think it may come down to whether rejecting `null` would be helpful 
> for users of these constructors to find problems in their code.? I 
> agree that the DateTimeStringConverter is not really a chained 
> constructor with a clear (and public) master constructor that is 
> documented to allow `null` for certain defaults.? It is more a style 
> of programming used throughout FX to provide many constructors (Image 
> is also like that) instead of a Builder or static factory method.
>
> I could make arguments that it would make programmatic use easier, but 
> that never stopped me from rejecting nulls in my own code.? Callers 
> then should just pick their own defaults, like:
>
> ?????? new DateTimeConverter(locale == null ? Locale.DEFAULT : locale, 
> pattern == null ? "ddMMyy" : pattern)
>
> Personally, I think this is not worth changing, but I do think it 
> should be documented.? Rejecting nulls now will definitely require a 
> CSR and is not backwards compatible :/
>
> --John
>
> On 18/08/2025 22:41, Nir Lisker wrote:
>
>>     But I think I see what you mean better now, for example, there is
>>     (Locale locale, String pattern) and (String pattern). If you
>>     intending to pass `null` as Locale, why not just use the
>>     pattern-only constructor?? I think that still could make sense,
>>
>>
>> OK, but what about `pattern` being null in either?
>>
>> On Mon, Aug 18, 2025 at 11:30?PM John Hendrikx 
>> <john.hendrikx at gmail.com> wrote:
>>
>>     If certain patterns make no sense, then I think the master
>>     constructor should reject them (if there is one, or perhaps one
>>     should be created as a private one).
>>
>>     For example, if there is a width/height constructor, but I only
>>     specify width and not height, then I think its fine to reject
>>     (null, height) and (width, null) while accepting (null, null) and
>>     (width, height).
>>
>>     But I think I see what you mean better now, for example, there is
>>     (Locale locale, String pattern) and (String pattern). If you
>>     intending to pass `null` as Locale, why not just use the
>>     pattern-only constructor?? I think that still could make sense,
>>     especially locale is say coming from a configuration file or some
>>     such.? If the constructor `null` here, then it makes it easier to
>>     use it programmatically (ie. if my configuration has a Locale
>>     then I pass that, if it is null, I pass that -- compare that to
>>     having to check for Locale being null and then having to select
>>     the correct constructor...
>>
>>     --John
>>
>>     On 18/08/2025 21:00, Nir Lisker wrote:
>>>
>>>         Aren't these constructors chained?
>>>
>>>
>>>     Not all of them. There are 3 tangential creation paths for
>>>     DateTimeStringConverter and subclasses:
>>>     1. Through dateStyle/timeStyle ints with an optional locale that
>>>     creates the DateFormat with
>>>     `DateFormat.getDateTimeInstance(dateStyle, timeStyle, locale)`
>>>     (similar for subclasses). There are 4 constructors here for the
>>>     combinations of: none, only style(s), only locale, all.
>>>     2. Through a String pattern with an optional locale?that creates
>>>     the DateFormat with `new SimpleDateFormat(pattern, locale)`. If
>>>     pattern is null, it uses path 1 above with default styles and
>>>     the optional locale. If you wanted to use a pattern to create
>>>     this converter, passing null makes little sense. It could
>>>     be?surprising to get a "defaults"?converter when you intended to
>>>     customize?the format with your own pattern to begin?with. I
>>>     imagine that if you couldn't get a pattern, you'd use your own
>>>     int styles as a replacement.
>>>     3. Through a DateFormat that is used directly. If it's null, it
>>>     checks if the pattern is null (which it will always be), in
>>>     which case it uses the defaults of path 1 again (with the
>>>     default locale since it's not optional here). I find it odd here
>>>     too to pass null and rely on the "defaults"?converter.
>>>
>>>     NumberStringConverter and its subclasses are similar. They have
>>>     path 2 with 4 combinations: none, only pattern, and locale, and
>>>     both. And they also have path 3 that falls on the default if null.
>>>
>>>     On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx
>>>     <john.hendrikx at gmail.com> wrote:
>>>
>>>         Aren't these constructors chained???I believe it is quite
>>>         common practice to use nulls when calling a chained
>>>         constructor to get a default for that parameter.? If a
>>>         certain type of convenience constructor is missing, a caller
>>>         can?pass in `null` for the parameter they'd like defaulted.?
>>>         It's not too far-fetched to allow this **if** there is a
>>>         constructor where this parameter is omitted and is assigned
>>>         a default.
>>>
>>>         If anything, the constructors IMHO should document that for
>>>         certain parameters passing in `null` results in a specific
>>>         default.
>>>
>>>         --John
>>>
>>>         On 18/08/2025 19:46, Nir Lisker wrote:
>>>>         Hi all,
>>>>
>>>>         In DateTimeStringConverter, NumberStringConverter, and
>>>>         their subclasses, null parameters sent to the constructors
>>>>         are internally converted to default values. This is not
>>>>         specified, but it's how the implementation behaves. I'm
>>>>         working on some changes there and was thinking about
>>>>         changing the behavior to throw NPEs as it makes no?sense to
>>>>         pass null into these and it's probably a bug more?than
>>>>         anything.
>>>>
>>>>         The LocalDate/Time converters specified the null-friendly
>>>>         behavior in their docs even though it doesn't make much
>>>>         sense there either.
>>>>
>>>>         Are we allowed to change this?
>>>>
>>>>         - Nir
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250818/c86dbd52/attachment-0001.htm>

From angorya at openjdk.org  Mon Aug 18 23:15:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 23:15:44 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
Message-ID: <JSAP_vjAxhP0GIy8QF8RAxZQvXgZxADik8JZOKBvm7o=.dc180e7d-858c-4024-9398-8a355f661a9f@github.com>

On Wed, 13 Aug 2025 12:31:32 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
> This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue

Good job finding the culprit, @Ziad-Mid !

I've tested with the _whole selector removed_, on Windows at scales 100%, 125%, 150%, and 175%.

I think it looks good:

<img width="1377" height="512" alt="Screenshot 2025-08-18 160538" src="https://github.com/user-attachments/assets/f569d718-e13a-4308-a340-6b3c75922e12" />
<img width="1128" height="699" alt="Screenshot 2025-08-18 160627" src="https://github.com/user-attachments/assets/7da93800-3a21-4b19-9469-752960e1fc11" />
<img width="1135" height="429" alt="Screenshot 2025-08-18 160703" src="https://github.com/user-attachments/assets/67bde879-5dac-4899-a5e6-ee0a1d440c53" />
<img width="665" height="335" alt="Screenshot 2025-08-18 160748" src="https://github.com/user-attachments/assets/a1a0ae78-77ac-4b7d-8a05-fb55deec5a9f" />

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

PR Comment: https://git.openjdk.org/jfx/pull/1869#issuecomment-3198683007
PR Comment: https://git.openjdk.org/jfx/pull/1869#issuecomment-3198685449

From angorya at openjdk.org  Mon Aug 18 23:15:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 23:15:45 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <L8zHl4UuQyBKIJF6gxaEXB50diExWQ2h1vEoQOsd6O0=.e36b9dc5-732c-41e1-8c49-d9aae92b6946@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
 <L8zHl4UuQyBKIJF6gxaEXB50diExWQ2h1vEoQOsd6O0=.e36b9dc5-732c-41e1-8c49-d9aae92b6946@github.com>
Message-ID: <WQWQSC7vGHKzveTSUPpqoeg2QgJP9JOTzrQkVezIZeY=.4c6c3fcb-180d-43ff-85d4-7ce2dbfa8db7@github.com>

On Fri, 15 Aug 2025 09:12:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> The issue occurs when displaying the ColorPicker on a second monitor with scale=1 the ColorPicker appears blurry,
>> This is due to snapping and changing the value of `-fx-snap-to-pixel` for the `ColorPalette` fixes the issue
>
> modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 1982:
> 
>> 1980: .color-palette > .color-picker-grid {
>> 1981:     -fx-padding: 0.5px;
>> 1982:     -fx-snap-to-pixel: true;
> 
> I guess we can completely remove this line then?

Good point - I wonder if the whole block can be removed.
We need to test this on windows with fractional scale though.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1869#discussion_r2283586036

From angorya at openjdk.org  Mon Aug 18 23:15:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 18 Aug 2025 23:15:45 GMT
Subject: RFR: 8322486: ColorPicker: blurry popup
In-Reply-To: <WQWQSC7vGHKzveTSUPpqoeg2QgJP9JOTzrQkVezIZeY=.4c6c3fcb-180d-43ff-85d4-7ce2dbfa8db7@github.com>
References: <pMTsJnYnvI0g-vznqXCRr71lyenwbBNyJyeu2hkKvZ0=.c97db83c-88a4-4de9-8a52-b132cd40cde0@github.com>
 <L8zHl4UuQyBKIJF6gxaEXB50diExWQ2h1vEoQOsd6O0=.e36b9dc5-732c-41e1-8c49-d9aae92b6946@github.com>
 <WQWQSC7vGHKzveTSUPpqoeg2QgJP9JOTzrQkVezIZeY=.4c6c3fcb-180d-43ff-85d4-7ce2dbfa8db7@github.com>
Message-ID: <Y3aN72jMa5KIbPLThrL1updVtWr4YlNV46ykchh8Ehk=.c06e49da-2f49-4814-a759-20af69e3b4db@github.com>

On Mon, 18 Aug 2025 21:58:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css line 1982:
>> 
>>> 1980: .color-palette > .color-picker-grid {
>>> 1981:     -fx-padding: 0.5px;
>>> 1982:     -fx-snap-to-pixel: true;
>> 
>> I guess we can completely remove this line then?
>
> Good point - I wonder if the whole block can be removed.
> We need to test this on windows with fractional scale though.

I suggest we remove the whole thing `.color-palette > .color-picker-grid { ... }`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1869#discussion_r2283682290

From kcr at openjdk.org  Tue Aug 19 02:38:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Aug 2025 02:38:47 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v6]
In-Reply-To: <53KwjkPGATSV9vZn1NWhXbIla_SKIrPH3NjB5sg9nLs=.1fe77c53-d0c3-4df9-8c53-8509351da5a8@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <53KwjkPGATSV9vZn1NWhXbIla_SKIrPH3NjB5sg9nLs=.1fe77c53-d0c3-4df9-8c53-8509351da5a8@github.com>
Message-ID: <PHzx37dSAnNei7XYJR35siZlFAI21p0XvoU2WUlku1U=.7dbfbe7d-ccfc-44a3-8141-152cd1ea7ca6@github.com>

On Mon, 18 Aug 2025 12:11:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
>> 
>> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
>> 
>> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
>> 
>> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make if one line

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1868#pullrequestreview-3130478554

From kcr at openjdk.org  Tue Aug 19 02:38:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Aug 2025 02:38:47 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v2]
In-Reply-To: <OENSz50UV51tTvNqU8QRoVNCxE-GfbOr_FZE_oCV8_A=.19e1a1d8-a5a5-4b5d-8477-6960d1553e6e@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <0IQlvwd6febogVCPw5QkIbqieppdt5fYiHOOAUvglbM=.3e201523-fdb3-4500-ab71-a90ce5659d98@github.com>
 <g4jPv68kt9DDClaS-NpkonLF8ikvhDThncc0-87H2b4=.df863ca7-a7d7-4071-bd43-2e6ec998245a@github.com>
 <OENSz50UV51tTvNqU8QRoVNCxE-GfbOr_FZE_oCV8_A=.19e1a1d8-a5a5-4b5d-8477-6960d1553e6e@github.com>
Message-ID: <Cg0f-9fMgzcRbObHqq1ZPVuYj_1DWDOU5qcSYA2YNpg=.816d90f1-2a15-4af7-b7b1-952a2035b440@github.com>

On Mon, 18 Aug 2025 07:25:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassViewCGL.m line 178:
>> 
>>> 176:                                       withHiDPIAware:isHiDPIAware
>>> 177:                                         withIsSwPipe:isSwPipe
>>> 178:                                        useMTLForBlit:useMTLInGlass];
>> 
>> Minor: indentation isn't consistent.
>
> We are following https://google.github.io/styleguide/objcguide.html#method-invocations & https://google.github.io/styleguide/objcguide.html#method-declarations-and-definitions. So i have also updated the code where it is inconsistent and we are touching in this PR.
> 
> Please correct me if i am wrong.

OK

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1868#discussion_r2283910082

From arapte at openjdk.org  Tue Aug 19 03:35:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Aug 2025 03:35:42 GMT
Subject: RFR: 8350479: SW pipeline should use default pipeline in Glass
 [v6]
In-Reply-To: <53KwjkPGATSV9vZn1NWhXbIla_SKIrPH3NjB5sg9nLs=.1fe77c53-d0c3-4df9-8c53-8509351da5a8@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
 <53KwjkPGATSV9vZn1NWhXbIla_SKIrPH3NjB5sg9nLs=.1fe77c53-d0c3-4df9-8c53-8509351da5a8@github.com>
Message-ID: <_Z-q65tWWVlBX18MNjDidl5hwYK-ZZM41bCUNft7H4w=.f6419d85-cdb2-4fa1-883d-be9b58e7eded@github.com>

On Mon, 18 Aug 2025 12:11:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
>> 
>> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
>> 
>> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
>> 
>> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make if one line

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1868#pullrequestreview-3130554886

From jdv at openjdk.org  Tue Aug 19 03:58:54 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 19 Aug 2025 03:58:54 GMT
Subject: Integrated: 8350479: SW pipeline should use default pipeline in Glass
In-Reply-To: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
References: <4hFwpucxEf5HbXY6RBEzG8UtJerL7TD7Dimg-rWrpos=.c09223dd-c1ad-4dfe-aa9f-7d0a1a9b97fd@github.com>
Message-ID: <bemqfhK0y6Sij_xu1BdZh-evp6JcCkK0a9mBcg2X9TM=.704ff3b9-ed48-4744-9b3e-f0231e2b0c7e@github.com>

On Wed, 13 Aug 2025 10:21:56 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have Metal pipeline also now in macOS apart from OpenGL pipeline for accelerated hardware pipelines.
> 
> Currently when Software pipeline is used we continue to use OpenGL(ES2) pipeline on glass side, which is the default hardware pipeline in macOS. If we want to switch to Metal pipeline as default hardware pipeline in prism, we should be able to use Metal pipeline in glass also when software pipeline is used. For this to happen we need to set some information when SWPipeline is getting initialized and pass that information to glass.
> 
> This PR adds new flag `useMTLInGlass` in device details when SWPipeline is getting initialized and then passes it to glass code. When SWPipeline is used, based on this flag we will use appropriate hardware pipeline in glass.
> 
> Patch is tested when useMTLInGlass is set to true/false and then using -Dprism.order=es2/mtl/sw and it picks proper GlassView/Layer.

This pull request has now been integrated.

Changeset: f8f466f9
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f8f466f9038b02b1e100cccf25a9ba58e7a06157
Stats:     88 lines in 9 files changed: 58 ins; 16 del; 14 mod

8350479: SW pipeline should use default pipeline in Glass

Reviewed-by: kcr, arapte

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

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

From nlisker at gmail.com  Tue Aug 19 04:26:22 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 19 Aug 2025 07:26:22 +0300
Subject: null parameter constructors in StringConverters
In-Reply-To: <2ea6791d-70e7-4d14-89cd-a28f4ba6adeb@oracle.com>
References: <CA+0ynh-tjJ5DjKPiNkDEBO4xDD144YQrg+t3QpQewZZabM7Vqg@mail.gmail.com>
 <b8c86592-fe96-4595-a045-214c7e46ccef@gmail.com>
 <CA+0ynh_7tkjwNr0uSCj+4HnXmKVDv=hjm4MJkcPxo9ZQ3ZNNdQ@mail.gmail.com>
 <d97fd27e-2269-4adc-9cea-d472b149c5f8@gmail.com>
 <CA+0ynh9X3UY2RFnpOLPyYOHw3OPC8SND-G2wFeg9_psrYCa1HQ@mail.gmail.com>
 <07b4544f-585d-4f04-bc09-7a681299e682@gmail.com>
 <2ea6791d-70e7-4d14-89cd-a28f4ba6adeb@oracle.com>
Message-ID: <CA+0ynh_G+0MSjaBvD3PjTugv83Nx5SrTu1VFnyy5VZszGWg32w@mail.gmail.com>

Alright, I'll document the current behavior.

On Tue, Aug 19, 2025 at 1:43?AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I am not sure it is worth changing the behavior either. It allowing null
> were ambiguous (or harmful), then it might be worth it. As it is, it seems
> better to just document the current behavior.
>
> -- Kevin
>
>
> On 8/18/2025 2:34 PM, John Hendrikx wrote:
>
> I think it may come down to whether rejecting `null` would be helpful for
> users of these constructors to find problems in their code.  I agree that
> the DateTimeStringConverter is not really a chained constructor with a
> clear (and public) master constructor that is documented to allow `null`
> for certain defaults.  It is more a style of programming used throughout FX
> to provide many constructors (Image is also like that) instead of a Builder
> or static factory method.
>
> I could make arguments that it would make programmatic use easier, but
> that never stopped me from rejecting nulls in my own code.  Callers then
> should just pick their own defaults, like:
>
>        new DateTimeConverter(locale == null ? Locale.DEFAULT : locale,
> pattern == null ? "ddMMyy" : pattern)
>
> Personally, I think this is not worth changing, but I do think it should
> be documented.  Rejecting nulls now will definitely require a CSR and is
> not backwards compatible :/
>
> --John
>
> On 18/08/2025 22:41, Nir Lisker wrote:
>
> But I think I see what you mean better now, for example, there is (Locale
>> locale, String pattern) and (String pattern). If you intending to pass
>> `null` as Locale, why not just use the pattern-only constructor?  I think
>> that still could make sense,
>
>
> OK, but what about `pattern` being null in either?
>
> On Mon, Aug 18, 2025 at 11:30?PM John Hendrikx <john.hendrikx at gmail.com>
> wrote:
>
>> If certain patterns make no sense, then I think the master constructor
>> should reject them (if there is one, or perhaps one should be created as a
>> private one).
>>
>> For example, if there is a width/height constructor, but I only specify
>> width and not height, then I think its fine to reject (null, height) and
>> (width, null) while accepting (null, null) and (width, height).
>>
>> But I think I see what you mean better now, for example, there is (Locale
>> locale, String pattern) and (String pattern). If you intending to pass
>> `null` as Locale, why not just use the pattern-only constructor?  I think
>> that still could make sense, especially locale is say coming from a
>> configuration file or some such.  If the constructor `null` here, then it
>> makes it easier to use it programmatically (ie. if my configuration has a
>> Locale then I pass that, if it is null, I pass that -- compare that to
>> having to check for Locale being null and then having to select the correct
>> constructor...
>>
>> --John
>>
>> On 18/08/2025 21:00, Nir Lisker wrote:
>>
>> Aren't these constructors chained?
>>
>>
>> Not all of them. There are 3 tangential creation paths for
>> DateTimeStringConverter and subclasses:
>> 1. Through dateStyle/timeStyle ints with an optional locale that creates
>> the DateFormat with `DateFormat.getDateTimeInstance(dateStyle, timeStyle,
>> locale)` (similar for subclasses). There are 4 constructors here for the
>> combinations of: none, only style(s), only locale, all.
>> 2. Through a String pattern with an optional locale that creates the
>> DateFormat with `new SimpleDateFormat(pattern, locale)`. If pattern is
>> null, it uses path 1 above with default styles and the optional locale. If
>> you wanted to use a pattern to create this converter, passing null makes
>> little sense. It could be surprising to get a "defaults" converter when you
>> intended to customize the format with your own pattern to begin with. I
>> imagine that if you couldn't get a pattern, you'd use your own int styles
>> as a replacement.
>> 3. Through a DateFormat that is used directly. If it's null, it checks if
>> the pattern is null (which it will always be), in which case it uses the
>> defaults of path 1 again (with the default locale since it's not optional
>> here). I find it odd here too to pass null and rely on the
>> "defaults" converter.
>>
>> NumberStringConverter and its subclasses are similar. They have path 2
>> with 4 combinations: none, only pattern, and locale, and both. And they
>> also have path 3 that falls on the default if null.
>>
>> On Mon, Aug 18, 2025 at 9:06?PM John Hendrikx <john.hendrikx at gmail.com>
>> wrote:
>>
>>> Aren't these constructors chained?  I believe it is quite common
>>> practice to use nulls when calling a chained constructor to get a default
>>> for that parameter.  If a certain type of convenience constructor is
>>> missing, a caller can pass in `null` for the parameter they'd like
>>> defaulted.  It's not too far-fetched to allow this **if** there is a
>>> constructor where this parameter is omitted and is assigned a default.
>>>
>>> If anything, the constructors IMHO should document that for certain
>>> parameters passing in `null` results in a specific default.
>>>
>>> --John
>>> On 18/08/2025 19:46, Nir Lisker wrote:
>>>
>>> Hi all,
>>>
>>> In DateTimeStringConverter, NumberStringConverter, and their subclasses,
>>> null parameters sent to the constructors are internally converted to
>>> default values. This is not specified, but it's how the implementation
>>> behaves. I'm working on some changes there and was thinking about changing
>>> the behavior to throw NPEs as it makes no sense to pass null into these and
>>> it's probably a bug more than anything.
>>>
>>> The LocalDate/Time converters specified the null-friendly behavior in
>>> their docs even though it doesn't make much sense there either.
>>>
>>> Are we allowed to change this?
>>>
>>> - Nir
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250819/49781b0d/attachment-0001.htm>

From arapte at openjdk.org  Tue Aug 19 06:58:20 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Aug 2025 06:58:20 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
Message-ID: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>

On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
This is done to get more testing of the Metal pipeline.
If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.

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

Commit messages:
 - 8365576: Temporarily make Metal the default JavaFX rendering pipeline for macOS

Changes: https://git.openjdk.org/jfx/pull/1876/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1876&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365576
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1876.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1876/head:pull/1876

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

From arapte at openjdk.org  Tue Aug 19 08:16:09 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Aug 2025 08:16:09 GMT
Subject: RFR: 8365763: Update copyright header for files modified in 2025
Message-ID: <_QOb8JypxcYWCMAkH9fwRUKzKdfIlCV2n7OqhVE3Mag=.36dfaaa8-97b0-4667-b25d-107d393ec520@github.com>

Update copyright year in files updated in the year 2025.

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

Commit messages:
 - copy year 2025 in 08

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

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

From arapte at openjdk.org  Tue Aug 19 08:16:09 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Aug 2025 08:16:09 GMT
Subject: RFR: 8365763: Update copyright header for files modified in 2025
In-Reply-To: <_QOb8JypxcYWCMAkH9fwRUKzKdfIlCV2n7OqhVE3Mag=.36dfaaa8-97b0-4667-b25d-107d393ec520@github.com>
References: <_QOb8JypxcYWCMAkH9fwRUKzKdfIlCV2n7OqhVE3Mag=.36dfaaa8-97b0-4667-b25d-107d393ec520@github.com>
Message-ID: <_XS8pKqEKYdftauMJ0nuKlSngSOR5d5h_GkSanV-3d4=.6db7c6d5-c8c5-470d-b7a9-ba0d243df0dd@github.com>

On Tue, 19 Aug 2025 08:11:08 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in the year 2025.

@kevinrushforth Please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1877#issuecomment-3199713011

From jdv at openjdk.org  Tue Aug 19 08:24:57 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 19 Aug 2025 08:24:57 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
In-Reply-To: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
References: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
Message-ID: <DDUsuQDicZyNUPVQE-3tkmzKe0uVrAqdbJg8SEbNWiM=.bfca458c-9bd0-4551-8d71-8513139de722@github.com>

On Tue, 19 Aug 2025 06:52:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
> This is done to get more testing of the Metal pipeline.
> If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1876#pullrequestreview-3131256624

From arapte at openjdk.org  Tue Aug 19 08:24:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 19 Aug 2025 08:24:58 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
In-Reply-To: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
References: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
Message-ID: <vmWe3a_qHWOncNTJrxZforBQ5r9cDIo8a1mjFdq3-Zc=.87f45cbc-f0ed-4407-9c4f-c86c1d8ef11e@github.com>

On Tue, 19 Aug 2025 06:52:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
> This is done to get more testing of the Metal pipeline.
> If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.

@kevinrushforth Please take a look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1876#issuecomment-3199741942

From kcr at openjdk.org  Tue Aug 19 11:38:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Aug 2025 11:38:44 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
In-Reply-To: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
References: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
Message-ID: <myrf7HRoDKLeL45ejtZfj8OuppXk4dnI9Ddjibi3OXY=.996bb3a3-17a9-4204-9b88-ad827e1bb2ee@github.com>

On Tue, 19 Aug 2025 06:52:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
> This is done to get more testing of the Metal pipeline.
> If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.

LGTM

Please wait until the PR has been out for 24 hours to give others a chance to comment or review.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1876#pullrequestreview-3131918500

From kcr at openjdk.org  Tue Aug 19 12:18:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Aug 2025 12:18:42 GMT
Subject: RFR: 8365763: Update copyright header for files modified in 2025
In-Reply-To: <_QOb8JypxcYWCMAkH9fwRUKzKdfIlCV2n7OqhVE3Mag=.36dfaaa8-97b0-4667-b25d-107d393ec520@github.com>
References: <_QOb8JypxcYWCMAkH9fwRUKzKdfIlCV2n7OqhVE3Mag=.36dfaaa8-97b0-4667-b25d-107d393ec520@github.com>
Message-ID: <cB4ReC72Z-YxcgcoT-tDxlYFodPxPDSUvz8aVlHw7tQ=.6635a22b-a600-4763-af03-babbc237c6e2@github.com>

On Tue, 19 Aug 2025 08:11:08 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Update copyright year in files updated in the year 2025.

LGTM

For this simple change, a single reviewer is sufficient. Also, I waive the usual 24 hour waiting period, since this is a simple cleanup PR, which was generated by a script that has been well-tested.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1877#pullrequestreview-3132064062

From angorya at openjdk.org  Tue Aug 19 15:18:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 19 Aug 2025 15:18:52 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
In-Reply-To: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
References: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
Message-ID: <PBRuR7WXwF9gfiGWniGMLyOPBhW01VkB71LscL5lMSs=.a04f1668-a765-4068-99aa-39f0643301ba@github.com>

On Tue, 19 Aug 2025 06:52:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
> This is done to get more testing of the Metal pipeline.
> If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.

modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java line 208:

> 206:             tryOrderArr = new String[] { "d3d", "sw" };
> 207:         } else if (PlatformUtil.isMac()) {
> 208:             tryOrderArr = new String[] { "mtl", "es2", "sw" };

perhaps add a comment here and refer to a follow-up issue to undo this change?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1876#discussion_r2285591108

From kcr at openjdk.org  Tue Aug 19 15:39:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 19 Aug 2025 15:39:46 GMT
Subject: RFR: 8365576: Temporarily make Metal the default JavaFX rendering
 pipeline for macOS
In-Reply-To: <PBRuR7WXwF9gfiGWniGMLyOPBhW01VkB71LscL5lMSs=.a04f1668-a765-4068-99aa-39f0643301ba@github.com>
References: <KsDRQWKBE0Pn900WjZBeAa0FmXayqD3fXMcD4RjBsMg=.474bbbe8-d0e5-4f90-8c60-fc2b959d5259@github.com>
 <PBRuR7WXwF9gfiGWniGMLyOPBhW01VkB71LscL5lMSs=.a04f1668-a765-4068-99aa-39f0643301ba@github.com>
Message-ID: <OT4nLrJyxorgaGMfvrVMzddd7l2W7qKx1o-5GeAHIg4=.14af26a4-d2f0-4ca5-b47b-e8f80d1dc5a7@github.com>

On Tue, 19 Aug 2025 15:15:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> On macOS, temporarily set the default rendering pipeline to Metal, for the next ~7 weeks (until Oct 2).
>> This is done to get more testing of the Metal pipeline.
>> If you need to use the ES2 pipeline, add **-Dprism.order=es2** option to the Java command.
>
> modules/javafx.graphics/src/main/java/com/sun/prism/impl/PrismSettings.java line 208:
> 
>> 206:             tryOrderArr = new String[] { "d3d", "sw" };
>> 207:         } else if (PlatformUtil.isMac()) {
>> 208:             tryOrderArr = new String[] { "mtl", "es2", "sw" };
> 
> perhaps add a comment here and refer to a follow-up issue to undo this change?

Given that this is intended to be temporary, that's a good idea. It will help anyone looking at it to know that it will be reverted soon.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1876#discussion_r2285648632