From john.hendrikx at gmail.com  Tue Jul  1 02:00:18 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 1 Jul 2025 04:00:18 +0200
Subject: JFX25: TableView + col.setMaxWidth() now clipping column headers
In-Reply-To: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
References: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
Message-ID: <979949ea-6e1f-407d-b72a-0cb80ce0e078@gmail.com>

Hi Cormac,

That definitely looks like a bug.? Setting the maximum constraint should
not have that effect.? The documentation describes what you'd expect and
does not allude to the odd side effects you are seeing.

Some work was done recently on the resizing of table columns, perhaps a
regression was introduced there.

--John

On 29/06/2025 01:41, Cormac Redmond wrote:
> Hi,
>
> While testing JFX25 (on Windows), previously perfectly-sized column
> sizes are now "too small", hiding parts of the column header.
>
> Code to reproduce:
>
> public class TableViewColSizeBug extends Application {
>
> ? ? @Override
> ? ? public void start(Stage stage) {
> ? ? ? ? TableView<String> table = new TableView<>();
> ? ? ? ? TableColumn<String, String> col1 = new TableColumn<>();
> ? ? ? ? col1.setGraphic(new Text("Column One (... ...)"));
>
> ? ? ? ?
> table.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN);
>
> ? ? ? ? // Setting a max width causes a "too small" column size
> ? ? ? ? col1.setMaxWidth(500); // Note large param
>
> ? ? ? ? table.getColumns().addAll(col1, new TableColumn<>("Col 2"),
> new TableColumn<>("Col 3"), new TableColumn<>("Col 4"), new
> TableColumn<>("Col 5"));
> ? ? ? ? stage.setScene(new Scene(new VBox(table), 600, 200));
> ? ? ? ? stage.show();
> ? ? }
>
> ? ? public static void main(String[] args) {
> ? ? ? ? launch();
> ? ? }
> }
>
> ?
> Notice the clear difference between JFX24 and JFX25 behaviour. If you
> do NOT setMaxWidth, there is no issue. For some reason, calling
> setMaxWidth, no matter how large the param, triggers this.
>
> JFX25 (as per code above, setting a column Text graphic),?col width
> too small:
> image.png
>
> JFX25 using "new TableColumn<>("Column One (... ...)")", instead of
> setting a Text graphic; col width also too small:
> image.png
>
> JFX25 when you do NOT do setMaxWidth(...),?looks fine:
>
> image.png
> JFX24 (in all instances, looks fine):
> image.png
>
> Is this a bug?
>
>
> Kind Regards,
> Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11186 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9817 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10133 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13967 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/657760bb/image-0007.png>

From lkostyra at openjdk.org  Tue Jul  1 10:56:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 1 Jul 2025 10:56:53 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
Message-ID: <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>

On Mon, 30 Jun 2025 16:58:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes; rewrite test to extend VisualTestBase
>
> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 118:
> 
>> 116:         Util.runAndWait(() -> {
>> 117:             Color color = getColor(STAGE_SIZE / 2, STAGE_SIZE / 2);
>> 118:             assertColorEquals(Color.LIGHTGREEN, color, TOLERANCE);
> 
> I wonder if this implementation is a reliable test: the stage in question may be overlapped by another window somewhere in the corner, right?
> 
> What would be a reliable test?  Strictly speaking, we must check every pixel in the scene, though I wonder if checking each pixel in a grid (maybe 20 x 20, since we don't expect any reasonable window to be less than that) should be enough?

The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2177242492

From angorya at openjdk.org  Tue Jul  1 15:13:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 1 Jul 2025 15:13:49 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
Message-ID: <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>

On Tue, 1 Jul 2025 10:54:16 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 118:
>> 
>>> 116:         Util.runAndWait(() -> {
>>> 117:             Color color = getColor(STAGE_SIZE / 2, STAGE_SIZE / 2);
>>> 118:             assertColorEquals(Color.LIGHTGREEN, color, TOLERANCE);
>> 
>> I wonder if this implementation is a reliable test: the stage in question may be overlapped by another window somewhere in the corner, right?
>> 
>> What would be a reliable test?  Strictly speaking, we must check every pixel in the scene, though I wonder if checking each pixel in a grid (maybe 20 x 20, since we don't expect any reasonable window to be less than that) should be enough?
>
> The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.

I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2177865033

From andy.goryachev at oracle.com  Tue Jul  1 16:40:17 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 16:40:17 +0000
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage
 via Software Renderer
In-Reply-To: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
Message-ID: <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

The devil is in detail, but I like this proposal very much, especially if most of the machinery is already there.

How would it work if one does enable the software pipeline?  Or the headless platform?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Friday, June 27, 2025 at 03:15
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

Hi list,

I'm exploring whether there is interest in exposing a (Canvas) GraphicsContext-like interface for WritableImage backed by the existing software rendering pipeline.  Currently, JavaFX offers two main choices for drawing and pixel manipulation, each with different trade-offs:

- Canvas provides rich drawing primitives via GraphicsContext, but offers no direct pixel access?requiring costly GPU readbacks (e.g., snapshot()).
- WritableImage, on the other hand, allows direct pixel manipulation via PixelReader/PixelWriter, but has no built-in support for drawing operations like shapes, fills, or blending.

My proposal would combine the strengths of both:

- Expose drawing operations (shapes, fills, etc.) for WritableImage
- Direct access to image data before or after rendering without GPU readbacks / snapshots
- Reuse of JavaFX?s software rendering stack (SWGraphics, PiscesRenderer, etc.) without activating the software pipeline globally

I?ve successfully tested this approach in a non-modular FX application by accessing internal APIs from com.sun.prism.sw. With minor adjustments (--add-exports), it may also work in modular environments.

Work needed to support this as a public API might include:

- Creating a new GraphicsContext-like interface ("DrawingContext" ?)
- Exposing a method on WritableImage to obtain such a context
- Optionally, refactoring Canvas' GraphicsContext to implement this new interface (method signatures are likely compatible)
- Implementing the new interface on top of the software renderer

See the end of the post for a working example (assuming you place the code in the "com.sun.prism.sw" package and deal with the module restrictions).  Note that you do not need to enable the software pipeline (and you don't want to either, as the whole point is to remain GPU accelerated but have software renderer backed drawing primitives for images).

Any feedback appreciated!

--John

package com.sun.prism.sw;

import com.sun.glass.ui.Screen;

import com.sun.glass.utils.NativeLibLoader;

import com.sun.pisces.JavaSurface;

import com.sun.pisces.PiscesRenderer;

import com.sun.pisces.RendererBase;

import com.sun.prism.paint.Color;

import java.nio.IntBuffer;

import javafx.application.Application;

import javafx.scene.Scene;

import javafx.scene.image.ImageView;

import javafx.scene.image.PixelWriter;

import javafx.scene.image.WritableImage;

import javafx.scene.layout.StackPane;

import javafx.stage.Stage;

public class SWRendererExample {

static {

NativeLibLoader.loadLibrary("prism_sw");

}

public static void main(String[] args) {

Application.launch(App.class);

}

public static class App extends Application {

@Override

public void start(Stage primaryStage) {

WritableImage writableImage = createImageWithSWPipeline();

Scene scene = new Scene(new StackPane(new ImageView(writableImage)));

primaryStage.setScene(scene);

primaryStage.show();

}

}

public static WritableImage createImageWithSWPipeline() {

int width = 400;

int height = 300;

SWResourceFactory resourceFactory = new SWResourceFactory(Screen.getMainScreen());

SWRTTexture texture = new SWRTTexture(resourceFactory, width, height);

SWContext swContext = new SWContext(resourceFactory);

// Set up a surface to draw on and create the renderer:

int[] backingArray = new int[width * height];

IntBuffer pixelBuffer = IntBuffer.wrap(backingArray);

JavaSurface surface = new JavaSurface(backingArray, RendererBase.TYPE_INT_ARGB_PRE, width, height);

PiscesRenderer renderer = new PiscesRenderer(surface);

// Create SWGraphics for drawing (software renderer)

SWGraphics swGraphics = new SWGraphics(texture, swContext, renderer);

swGraphics.clear(Color.WHITE);

swGraphics.setPaint(Color.BLUE);

swGraphics.fillRect(50, 50, 100, 100);

swGraphics.setPaint(Color.RED);

swGraphics.fillEllipse(75, 75, 10, 20);

// Take the result and place it in a writable image:

WritableImage writableImage = new WritableImage(width, height);

PixelWriter pw = writableImage.getPixelWriter();

pw.setPixels(0, 0, width, height, javafx.scene.image.PixelFormat.getIntArgbPreInstance(), pixelBuffer.array(), 0, width);

return writableImage;

}

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

From john.hendrikx at gmail.com  Tue Jul  1 17:36:27 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 1 Jul 2025 19:36:27 +0200
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage
 via Software Renderer
In-Reply-To: <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
 <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>

If you enable the software pipeline, that would not change anything,
apart from the libraries already being loaded and the software renderer
being used more often. The renderer used in the example would be
independent and so it would not interfere.

As far as the headless platform goes, if it allows for the software
pipeline to be loaded, then this code should function as well as the
Pisces renderer used here is pure Java.? A mock Screen may need to be
provided.? I'm not well-versed currently in the specifics of the
headless platform.? Perhaps somebody working on it could comment?

--John


On 01/07/2025 18:40, Andy Goryachev wrote:
>
> The devil is in detail, but I like this proposal very much, especially
> if most of the machinery is already there.?
>
> ?
>
> How would it work if one does enable the software pipeline?? Or the
> headless platform?
>
> ?
>
> -andy
>
> ?
>
> ?
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John
> Hendrikx <john.hendrikx at gmail.com>
> *Date: *Friday, June 27, 2025 at 03:15
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Proposal: Exposing a GraphicsContext-like API for
> WritableImage via Software Renderer
>
> Hi list,
>
> I'm exploring whether there is interest in exposing a (Canvas)
> GraphicsContext-like interface for WritableImage backed by the
> existing software rendering pipeline.? Currently, JavaFX offers two
> main choices?for drawing and pixel manipulation, each with different
> trade-offs:
>
> - Canvas provides rich drawing primitives via GraphicsContext, but
> offers no direct pixel access?requiring costly GPU readbacks (e.g.,
> snapshot()).
> - WritableImage, on the other hand, allows direct pixel manipulation
> via PixelReader/PixelWriter, but has no built-in support for drawing
> operations like shapes, fills, or blending.
>
> My proposal would combine the strengths of both:
>
> - Expose drawing operations (shapes, fills, etc.) for WritableImage?
> - Direct access to image data before or after rendering without GPU
> readbacks / snapshots
> - Reuse of JavaFX?s software rendering stack (SWGraphics,
> PiscesRenderer, etc.) without activating the software pipeline globally
>
> I?ve successfully tested this approach in a non-modular FX application
> by accessing internal APIs from com.sun.prism.sw. With minor
> adjustments (--add-exports), it may also work in modular environments.
>
> Work needed to support this as a public API might include:
>
> - Creating a new GraphicsContext-like interface ("DrawingContext" ?)
> - Exposing a method on WritableImage to obtain such a context
> - Optionally, refactoring Canvas' GraphicsContext to implement this
> new interface (method signatures are likely compatible)
> - Implementing the new interface on top of the software renderer
>
> See the end of the post for?a working example (assuming you place the
> code in the "com.sun.prism.sw" package and deal with the module
> restrictions).? Note that you do not need to enable the software
> pipeline (and you don't want to either, as the whole point is to
> remain GPU accelerated but have software renderer backed drawing
> primitives for images).
>
> Any feedback appreciated!
>
> --John
>
> *package*com.sun.prism.sw;
>
> *import*com.sun.glass.ui.Screen;
>
> *import*com.sun.glass.utils.NativeLibLoader;
>
> *import*com.sun.pisces.JavaSurface;
>
> *import*com.sun.pisces.PiscesRenderer;
>
> *import*com.sun.pisces.RendererBase;
>
> *import*com.sun.prism.paint.Color;
>
> *import*java.nio.IntBuffer;
>
> *import*javafx.application.Application;
>
> *import*javafx.scene.Scene;
>
> *import*javafx.scene.image.ImageView;
>
> *import*javafx.scene.image.PixelWriter;
>
> *import*javafx.scene.image.WritableImage;
>
> *import*javafx.scene.layout.StackPane;
>
> *import*javafx.stage.Stage;
>
> *public**class*SWRendererExample {
>
> *static*{
>
> NativeLibLoader./loadLibrary/("prism_sw");
>
> }
>
> *public**static**void*main(String[] args) {
>
> Application./launch/(App.*class*);
>
> }
>
> *public**static**class*App *extends*Application {
>
> @Override
>
> *public**void*start(Stage primaryStage) {
>
> WritableImage writableImage = /createImageWithSWPipeline/();
>
> Scene scene = *new*Scene(*new*StackPane(*new*ImageView(writableImage)));
>
> primaryStage.setScene(scene);
>
> primaryStage.show();
>
> }
>
> }
>
> *public**static*WritableImage createImageWithSWPipeline() {
>
> *int*width = 400;
>
> *int*height = 300;
>
> SWResourceFactory resourceFactory =
> *new*SWResourceFactory(Screen./getMainScreen/());
>
> SWRTTexture texture = *new*SWRTTexture(resourceFactory, width, height);
>
> SWContext swContext = *new*SWContext(resourceFactory);
>
> // Set up a surface to draw on and create the renderer:
>
> *int*[] backingArray = *new**int*[width * height];
>
> IntBuffer pixelBuffer = IntBuffer./wrap/(backingArray);
>
> JavaSurface surface = *new*JavaSurface(backingArray,
> RendererBase.TYPE_INT_ARGB_PRE, width, height);
>
> PiscesRenderer renderer = *new*PiscesRenderer(surface);
>
> // Create SWGraphics for drawing (software renderer)
>
> SWGraphics swGraphics = *new*SWGraphics(texture, swContext, renderer);
>
> swGraphics.clear(Color.WHITE);
>
> swGraphics.setPaint(Color.BLUE);
>
> swGraphics.fillRect(50, 50, 100, 100);
>
> swGraphics.setPaint(Color.RED);
>
> swGraphics.fillEllipse(75, 75, 10, 20);
>
> // Take the result and place it in a writable image:
>
> WritableImage writableImage = *new*WritableImage(width, height);
>
> PixelWriter pw = writableImage.getPixelWriter();
>
> pw.setPixels(0, 0, width, height,
> javafx.scene.image.PixelFormat./getIntArgbPreInstance/(),
> pixelBuffer.array(), 0, width);
>
> *return*writableImage;
>
> }
>
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/ced6ba53/attachment-0001.htm>

From andy.goryachev at oracle.com  Tue Jul  1 17:48:40 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 17:48:40 +0000
Subject: [External] : Re: Proposal: Exposing a GraphicsContext-like API
 for WritableImage via Software Renderer
In-Reply-To: <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>
References: <b5c482f4-69ac-4895-8b38-8ab8a6a0c295@gmail.com>
 <CY8PR10MB72655335B8AD0CD6FC2D2BD4E541A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <57cad8a4-7b2a-4664-9b6a-2445056db0fa@gmail.com>
Message-ID: <CY8PR10MB7265A761E545C4A8006D3314E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

There is currently a POC PR https://github.com/openjdk/jfx/pull/1836 for headless, so it might be relatively easy to check.

-andy

From: John Hendrikx <john.hendrikx at gmail.com>
Date: Tuesday, July 1, 2025 at 10:36
To: Andy Goryachev <andy.goryachev at oracle.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

If you enable the software pipeline, that would not change anything, apart from the libraries already being loaded and the software renderer being used more often. The renderer used in the example would be independent and so it would not interfere.

As far as the headless platform goes, if it allows for the software pipeline to be loaded, then this code should function as well as the Pisces renderer used here is pure Java.  A mock Screen may need to be provided.  I'm not well-versed currently in the specifics of the headless platform.  Perhaps somebody working on it could comment?

--John


On 01/07/2025 18:40, Andy Goryachev wrote:
The devil is in detail, but I like this proposal very much, especially if most of the machinery is already there.

How would it work if one does enable the software pipeline?  Or the headless platform?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com><mailto:john.hendrikx at gmail.com>
Date: Friday, June 27, 2025 at 03:15
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Proposal: Exposing a GraphicsContext-like API for WritableImage via Software Renderer

Hi list,

I'm exploring whether there is interest in exposing a (Canvas) GraphicsContext-like interface for WritableImage backed by the existing software rendering pipeline.  Currently, JavaFX offers two main choices for drawing and pixel manipulation, each with different trade-offs:

- Canvas provides rich drawing primitives via GraphicsContext, but offers no direct pixel access?requiring costly GPU readbacks (e.g., snapshot()).
- WritableImage, on the other hand, allows direct pixel manipulation via PixelReader/PixelWriter, but has no built-in support for drawing operations like shapes, fills, or blending.

My proposal would combine the strengths of both:

- Expose drawing operations (shapes, fills, etc.) for WritableImage
- Direct access to image data before or after rendering without GPU readbacks / snapshots
- Reuse of JavaFX?s software rendering stack (SWGraphics, PiscesRenderer, etc.) without activating the software pipeline globally

I?ve successfully tested this approach in a non-modular FX application by accessing internal APIs from com.sun.prism.sw. With minor adjustments (--add-exports), it may also work in modular environments.

Work needed to support this as a public API might include:

- Creating a new GraphicsContext-like interface ("DrawingContext" ?)
- Exposing a method on WritableImage to obtain such a context
- Optionally, refactoring Canvas' GraphicsContext to implement this new interface (method signatures are likely compatible)
- Implementing the new interface on top of the software renderer

See the end of the post for a working example (assuming you place the code in the "com.sun.prism.sw" package and deal with the module restrictions).  Note that you do not need to enable the software pipeline (and you don't want to either, as the whole point is to remain GPU accelerated but have software renderer backed drawing primitives for images).

Any feedback appreciated!

--John

package com.sun.prism.sw;

import com.sun.glass.ui.Screen;

import com.sun.glass.utils.NativeLibLoader;

import com.sun.pisces.JavaSurface;

import com.sun.pisces.PiscesRenderer;

import com.sun.pisces.RendererBase;

import com.sun.prism.paint.Color;

import java.nio.IntBuffer;

import javafx.application.Application;

import javafx.scene.Scene;

import javafx.scene.image.ImageView;

import javafx.scene.image.PixelWriter;

import javafx.scene.image.WritableImage;

import javafx.scene.layout.StackPane;

import javafx.stage.Stage;

public class SWRendererExample {

static {

NativeLibLoader.loadLibrary("prism_sw");

}

public static void main(String[] args) {

Application.launch(App.class);

}

public static class App extends Application {

@Override

public void start(Stage primaryStage) {

WritableImage writableImage = createImageWithSWPipeline();

Scene scene = new Scene(new StackPane(new ImageView(writableImage)));

primaryStage.setScene(scene);

primaryStage.show();

}

}

public static WritableImage createImageWithSWPipeline() {

int width = 400;

int height = 300;

SWResourceFactory resourceFactory = new SWResourceFactory(Screen.getMainScreen());

SWRTTexture texture = new SWRTTexture(resourceFactory, width, height);

SWContext swContext = new SWContext(resourceFactory);

// Set up a surface to draw on and create the renderer:

int[] backingArray = new int[width * height];

IntBuffer pixelBuffer = IntBuffer.wrap(backingArray);

JavaSurface surface = new JavaSurface(backingArray, RendererBase.TYPE_INT_ARGB_PRE, width, height);

PiscesRenderer renderer = new PiscesRenderer(surface);

// Create SWGraphics for drawing (software renderer)

SWGraphics swGraphics = new SWGraphics(texture, swContext, renderer);

swGraphics.clear(Color.WHITE);

swGraphics.setPaint(Color.BLUE);

swGraphics.fillRect(50, 50, 100, 100);

swGraphics.setPaint(Color.RED);

swGraphics.fillEllipse(75, 75, 10, 20);

// Take the result and place it in a writable image:

WritableImage writableImage = new WritableImage(width, height);

PixelWriter pw = writableImage.getPixelWriter();

pw.setPixels(0, 0, width, height, javafx.scene.image.PixelFormat.getIntArgbPreInstance(), pixelBuffer.array(), 0, width);

return writableImage;

}

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

From andy.goryachev at oracle.com  Tue Jul  1 21:43:14 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 1 Jul 2025 21:43:14 +0000
Subject: FW: [External] : Re: JFX25: TableView + col.setMaxWidth() now
 clipping column headers
In-Reply-To: <CY8PR10MB72653E6F289133BF76FB42AEE541A@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAG_-AaA6Qv70Fs8w-b5yay1BJ6U3TZ2K9ARKmegMFE4iVL2Tcg@mail.gmail.com>
 <CY8PR10MB726586A13E859913DCD45BD6E546A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaDwVYS8QM--Baqhnpf2asRzw_Ba4R_-P_aScRJizyCS0Q@mail.gmail.com>
 <CY8PR10MB72657F7D8093F6C43F18922EE546A@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaAwNoD_9WPYmDnzYgjNb5a1a=GDqj2gBq5M75uxiwvuZQ@mail.gmail.com>
 <CY8PR10MB72653E6F289133BF76FB42AEE541A@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CY8PR10MB7265DF775A11AA580E711D33E541A@CY8PR10MB7265.namprd10.prod.outlook.com>

Didn't realize I replied to a direct message.  Re-posting to the mailing list.

-andy



From: Andy Goryachev <andy.goryachev at oracle.com>
Date: Tuesday, July 1, 2025 at 09:25
To: Cormac Redmond <credmond at certak.com>
Subject: Re: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
You and John are right: this is a bug.  Setting the max width should not impact the distribution of extra space, unless the column hits the constraint.

Created https://bugs.openjdk.org/browse/JDK-8361210

Thanks!
-andy


From: Cormac Redmond <credmond at certak.com>
Date: Monday, June 30, 2025 at 19:35
To: Andy Goryachev <andy.goryachev at oracle.com>
Subject: Re: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
Thanks for the details, Andy.

Generally speaking, it seems like confusing behaviour (to anyone not reading this thread), that a column header is visible normally, but suddenly isn't when specifying a maximum size. It's counter-intuitive.

And the value of that maximum size seems to have no bearing on the (small) size of the column. It's always the same: just slightly too small.

It's not a big deal for me, I'm thinking of the community.



Kind Regards,
Cormac

On Mon, 30 Jun 2025 at 23:44, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
Found the change: https://bugs.openjdk.org/browse/JDK-8299753 - I thought it went in earlier.

The resizing logic does indeed consider maximum widths (when the available space exceeds the sum of preferred widths), so the behavior is as designed.  The unexpected part comes from the fact that the rest of the columns have the maximum sizes of 5000, and that is what we see, as it distributes less space to the first column.

I would suggest to set preferred widths.  Don't know whether your application supports restoring UI settings between sessions, but that's what I do in my projects: https://github.com/andy-goryachev/AppFramework<https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework__;!!ACWV5N9M2RV99hQ!IFuNYGKCo_TFdOe3pZK4gs3O7aIckRW7RFESr_0V4PJXeWeQVExP735zJO2VoYxcIxDtAaYaIQJZQ5XGqvDM9g$>

-andy




From: Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Monday, June 30, 2025 at 14:54
To: Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: [External] : Re: JFX25: TableView + col.setMaxWidth() now clipping column headers
Hi,

Well, it's not making much sense to me.

If you set a preferred width that's "too small", it's coming up with some other size (probably the 80 you're talking about):

// col1.setPrefWidth(500);
col1.setPrefWidth(25);

[cid:ii_197c3342932cb971f165]

...but if you specify a max, the pref width is suddenly honoured:

col1.setMaxWidth(500);
col1.setPrefWidth(25);

[cid:ii_197c3342932cb971f166]

The above is JFX25.

I think I noticed this oddity in my application because I had prefWidths that were probably too small -- but JFX24 still made them fit (unbeknownst to me). JFX25 doesn't appear to do that though, whatever has changed there.

Thanks for the tips. Not sure if this is worth worrying about or not, but definitely the behaviour has changed.




Kind Regards,
Cormac

On Mon, 30 Jun 2025 at 22:29, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> wrote:
When using constrained resize policy, it is better to set the preferred widths explicitly.  Otherwise, the initial distribution is a function of default preferred / maximum sizes which are, if I recall correctly, are 80 and 5000 respectively.

You can see that the first column has shrunk because of the change in the max width (5000 -> 500).  I am not entirely sure why setting the max width of one column has such an effect, it is certainly not used for initiali allocation except to limit the width, which is not the case in the screenshots provided.

What happens when you set the preferred width for the columns?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>>
Date: Saturday, June 28, 2025 at 16:42
To: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: JFX25: TableView + col.setMaxWidth() now clipping column headers
Hi,

While testing JFX25 (on Windows), previously perfectly-sized column sizes are now "too small", hiding parts of the column header.

Code to reproduce:

public class TableViewColSizeBug extends Application {

    @Override
    public void start(Stage stage) {
        TableView<String> table = new TableView<>();
        TableColumn<String, String> col1 = new TableColumn<>();
        col1.setGraphic(new Text("Column One (... ...)"));

        table.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY_FLEX_LAST_COLUMN);

        // Setting a max width causes a "too small" column size
        col1.setMaxWidth(500); // Note large param

        table.getColumns().addAll(col1, new TableColumn<>("Col 2"), new TableColumn<>("Col 3"), new TableColumn<>("Col 4"), new TableColumn<>("Col 5"));
        stage.setScene(new Scene(new VBox(table), 600, 200));
        stage.show();
    }

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


Notice the clear difference between JFX24 and JFX25 behaviour. If you do NOT setMaxWidth, there is no issue. For some reason, calling setMaxWidth, no matter how large the param, triggers this.

JFX25 (as per code above, setting a column Text graphic), col width too small:
[cid:ii_197c3342932cb971f162]

JFX25 using "new TableColumn<>("Column One (... ...)")", instead of setting a Text graphic; col width also too small:
[cid:ii_197c3342932cb971f163]

JFX25 when you do NOT do setMaxWidth(...), looks fine:

[cid:ii_197c3342932cb971f164]
JFX24 (in all instances, looks fine):
[cid:ii_197c3342932cb971f161]

Is this a bug?


Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13967 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11186 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9817 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10133 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2827 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2194 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250701/0f5e6413/image-0011.png>

From lkostyra at openjdk.org  Wed Jul  2 06:49:51 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 06:49:51 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
 <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
Message-ID: <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>

On Tue, 1 Jul 2025 15:11:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The most reliable way would be to probably scan the whole grid, I agree... I could change this - the stage is not that big after all. Maybe even turn the stage to undecorated to make this more reliable across platforms. I expect the very edge of the Stage to be not exactly the same color, but if we leave ex. 1px margin around the edges it should still be fine. I'll play around with this and update soon.
>
> I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?

Turning the scene to undecorated would just make the math easier, without having to count in the window decorations which almost certainly would be of different color.

As for the margin thing, I had to do a bit of history searching and I came back with this old PR: https://github.com/openjdk/jfx/pull/1242

I think when writing the above my blurry memory had to recall to one of the attempts at solving this which involved just skipping the 1px margin of the Stage on HiDPI systems. I agree, it should be fine just going through the entire Stage.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2179255898

From arapte at openjdk.org  Wed Jul  2 07:53:24 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Jul 2025 07:53:24 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@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:

  add @Override

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/67e06ae8..e8ac354a

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

  Stats: 6 lines in 5 files changed: 6 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  Wed Jul  2 08:05:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 2 Jul 2025 08:05:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v5]
In-Reply-To: <MFFkpcOBfFAetVA2JzTjK2IkS90knxGVYHiMEn9QoYA=.08eef53b-b245-45df-92cd-9e811cc67456@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <VqFhUWTkkd70tv7Qn-Ezs4UG7PDzXPnvYtQWVWzVUa8=.bbc9b0cf-b21b-45ef-a543-2f54aacd7858@github.com>
 <MFFkpcOBfFAetVA2JzTjK2IkS90knxGVYHiMEn9QoYA=.08eef53b-b245-45df-92cd-9e811cc67456@github.com>
Message-ID: <H5pMCLpZNJ5N9tp-gmSdl2tsOrncafH7EKGB_g2tQKc=.8bfbda68-f8f7-4b67-a884-352453c9b5bf@github.com>

On Mon, 30 Jun 2025 15:46:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The method createStockShader(String) of type DummyResourceFactory should be tagged with `@Override` since it actually overrides a superinterface method	DummyResourceFactory.java	Java Problem	/graphics/src/main/java/com/sun/prism/null3d	line 132

Thank you, added `@Override` annotation to mentioned methods.

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

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

From lkostyra at openjdk.org  Wed Jul  2 11:06:45 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 11:06:45 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v4]
In-Reply-To: <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <1CLDu2Iw5LGJ29HjcSWtQR5ZJ_cpDX4UriNdwy62jbg=.f25146b4-136e-44fd-b38f-2a931d1d517b@github.com>
 <nQvdCh_N2BgH1nZiS8g_F6yQ6_cqoT6IUU5wskoW3SM=.21fb5c3d-9c83-4db6-b728-c4c6ddcfe23f@github.com>
 <K3U21RmhFFGgi_xXVyimPPrmC6IkWdhRlrMhVq1BMvA=.b42be952-3f4e-47d3-b5b9-b1a081da029d@github.com>
 <Q4dmEXJqDAo6iDycK7cJmc3wVjUoB9a3gh92hCfxkgo=.fbbf9d2c-6bc4-48ef-925a-efa4d908bd31@github.com>
 <CpQKxIDgPTLWlcY_TJ1IRROm8GXL249CnMSdzjNRyBw=.dcd72fbf-8ada-47cd-9bcc-cbb3a215c9a2@github.com>
Message-ID: <_cT7hbhKBnVB7igGurT_tYoomS-V3xJOmzxsgvA9IKE=.e1d7930f-de8a-467e-8b6c-e04ab105a7be@github.com>

On Wed, 2 Jul 2025 06:47:22 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> I thought about that too - but why wouldn't the client area, the scene itself, be of different color?  The decorations and possible effects should be outside of the stage, shouldn't they?
>
> Turning the scene to undecorated would just make the math easier, without having to count in the window decorations which almost certainly would be of different color.
> 
> As for the margin thing, I had to do a bit of history searching and I came back with this old PR: https://github.com/openjdk/jfx/pull/1242
> 
> I think when writing the above my blurry memory recalled one of the attempts at solving this which involved just skipping the 1px margin of the Stage on HiDPI systems. I agree, it should be fine just going through the entire Stage.

Actually a small correction, using `VisualTestBase` already assumes the Stage we get is undecorated. So no changes need to be made there.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2179768493

From lkostyra at openjdk.org  Wed Jul  2 12:58:30 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 2 Jul 2025 12:58:30 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Expand check for whether Stage is on top

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/2df8fe80..32a97c24

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

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

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

From angorya at openjdk.org  Wed Jul  2 14:53:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 14:53:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <oyGtZYsfnpCUMLUw_-bFad9V9WrsG9dUH6p0pgSL3BM=.0307ea9f-af8e-4f7e-808f-9a4235fa531d@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Still getting the exception loading "msl/jfxshaders.metallib".  I am running in eclipse, so perhaps the eclipse project files need to include some added paths?  I've got a few of them in the workspace:
![Screenshot 2025-07-02 at 07 50 49](https://github.com/user-attachments/assets/c32df879-e4f7-4e12-a130-9822069774e2)

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

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

From angorya at openjdk.org  Wed Jul  2 14:56:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 14:56:49 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Is `mtl` a good name for the `prism.order` property?  Should it be `metal`?

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

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

From nlisker at openjdk.org  Wed Jul  2 15:00:54 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 2 Jul 2025 15:00:54 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
Message-ID: <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>

On Wed, 2 Jul 2025 14:54:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Is `mtl` a good name for the `prism.order` property? Should it be `metal`?

"mtl" is sometimes used a short for "material", which has overlapping context here. I'd prefer the explicit "metal".

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

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

From angorya at openjdk.org  Wed Jul  2 18:58:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 18:58:28 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v5]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <GKvp6VYy_w5bIZaXbPjeDjJ2FgXTjKnUVXr1ug8gzEA=.99c5b224-1002-4f69-9dc6-6f2713576124@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - api
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - seems to work
 - ... and 49 more: https://git.openjdk.org/jfx/compare/0270847b...c3842c03

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

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=04
  Stats: 589 lines in 12 files changed: 559 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  2 21:01:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 2 Jul 2025 21:01:50 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
Message-ID: <3763giTKhF2iIZSdebEXkvXLwyapCfPr0r9VzTI61dU=.f0b63724-a6c3-4385-a1dd-442c4c84a086@github.com>

On Wed, 2 Jul 2025 12:58:30 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand check for whether Stage is on top

Looks good!  Left some minor suggestions.

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 67:

> 65:     static final Color SCENE_COLOR = Color.LIGHTGREEN;
> 66: 
> 67:     private Stage theStage = null;

null is unnecessary

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 99:

> 97:                 Platform.runLater(() -> {
> 98:                     theStage.setX(STAGE_X);
> 99:                     theStage.setY(STAGE_Y);

setting Stage (x,y) coordinates in runLater makes the window jump.
it's probably better to move LL98-99 before runLater, to L96

with the robot disabled, the test fails with expected

org.opentest4j.AssertionFailedError: Event received latch timed out! Stage most probably did not have focus after showing. Some tests might fail because of this. If that is the case, try re-running the tests with '--no-daemon' flag in Gradle. ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 124:

> 122:             PixelReader captureReader = capture.getPixelReader();
> 123:             for (int x = 0; x < STAGE_SIZE; ++x) {
> 124:                 for (int y = 0; y < STAGE_SIZE; ++y) {

I was thinking of testing ever 5th or 10th pixel, but this code is fast enough.
If I quickly click on some window underneath the test window, the test correctly fails with 

org.opentest4j.AssertionFailedError: expected:rgba(144,238,144,255) but was:rgba(234,234,234,255)

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 137:

> 135:         assertTrue(
> 136:             eventReceivedLatch.await(TIMEOUT, TimeUnit.MILLISECONDS),
> 137:             "Event received latch timed out! Stage most probably did not have focus after showing. Some tests might fail because of this. " +

I'd suggest to replace "Event received latch timed out!", or re-phrase completely, maybe

"The Stage did not received the key stroke generated by Robot.  This might happen if the stage did not receive focus.  Some tests might fail because of this.
Try re-running the tests with '--no-daemon' flag in Gradle.".

or something along these lines.

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

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-2980590440
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180956422
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180948401
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180961162
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2180954317

From jvos at openjdk.org  Wed Jul  2 21:51:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 2 Jul 2025 21:51:25 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource from
 jar
Message-ID: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>

After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.

The 2 changes I made are:
1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

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

Commit messages:
 - Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks

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

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

From mfox at openjdk.org  Wed Jul  2 22:47:43 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 2 Jul 2025 22:47:43 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
Message-ID: <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>

On Wed, 2 Jul 2025 12:58:30 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand check for whether Stage is on top

I'm having an issue with this test. I can't get it to fail on my Windows 11 box but I can get other tests to fail due to focus issues.

I'm working on a system keyboard test (see attached patch for a pared down version). On my Windows 11 box the focus does not go to the stage unless I invoke the Robot mouse-click workaround. If I don't use that workaround the key event is going to the terminal window instead of the stage.

In that same environment the StageFocusTest in this PR always succeeds. I've never seen it fail. I've run these tests from both a Cygwin terminal and a MSYS2 MINGW terminal using bash and sh and StageFocusTest always passes.

I also notice that even when my test case fails the window is still on top, it just doesn't have focus. So the color testing in this PR seems unnecessary (?) Are you seeing cases where the stage is below other windows when it shows up?

[ShortcutKeyboardTest.patch](https://github.com/user-attachments/files/21026158/ShortcutKeyboardTest.patch)

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3029547784

From maw at weichi.com  Wed Jul  2 23:03:08 2025
From: maw at weichi.com (maw at weichi.com)
Date: Wed, 2 Jul 2025 19:03:08 -0400
Subject: Debugger
Message-ID: <009a01dbeba5$7ad19b90$7074d2b0$@weichi.com>

The Debugger is private. How is it to be used?

 

Marvin Wolfthal

maw at weichi.com <mailto:maw at weichi.com> 

http://www.marvinwolfthal.com <http://www.marvinwolfthal.com> 

https://www.youtube.com/@marvinwolfthal6402

 

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

From fkirmaier at openjdk.org  Thu Jul  3 07:06:46 2025
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 3 Jul 2025 07:06:46 GMT
Subject: RFR: 8359108: Mac - When Swing starts First,
 native application menu doesn't work for JavaFX
In-Reply-To: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
References: <m0JmJMV889lG-gr-F0gCyY0hfWDaIvbzrnRA24dPsGI=.50176de7-0caa-43df-bc89-96fbf34a866c@github.com>
Message-ID: <VvjXnaH3Ph60VU7SgFS3TJ9LKiIBSEEnSfg4HnwlF0c=.ef0051e9-bbb7-4309-a746-d5421fd0e050@github.com>

On Wed, 18 Jun 2025 20:58:20 GMT, Pabulaner IV <duke at openjdk.org> wrote:

> This pull request fixes the system menu bar on Mac when combining windows of Swing and JavaFX.
> 
> The first issue was to get the native menu bar working simultaneously on Swing and JavaFX, which was done by just returning always true inside the supportsSystemMenu method.
> 
> The second issue was to remove all system menu items installed by a swing window. This was fixed by checking the system menu bar every time an item is inserted or removed and removing all menu items that are not owned by JavaFX. This check is done on every insert and remove as JavaFX does not have a clear method inside the MenuBarDelegate class that could be called every time the window gets the focus.
> 
> I tested the fix with two Swing and two JavaFX windows that are run inside the same application and it works without any errors.
> 
> Co-Author: @FlorianKirmaier

The model we are trying to have here is quite simple.

**Background**
When a Window/Toolkit gets focused, it defines which menus should be shown.
This is done by removing the old menus, and adding their own.
This is basically, what the OS does, when you switch from Application A to B, just inside one process.

Actually, we only wanted to make the JavaFX menu work when Swing/AWT was started first.
But as far as we see, our solution also makes all combinations work.

**Test**
What is definitely missing, which we will add, are unit tests.
We have already investigated - there is an Apple Command line API, which allows us to read out which menus are currently shown. We will add some unit-tests, which should provide confidence that this is working reliably.

I hope these tests will improve the confidence, that this solution is correct and maintainable.

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

PR Comment: https://git.openjdk.org/jfx/pull/1835#issuecomment-3031120580

From jvos at openjdk.org  Thu Jul  3 07:22:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 3 Jul 2025 07:22:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <ICTnrwPyaIi1N5QekEztm8WftwuTZeL4yaiIg8Ux3GA=.1172d5d3-ed3f-40c6-aa12-29589c15b320@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

@sashamatveev can you review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3031162932

From lkostyra at openjdk.org  Thu Jul  3 12:36:44 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 3 Jul 2025 12:36:44 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v5]
In-Reply-To: <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <CZhrNDkZWeSRpd4e3IQ8Me8tUxlRjODFhjeRsLc5NtY=.d367d160-5659-43aa-9fa5-5b1e06a77269@github.com>
 <mwc1NHsOq-PveCv_nbmuPJyV9YFkEEzvOIBTSJcZxeY=.62617c43-2b52-46e7-9aad-858bde46f061@github.com>
Message-ID: <FvYGsRycG7hEIi48a-aXsl_lqWteM4YocpeEjjRYIgI=.5f06e9ca-ce0d-4dd9-afd5-db7c158b24db@github.com>

On Wed, 2 Jul 2025 22:45:16 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I'm having an issue with this test. I can't get it to fail on my Windows 11 box but I can get other tests to fail due to focus issues.

I started to see this problem as well while working on [JDK-8359899 (the Stage.isFocused discrepancy)](https://bugs.openjdk.org/browse/JDK-8359899). I have a suspicion that switching to VisualTestBase caused some sort of difference - VisualTestBase creates new Stages separately and doesn't take into account the primary Stage that you would get via overriding Application.start(). I noticed your test does not use VisualTestBase so it might be it.

I have not looked into a solution yet outside of the obvious - reverting to not using VisualTestBase. I will get that figured out very soon with Andy's review suggestions.

> I also notice that even when my test case fails the window is still on top, it just doesn't have focus. So the color testing in this PR seems unnecessary (?) Are you seeing cases where the stage is below other windows when it shows up?

I did have situations where the Stage would appear under currently active window, sometimes even under the terminal window that runs the test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3032101631

From arapte at openjdk.org  Thu Jul  3 12:53:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 3 Jul 2025 12:53:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <qhZE_1dBtis5sb3Dx6M7WnvkJSpqI0lVF8M7tFGt7Ts=.b2d2cbd9-f340-4334-8ed9-14704de86c38@github.com>
 <hyLIdi-MNCKWI38XLcpmIOQa0MdlQO3vpKHAqojmc98=.5e3d297f-4daa-468a-bc3e-29674925207f@github.com>
Message-ID: <VXqN-4Un8QY9FdoYbMF8NQDzTqB3Zve_2_f-DssjpWI=.44367ef1-0b4c-4c74-a565-132b3885ff1f@github.com>

On Wed, 2 Jul 2025 14:58:34 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > Is `mtl` a good name for the `prism.order` property? Should it be `metal`?
> 
> "mtl" is sometimes used a short for "material", which has overlapping context here. I'd prefer the explicit "metal".

mtl was chose because
- It aligns with our existing abbreviated names for pipelines like d3d, es2, sw
- The metal library also uses 'MTL' as prefix all metal library types like MTLDevice, MTLCommandQueue, MTLCommandBuffer and more..

I think It would feel relevant in the context of `-Dprism.order`

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

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

From angorya at openjdk.org  Thu Jul  3 14:43:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 14:43:48 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 812:

> 810:             unsigned int blockSize = -1;
> 811:             if (isRandomAccess) {
> 812:                 blockSize = locatorStream->GetCallbacks()->ReadBlock(pos, size);

would it make sense to declare a local variable for `locatorStream->GetCallbacks()` ?
or do we assume the compiler is smart enough to do that?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2182969956

From angorya at openjdk.org  Thu Jul  3 14:58:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 14:58:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <xUBJLrM0xK-tsWqvgYH7j-eETRKwUJbYf3WorASAu10=.8a030e7a-e935-4774-9d3e-36caae739ce8@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Would it be possible to come up with a system test?

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3032579681

From angorya at openjdk.org  Thu Jul  3 19:30:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 3 Jul 2025 19:30:13 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
Message-ID: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>

> Adding missing APIs related to styling the highlights with CSS:
> 
> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
> 
> 
> 
> Adds methods to the `RichParagraph.Builder`:
> 
> 
>         /**
>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addWavyUnderline(int start, int length, String ... css) {
> 
> 
> 
>         /**
>          * Adds a highlight with the specified style name(s).
>          * Use translucent colors to enable multiple highlights in the same region of text.
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addHighlight(int start, int length, String ... css) {
> 
> 
> 
> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
> 
> 
>     /**
>      * Adds a highlight of the given color to the specified range within the last paragraph,
>      * with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
> 
> 
>     /**
>      * Adds a wavy underline (typically used as a spell checker indicator)
>      * to the specified range within the last paragraph, with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into 8355774.css
 - Merge remote-tracking branch 'origin/master' into 8355774.css
 - tab
 - css

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1802/files
  - new: https://git.openjdk.org/jfx/pull/1802/files/5f1e084c..15617920

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

  Stats: 9379 lines in 126 files changed: 8187 ins; 753 del; 439 mod
  Patch: https://git.openjdk.org/jfx/pull/1802.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1802/head:pull/1802

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

From credmond at certak.com  Thu Jul  3 21:24:12 2025
From: credmond at certak.com (Cormac Redmond)
Date: Thu, 3 Jul 2025 22:24:12 +0100
Subject: Inconsistent drawing/layouts of Dialogs & show()/showAndWait()
 differences
Message-ID: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>

Hi,

I have noticed inconsistent and confusing size/layout behaviour with
Dialogs when changing min width or height (after shown).

The behaviour depends on whether changing min width/height on the Stage, or
the DialogPane itself, and whether show() or showAndWait() is used.

In summary:

   1. Set Stage mins + show()
      - no bug
   2.  Set Stage mins + showAndWait()
      - improper layout: background applies only to label (i.e., size
      before re-size), button wrong position, re-sizing window fixes the problem
   3. 3 Set DialogPane mins + show()
      - min sizes are ignored, button is visible, until it comes into
      focus, and then the button disappears, you can find it if you
resize window
      close to the mins set
   4. 4 Set DialogPane mins + showAndWait()
      - no bug

It's happening in JFX23/24/25. Note, these may seem trivial/fixable, or you
may ask "why would you do that?", but there are reasons I won't clutter the
mail with.

Anyway, it's best presented with a set of examples and code.

Re points 1 and 2 above, exact same code, except red is showAndWait() and
green is show():

[image: image.png]

Obviously, they should behave the same. Then slightly resize the red one:

[image: image.png]


Examples 3 and 4 above -- again, same code. Purple is show(), yellow is
showAndWait().

[image: image.png]

After you close the yellow dialog:

[image: image.png]

They should be the same size from the outset.



public class DialogBug extends Dialog<Boolean> {

    public DialogBug(final String s, boolean flip) {
        setTitle("Bug");
        setResizable(true);

        final DialogPane dp = getDialogPane();
        dp.setStyle(s);
        dp.getButtonTypes().add(ButtonType.CLOSE);
        dp.setContent(new Label("Content"));

        // Setting stage size causes the bug
        setOnShown(e -> {

            if (flip) {
                // Set stage sizes
                Stage st = (Stage) dp.getScene().getWindow();
                st.setMinHeight(260);
                st.setMinWidth(360);
            } else {
                // Set dialog sizes: note buttons disappear when you resize
                dp.setMinHeight(260);
                dp.setMinWidth(360);
            }
        });
    }

    public static class BugApp extends Application {
        @Override
        public void start(final Stage st) throws Exception {

            final boolean FLIP_ME = true; // make true for other bug

            if (FLIP_ME) {
                // Note: bug doesn't happen when using show() only. Stage
is fully green on show.
                new DialogBug("-fx-background-color: green;", true).show();
// NO BUG

                // showAndWait presents the bug; background not fully
drawn, button shifts on re-size
                new DialogBug("-fx-background-color: red;",
true).showAndWait(); // BUG
            } else {
                // A different type of issue: two different sizes and
button behaviour
                // Notice:
                // - same dialogs, different sizes
                // - how button in purple dialog shifts when yellow dialog
pane is closed
                new DialogBug("-fx-background-color: purple;",
false).show(); // BUG

                new DialogBug("-fx-background-color: yellow;",
false).showAndWait(); // NO BUG
            }
        }
    }
}

Thoughts?



Kind Regards,
Cormac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12215 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 8224 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12750 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2688 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250703/a0b73404/image-0007.png>

From almatvee at openjdk.org  Thu Jul  3 21:30:45 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 21:30:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

modules/javafx.media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm line 331:

> 329:         CJavaInputStreamCallbacks *callbacks = new (nothrow) CJavaInputStreamCallbacks();
> 330:         jobject jConnectionHolder = CLocator::CreateConnectionHolder(env, jLocator);
> 331:         if (callbacks == NULL) {

Missing `NULL` check for  `jConnectionHolder`. `if (callbacks == NULL || jConnectionHolder == NULL)`

If `callbacks` is not `NULL` it needs to be deleted.

modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:

> 804: 
> 805:         NSMutableData* readData = nil;
> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();

`URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183766995
PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183772092

From almatvee at openjdk.org  Thu Jul  3 21:30:46 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 21:30:46 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <RAsFSuqlNEk67q4G0SsLn-TrZ-0Q8cxLeurAxgCe6Ug=.2b9c8fd7-60d5-4172-a002-63c9d6c98d34@github.com>
Message-ID: <TDfr-nwqSStm5j5TMAewjXxqEcaiLIxFPMtKEzNqmJQ=.1e6541e5-7c9c-4623-803a-3806b86132df@github.com>

On Thu, 3 Jul 2025 14:41:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 812:
> 
>> 810:             unsigned int blockSize = -1;
>> 811:             if (isRandomAccess) {
>> 812:                 blockSize = locatorStream->GetCallbacks()->ReadBlock(pos, size);
> 
> would it make sense to declare a local variable for `locatorStream->GetCallbacks()` ?
> or do we assume the compiler is smart enough to do that?

Not sure, but do not see a need from performance point view.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2183777438

From almatvee at openjdk.org  Thu Jul  3 22:02:44 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 3 Jul 2025 22:02:44 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <1PD28xQVXVKCptksMzq11_kSJiMn75fk73Ns1xzMSkc=.f01c6758-7d26-406f-9522-5d02103d3053@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Looks good overall.
- Undo changed in `AVFMediaPlayer.mm`. There is no need for it and this code will never execute.
- Add NULL pointer check and deletion of `callbacks` if not NULL.
- Change title for issue to something like `MediaPlayer and AudioClip can crash when playing media files over "jar" and "jrt" protocols via OSXPlatform`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3033789612

From kizune at openjdk.org  Thu Jul  3 22:21:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 3 Jul 2025 22:21:52 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
Message-ID: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>

- Copyright year update;
- Introduce new function requestNodeAttribute and refactor code to use it;
- Fix some typos;
- Enable new code to handle TabPages since TabGroup was implemented;

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

Commit messages:
 - 8361379: [macos] Refactor accessibility code to retrieve attribute by name

Changes: https://git.openjdk.org/jfx/pull/1840/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361379
  Stats: 94 lines in 3 files changed: 12 ins; 54 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1840.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1840/head:pull/1840

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

From lkostyra at openjdk.org  Fri Jul  4 06:59:24 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Jul 2025 06:59:24 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:

 - Parameterize StageFocusTest
   
   This is to check if Stage showing works also for Stages other than the
   primary Stage provided by Application.start()
 - Review fixes; revert using VisualTestBase

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/32a97c24..56cdcf4b

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

  Stats: 122 lines in 1 file changed: 84 ins; 1 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1804.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1804/head:pull/1804

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

From lkostyra at openjdk.org  Fri Jul  4 07:09:42 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 4 Jul 2025 07:09:42 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
Message-ID: <vImh9FTffbdOVXrswCGNjYAR_nfBzy3K5rpSiYn__mA=.c6ea1e44-d268-4bca-8d90-db7384a95546@github.com>

On Fri, 4 Jul 2025 06:59:24 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Parameterize StageFocusTest
>    
>    This is to check if Stage showing works also for Stages other than the
>    primary Stage provided by Application.start()
>  - Review fixes; revert using VisualTestBase

I did a couple of extra changes in addition to the regular fixes:
- `extend VisualTestBase` was removed, it was indeed the cause of the test always passing. The "Windows forbids granting focus" scenario seems to only happen when we try and show the Stage provided by `Application.start()`
- Tests are now parameterized and check both the primaryStage delivered by `Application.start()` as well as a separately created Stage. Figured it might be worth testing as well, since it seems to behave slightly differently and can affect other test.

I did notice this morning that on a fresh system start, the test _can_ pass even with `--daemon` gradle flag. This happens when it is the first invocation of Gradle that run - then the used Gradle daemon instance is a child of current Terminal process (which is a foreground process) which makes Windows treat it as a foreground process as well and grant focus to its children. The most reliable way I found of reproducing this and getting the test to fail on my Windows 11 box (also has to be done after calling `gradle --stop`):
- Run one build using `gradle --daemon`
- Close the Terminal window - that will cut the daemon's association with the Terminal and make Windows treat it as a background process
- Re-open the terminal and re-run the tests using `gradle --daemon`

For me the test then fails when checking the primary Stage delivered by `Application.start()` at the keystroke part of the test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3034768336

From arapte at openjdk.org  Fri Jul  4 12:44:44 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 4 Jul 2025 12:44:44 GMT
Subject: RFR: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered to
 wrong place
In-Reply-To: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
References: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
Message-ID: <0kxn0ZVHFA6ei6s8LXjhCU5_WrCkAAltL0A_cp2zirc=.80b960e7-100e-4de7-9e4b-989c7d4c642e@github.com>

On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot.
> More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753)
> 
> In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time.
> 
> This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps).
> 
> ----
> 
> * The remote desktop for Robot is enabled by default on GnomeShell 47+
> * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46)
> * The key handling might still have bugs.
> * The main goal is to add this new functionality.  If there are small issues that can't be solved right away,  I will prefer to fix them in follow up fixes.

LGTM, 
Verified that no test fail on ubuntu 24.04. and changes are very similar to that of JDK.

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1834#pullrequestreview-2987075508

From jvos at openjdk.org  Fri Jul  4 13:06:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 4 Jul 2025 13:06:46 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
Message-ID: <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>

On Thu, 3 Jul 2025 21:23:47 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:
> 
>> 804: 
>> 805:         NSMutableData* readData = nil;
>> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();
> 
> `URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?

In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2185323239

From arapte at openjdk.org  Sat Jul  5 01:38:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Sat, 5 Jul 2025 01:38:42 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <LPatJEveDfni7JkIykb-nJgpfOXemS6ckvfWU8azBbg=.bba0abe4-7e1a-4f66-8fa7-31c3e1741abc@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

> Still getting the exception loading "msl/jfxshaders.metallib". I am running in eclipse, so perhaps the eclipse project files need to include some added paths? I've got a few of them in the workspace: ![Screenshot 2025-07-02 at 07 50 49](https://private-user-images.githubusercontent.com/107069028/461579606-c32df879-e4f7-4e12-a130-9822069774e2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTE2NzgyNTIsIm5iZiI6MTc1MTY3Nzk1MiwicGF0aCI6Ii8xMDcwNjkwMjgvNDYxNTc5NjA2LWMzMmRmODc5LWU0ZjctNGUxMi1hMTMwLTk4MjIwNjk3NzRlMi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwNzA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDcwNVQwMTEyMzJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mNDYxN2I3ZDYzNWI2MDdkMjNmZjA1M2U4ZmM2MGQxMzMzZjE4MGI3MjNkMmY4ZjMwYzk2MGI3N2EwOGY4ZDcyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.r1DObrQTjY4fEy54axEqTL
 DZ0rU3n4wQ7D82-bAaQgg)

It should use the file from build directory:
`build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl/msl/jfxshaders.metallib`

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

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

From duke at openjdk.org  Sat Jul  5 02:34:47 2025
From: duke at openjdk.org (Glavo)
Date: Sat, 5 Jul 2025 02:34:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

Unfortunately, this commit caused our app to behave abnormally :(

I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3037733509

From jhendrikx at openjdk.org  Sat Jul  5 04:59:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 5 Jul 2025 04:59:48 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
 <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
Message-ID: <Rpi3XkwnJZ2bdn0C07RiFgpAxn2rRis21_avBHoj760=.2078c96c-e731-4757-bbd2-08be0c44f207@github.com>

On Sat, 5 Jul 2025 02:32:18 GMT, Glavo <duke at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
> 
> I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

@Glavo I'd be interested in what problem you're running into (maybe before/after description?).  Perhaps there is a bug in the fix.  It's also possible you inadvertently have been relying on the behavior where content bias is sometimes ignored, which was a bug.  All FX containers always respect content bias.  In that case the only solution is to modify your layout a bit.  Let me know if I can be of help.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3038078858

From duke at openjdk.org  Sat Jul  5 06:20:46 2025
From: duke at openjdk.org (Glavo)
Date: Sat, 5 Jul 2025 06:20:46 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
 <q1FBqJeuCpFquR2KmSik7eh6yl8iBIhaqR4zUUqGd0c=.cc0897c4-fe59-4e2f-989f-ae7f4932a78a@github.com>
Message-ID: <zCJp5i9wDlmwwa_N2AM5fcO7cayBB9_UstxrB1o56No=.8968d0d1-d4ea-46ff-acfa-728ff42c194f@github.com>

On Sat, 5 Jul 2025 02:32:18 GMT, Glavo <duke at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
> 
> I know this is a problem with our app, I will try to fix it. But what I want to say is that this PR does break some real-world applications, and maybe a workaround is really needed to make them work.

> @Glavo I'd be interested in what problem you're running into (maybe before/after description?). Perhaps there is a bug in the fix. It's also possible you inadvertently have been relying on the behavior where content bias is sometimes ignored, which was a bug. All FX containers always respect content bias. In that case the only solution is to modify your layout a bit. Let me know if I can be of help.

We encountered this problem. The content of this page (excluding the title bar) is a `BorderPane`, and the red box is the content of its center, a `FlowPane`.

![image](https://github.com/user-attachments/assets/fa373e33-c5b8-40aa-83ae-64fc71733641)

In OpenJFX 25+9 and earlier, the height of this `FlowPane` was 280 pixels, but since 25+10, its height has grown to 576 pixels, so that the interface layout is broken.

![image](https://github.com/user-attachments/assets/dfff7048-32fa-42e5-8dd7-ab3925a5d9a5)

It is not difficult for us to solve this problem. Wrapping this `FlowPane` in a `ScrollPane` will restore its height to normal. However, I still don?t understand the specific reason behind it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3038246961

From jhendrikx at openjdk.org  Sun Jul  6 08:27:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 08:27:48 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <9VSGw5vdgdpv29g0FMbxsZGNZZ9xNs_4O6942pD_WP0=.5d7345a7-6475-4bf2-9568-155a1c60f350@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

The BorderPane shares some of the calculations with VBox, so it's possible it is a bug.  This small program can reproduce the issue:


.main .button {
  -fx-pref-width: 12em;
  -fx-pref-height: 12em;
}



package app;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.Label;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.FlowPane;
import javafx.stage.Stage;

public class LayoutBugDemo extends Application {

    @Override
    public void start(Stage stage) {
        BorderPane borderPane = new BorderPane();
        FlowPane flowPane = new FlowPane();

        flowPane.getStyleClass().add("main");

        borderPane.setTop(new Label("Instance Name"));
        borderPane.setCenter(flowPane);

        flowPane.getChildren().addAll(
            new Button("Minecraft"),
            new Button("Forge"),
            new Button("NeoForge"),
            new Button("OptiFine"),
            new Button("Fabric"),
            new Button("Fabric API"),
            new Button("Quilt"),
            new Button("SQL/QFAPI")
        );

        borderPane.setBottom(new Button("Install"));

        Scene scene = new Scene(borderPane, 600, 400);

        scene.getStylesheets().add("styles.css");

        stage.setScene(scene);
        stage.setTitle("JavaFX Layout Bug Demo");
        stage.show();
    }

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

}

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041190238

From jhendrikx at openjdk.org  Sun Jul  6 08:54:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 08:54:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <7EFgl4WC5omNH6lP-FlsfU5viJHgOY0mjqdY9j2wi2g=.3f2198b0-6417-41fd-ba33-8419927e01d0@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

I looked a bit further, and I think that the `getAreaHeight` function in `BorderPane` which forwards to `Region`'s `computeChildPrefAreaHeight` (which was given an extra parameter) is the culprit.  It's called with `fillWidth` set to `false` but calling it with `fillWidth` set to `true` seems to restore the old behavior.

The only troubling part of that fix however is that its counterpart (`getAreaWidth`) calls the corresponding region function for horizontal calculations with `fillHeight` set to `false` (which is why I used `false` for `fillWidth` in the height calculation as well).

I'll need to look more closely what is the correct fix here, as it seems to me that having vertical calculations use fill, but not horizontal calculations is also not what one would expect.   Creating an example where the FlowPane is laid out vertically and seeing how it behaves then may give a clue if that breaks in the same way (allocating too much width to it when used as the center of a border pane).

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041218059

From jhendrikx at openjdk.org  Sun Jul  6 09:42:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 09:42:47 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <dhwhU-bNr7nMj7qjPPhnWYG_5nblSp10WHqQyHbCClc=.e64babb6-c4ab-4cc2-9e0d-7963ba7b7b89@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

It looks like when using a vertical flow pane, that the left-to-right version of the layout is also quite poor:

![image](https://github.com/user-attachments/assets/e4ee3e07-ad47-42b6-a51f-224314d17b42)

When I apply the same fix in `BorderPane` for the horizontal calculations, it becomes this:

![image](https://github.com/user-attachments/assets/92676801-e86c-4d21-bcab-a742abccf079)

Note how the flow pane now doesn't take an unreasonable amount of space anymore cutting the install button from view.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3041253008

From jhendrikx at openjdk.org  Sun Jul  6 10:25:43 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 6 Jul 2025 10:25:43 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <tGgyvJKAXSL0crqmnmLeJCbV6CAD5j55Qn01jzgdcIA=.62ee38ee-1683-417d-bbe1-d7c1f9c825d7@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

This would also address https://bugs.openjdk.org/browse/JDK-8092347

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

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-3041294377

From maw at weichi.com  Sun Jul  6 16:56:10 2025
From: maw at weichi.com (maw at weichi.com)
Date: Sun, 6 Jul 2025 12:56:10 -0400
Subject: Debugger
Message-ID: <007f01dbee96$e1011050$a30330f0$@weichi.com>

Why is WebEngine Debugger private?

 

Marvin Wolfthal

maw at weichi.com <mailto:maw at weichi.com> 

http://www.marvinwolfthal.com <http://www.marvinwolfthal.com> 

https://www.youtube.com/@marvinwolfthal6402

 

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

From mstrauss at openjdk.org  Mon Jul  7 04:55:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
Message-ID: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>

Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

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

Commit messages:
 - javadoc
 - Added documentation
 - Add EventTarget.dispatchEvent(Event)
 - Capture (parent, delegate, dispatcher) in DelegatingEventDispatcher
 - Improved documentation, updated copyright headers
 - Merge branch 'master' into feature/focus-delegation
 - added getFocusDelegate(hoistingNode) parameter
 - Merge branch 'master' into feature/focus-delegation
 - Merge branch 'master' into feature/focus-delegation
 - added tests
 - ... and 3 more: https://git.openjdk.org/jfx/compare/0270847b...a9e6b8f8

Changes: https://git.openjdk.org/jfx/pull/1632/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343956
  Stats: 1045 lines in 16 files changed: 819 ins; 111 del; 115 mod
  Patch: https://git.openjdk.org/jfx/pull/1632.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1632/head:pull/1632

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

From mfox at openjdk.org  Mon Jul  7 04:55:22 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <2f1pzDot8o1VwXd8ZfpfyD5E9HP11NhzcD1ND-91ypU=.22544726-6aaf-4d7e-b3f3-927b244001e0@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

PopupWindows have to solve a similar problem; multiple nodes can receive key events and they all act as if they have focus. This gets (mildly) complicated when dealing with input methods. There may be multiple focused nodes but there can only be one caret so you have to have a mechanism to determine which node will respond to input method requests. You also have to determine when to enable and disable IM events at the OS level. Spinners have never dealt with input methods but ComboBoxes do.

I've submitted PR #1634 to get input methods working in popups. If you want input methods to work with focus delegation you would need to do similar bookkeeping.

I noticed that PopupWindows use EventRedirectors for forwarding messages. I didn't dig into the EventRedirector implementation but it is an existing class that seems to be tackling the same problem as this PR.

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:22 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:22 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.

It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).

When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.

The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).

Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

> > It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?).
> 
> For what it's worth I am not a fan of using the term focus owner to refer to a focus delegate. The focusOwner of a Scene is the target of key events. The focus delegate of a ComboBox is the _second_ target of key events. Key events are sent to the ComboBox first and the delegate only receives the events that it doesn't consume. To me that's an important distinction.

I don't think the distinction quite holds.  Scene does not delegate all key events.  Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics.  Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.

However, I now think that "focus delegate" is indeed the better name for this.
 
> Presumably we would need a way of telling the focus scope node which sub-node hoisted the focus so it could select the correct delegate. But it's difficult to imagine a control that's trying to pass itself off as a monolithic entity having two internal TextFields. Wouldn't that require enabling keyboard traversal inside a monolithic control? What does that mean? I don't think this is a scenario we need to solve.

See my example in my reply to Michael, I think it may be worth having a few thoughts about.

Keep open IMHO.

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

PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2569018506
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-2646636802
PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3027816893

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <1GwATw241DFoklYfHQNEXirmNyxicZ9v6qR_ALsczmU=.866ee8d3-0981-4dda-aa58-3595a2cfe523@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

@hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.

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

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

From mfox at openjdk.org  Mon Jul  7 04:55:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

@hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.

> I don't think the distinction quite holds. Scene does not delegate all key events. Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics. Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.

What you describe is a common pattern in other UI toolkits but is not how JavaFX works. All key events are immediately fired at the Scene's focus owner and all processing happens within the resulting dispatch chain. The Scene provides a dispatcher that processes mnemonics during the capturing phase (early) and menu accelerators and navigation in the bubbling phase (late). The accelerators also cover the default dialog buttons.

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
Message-ID: <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>

On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
> 
> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
> 
> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
> 
> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
> 
> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.

> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.

Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.

Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
Message-ID: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>

On Sat, 8 Feb 2025 10:35:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This looks really good.  I'm wondering if this could be simplified further.  Specifically, I think the `hoistFocus` flag and manual management of the focus delegate may not be needed.
>> 
>> It seems to me that a Control could share some similarities with a Scene, in that Control has properties that track a focus owner (similar to focus delegate). In effect, a Control is a focus root similar to scene.  When a Scene receives focus, it determines the best Node to "delegate" focus to; similarly, when a Control receives focus, it determines which skin control should be focused.  The normal focus rules should do the right thing here and for example select the TextField of a Spinner as the delegate automatically (some children may need to be marked as not focusable to guide the auto selection, but this is an already existing standard mechanism).
>> 
>> When determining where to send events, if the target is a focus root, it queries its focus owner (or focus delegate) and extends the event to that target.  If that target is also a focus root, the process repeats.
>> 
>> The request focus function should operate differently as well.  It should look for the closest focus root (a Control or Scene) and call the appropriate request focus function on the root it finds.  If that root is Scene, everything works as usual.  If it is another focus root like a Control, Control can determine the best way to focus one of its child nodes (likely you can just apply a normal search for an eligible focusable control for this).
>> 
>> Perhaps the focus root functionality can be captured in an interface that both Scene and Control implement.  I think it would need to specify a `requestFocus` method and `focusOwnerProperty`.  This interface would then replace the `focusScope` flag.
>
>> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.
> 
> Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.
> 
> Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.

> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.

Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  

I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)

Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?

This can be achieved later, just interested in hearing your thoughts:
- A getter can later become a property
- A getter can later become part of an interface
- Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)

I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.

Again, I love this proposal, and would like to move it forward.

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

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

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
Message-ID: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>

On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> 
> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
> 
> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)

Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).


> Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?

It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.

That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.

But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

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

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

From mfox at openjdk.org  Mon Jul  7 04:55:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
Message-ID: <8IoXCH_izHXmViBKO3RgiBOH_hnnpX2IV5T_0aPKDLc=.e23bb896-b809-44a8-97ca-7861d0a7586b@github.com>

On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?).

For what it's worth I am not a fan of using the term focus owner to refer to a focus delegate. The focusOwner of a Scene is the target of key events. The focus delegate of a ComboBox is the *second* target of key events. Key events are sent to the ComboBox first and the delegate only receives the events that it doesn't consume. To me that's an important distinction.

But really I just don't want to end up having a conversation about the focusOwner's focusOwner.

> But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

Presumably we would need a way of telling the focus scope node which sub-node hoisted the focus so it could select the correct delegate. But it's difficult to imagine a control that's trying to pass itself off as a monolithic entity having two internal TextFields. Wouldn't that require enabling keyboard traversal inside a monolithic control? What does that mean? I don't think this is a scenario we need to solve.

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
Message-ID: <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>

On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> @hjohn Could you provide an outline of the algorithm that a control would use to automatically determine the focus delegate? I really can't envision what that would look like. For that matter I'm not sure why we would rely on an algorithm when in the few existing cases where focus delegation is needed the control knows exactly which node to delegate to.
>> 
>> Well, `Scene` determines the initial focus node by doing a depth first search on its children and focusing the first child that is focus traversable and enabled.  I don't see why this wouldn't work for controls exactly the same way.  It's almost always the correct default, and in cases when it isn't, it could still be overridden manually.  Take a ComboBox for example.  It consists of a field and a button (or vice versa if you have a different skin).  In either case however it would focus the field as the button in the combo is not focus traversable.
>> 
>> Skins therefore can control the focus delegate by making appropriate use of focus traversable and enabled, just like you can control what Scene would pick for its initial focus.
>
>> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> 
> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  
> 
> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> This can be achieved later, just interested in hearing your thoughts:
> - A getter can later become a property
> - A getter can later become part of an interface
> - Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)
> 
> I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.
> 
> Again, I love this proposal, and would like to move it forward.

> > > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
> > 
> > 
> > Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
> > I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).

Perhaps the analogy does break down here.  I was thinking, if you could interact with a control on an inactive window, the control could decide if interacting with it should focus the window or not with the hoist focus flag.  However, that would presumably also means the Scene's focus owner shouldn't be changed (or be `null`).

> > Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.

I agree that focusOwner probably only works for well for Scene, although it could have been named focusDelegate and work quite well if there had been sufficient foresight :)

> That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.
> 
> But the proposed API doesn't seem to easily support this scenario. When I click on the second text field, it hoists the focus request up to the combo box, which in turn delegates its focus to... the first or the second text field? How would it choose? Is this a scenario that we need to solve?

Why doesn't it just set the delegate to whatever hoisted focus in the first place?  A not entirely hypothetical `DateEntryControl` with 3 separate fields internally (with borders stripped) could have a day-month-year area (such controls were quite common before fancy date pickers).  Each of the subfields could set hoist focus.  Clicking on a specific subfield would put the cursor there, but focus the `DateEntryControl` as a whole.

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <yLniXo2F4cJuLnU0OT-uu4I3cCpxWlSklsLPcChQ3ag=.aa210b49-1b61-46a3-801a-7711d118216a@github.com>
Message-ID: <Bp4rF908AIi8fTvpIbPwyRGqRGXI5-AdAGg7bkDHk1o=.007b0258-8a77-4bea-9d29-b7084b09c573@github.com>

On Tue, 11 Feb 2025 18:54:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > I don't think the distinction quite holds. Scene does not delegate all key events. Menu shortcuts for example are consumed and never dispatched, and I think the same goes for mnemonics. Navigation keys are dispatched, and only acted upon by Scene when bubbled back up.
> 
> What you describe is a common pattern in other UI toolkits but is not how JavaFX works. All key events are immediately fired at the Scene's focus owner and all processing happens within the resulting dispatch chain. The Scene provides a dispatcher that processes mnemonics during the capturing phase (early) and menu accelerators and navigation in the bubbling phase (late). The accelerators also cover the default dialog buttons.

But isn't that a distinction without a difference? Technically, you're right, all keys go to the focus owner.  In practice though, some never make it out the door.

Looks like I recalled wrong how menu keys are processed, surprisingly they can be blocked if you want.  I should have checked more closely :)

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

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

From jhendrikx at openjdk.org  Mon Jul  7 04:55:23 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <l4lxKO10hAgwzZTIlTx3XToAZxt_SPq-GYlHwBbKSt8=.c54c25c7-eff3-415b-9386-61933780b2f5@github.com>
Message-ID: <mxIrYsYnvKS4U15ZCfBNny-VTCJck59dfKtUXbfeatc=.78e7bcf8-fce5-4a48-ae1b-2285aada7126@github.com>

On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
>> 
>> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.  
>> 
>> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
>> 
>> Then what about the focus delegate?  This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed.  One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node.  Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
>> 
>> This can be achieved later, just interested in hearing your thoughts:
>> - A getter can later become a property
>> - A getter can later become part of an interface
>> - Scene can later implement an interface, even if it means duplicating the functionality of a property (if not named the same already)
>> 
>> I see some overlap, and having Nodes/Scene/Window implement a common interface (like `EventTarget`) is not unheard of.
>> 
>> Again, I love this proposal, and would like to move it forward.
>
>> > @hjohn I think what's missing in your model is the option to have an independently focusable node inside of a control. For example, think of a Button placed within a Button (via its `graphic` property). Clicking the nested button should not transfer the focus to its parent button. Whether a focus request should be hoisted is a choice that depends on the specifics of the control, and we probably need an API for that.
>> 
>> Okay, agreed, so it would be good to have Nodes control whether or not the focus traverses up.
>> 
>> I could imagine the flag could also in the future perhaps allow the Root Node or Scene to determine whether the Window should receive focus (perhaps special cases like popups or transparent overlays would allow interaction without hoisting focus to the Window?)
> 
> Do you mean window focus in a JavaFX sense, or in a window manager sense? For example, in Windows you can make a window non-activatable, which means it won't steal the focus from other windows when interacted with (for example, an on-screen keyboard window).
> 
> 
>> Then what about the focus delegate? This is not a full FX property in this API, but seems very similar to `focusOwner` in Scene, in that it determines to which `Node` (keyboard) events are directed. One could say that, since Window/Scene are also focusable, Scene is **delegating** events/focus to a node. Would it be reasonable to have `focusDelegate` be a read-only property like in `Scene`, and perhaps rename it to focus owner (or if that's too drastic, ensure that `Scene` at some later stage --might-- implement the same interface and then duplicating its focus owner property as focus delegate)?
> 
> It works quite well to say that a `Scene` delegates focus to a `Node`. It doesn't seem to work quite as well (linguistically) to say that a `TextField` is the focus owner of a `ComboBox` (the `ComboBox` is also focused, why would the `TextField` be its focus owner?). But linguistics aside, the question is whether `focusOwner`/`focusDelegate` should be a read-only property.
> 
> That's a very good question. It would allow observers to know when the focus delegate changes. But can the focus delegate change? It can probably go from non-null to null, and vice versa. Let's consider a hypothetical control that is like a combo box, but it contains two separate text fields. It seems reasonable that the focus delegate can probably change between the two text fields.
> 
> But the proposed API doesn't seem to easily support this scenario. When I cl...

@mstr2 do you think it is worth pursuing this further?

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

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

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <2zgRnl--q3CUVBpg8af2J-1WQCX-8D8pIRo3J1P37DQ=.4dca3f79-64c0-42f5-b6ac-35fe7d6f0562@github.com>
 <3__kC3GrLLNOvLxwMyK8IZ_DcrZZBPX5LAVhDwbd-rY=.df34b65d-a34a-48a5-827d-80bd1056536d@github.com>
 <qD757HcT1FBZx3OKzfKi8N2ytO8on-ym24-5zJm0ad8=.d0fe2707-22d6-49c4-b1a3-8277b742045b@github.com>
 <0PSEva7Kj-9-2aoKMsu1o2zej83C0ivq9tmBlneQ5aA=.141a86ba-c349-4731-9482-efb0da7bd6ef@github.com>
Message-ID: <U8i0klMcmpQlB8DT_BcIqPZ_i-KSyN8Kq6G_sL9-u9o=.ee5ec36f-bb8f-49a4-86a5-2a958715818b@github.com>

On Sun, 9 Feb 2025 22:45:14 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Why doesn't it just set the delegate to whatever hoisted focus in the first place? A not entirely hypothetical `DateEntryControl` with 3 separate fields internally (with borders stripped) could have a day-month-year area (such controls were quite common before fancy date pickers). Each of the subfields could set hoist focus. Clicking on a specific subfield would put the cursor there, but focus the `DateEntryControl` as a whole.

I've added a parameter to `getFocusDelegate(Node hoistingNode)`, which indicates the node that hoisted the last focus request to the node on which `getFocusDelegate` is called. The hoisting node is not necessarily a focus delegate, it can be any descendant with the `hoistFocus` flag set.

When `getFocusDelegate(Node hoistingNode)` is called, the control can use the additional information to decide which of its children will be the focus delegate.

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

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

From mstrauss at openjdk.org  Mon Jul  7 04:55:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 04:55:23 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <xK4Qcn_iSCCMw4LTdBYiB21M7wBa9xJuQYikwz-9baA=.758c1cbf-329a-4f27-a2f8-4971229a2e96@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

Dispatching an event in the presence of focus delegation is slightly different, because it requires cooperation of the `Node` that is the event target. Previously, we would dispatch an event like this:

EventUtil.fireEvent(EventTarget, Event);


With focus delegation, we need to know what the final delegate will be, and we dispatch the event like this:

EventUtil.fireEvent(EventTarget firstTarget, EventTarget finalDelegate, Event event);


Of course, this is internal code that can only be called within the `Node` class (as only `Node` knows its final delegate). But we need a way for users to correctly dispatch an event without knowing `Node` internals. [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) comes in handy here, so I've pulled that proposal into this feature.

Old code like `Event.fireEvent(EventTarget, Event)` is simply redefined to call `EventTarget.dispatchEvent(Event)`, ensuring that the overridden implementation `Node.dispatchEvent(Event)` is called. This ensures that events are always fired correctly.

Note that it is not enough to manually construct an event dispatch chain with `EventTarget.buildEventDispatchChain(EventDispatchChain)`, and call `EventDispatchChain.dispatchEvent(Event)` on it. This skips the very important step of setting the correct delegation target. I've added documentation to the existing method, clarifying that it should not be used by application developers. There is no reason to use it in any case, since we now have the `EventTarget.dispatchEvent(Event)` method instead.

This PR is now ready for review. We should finish the discussion of whether we want to have this feature in JavaFX. If we decide to go ahead, it is not required to migrate all controls to use focus delegation at the same time. This PR includes the `Spinner` control as an example, and more controls can be migrated step by step.

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

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

From jvos at openjdk.org  Mon Jul  7 07:31:49 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:31:49 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <vmJ-yiSZRmURiVEXAjDZIRkOcd8NeYV9D49TkgehPmE=.56341777-cae9-4077-a8c5-378295c95b22@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <C5R8BspvBIL6n-E3yMIXGUX3jXqZgC6wlzyN1A4uedc=.2f4c50e3-b6d1-4c88-96d6-ceadac2ad487@github.com>
 <vmJ-yiSZRmURiVEXAjDZIRkOcd8NeYV9D49TkgehPmE=.56341777-cae9-4077-a8c5-378295c95b22@github.com>
Message-ID: <S358c-L69Dbga9Zr7MEpvLv0bQrDMxuiffaD9ZnqQHs=.dd742235-ac9c-43dc-b490-ae90ac645534@github.com>

On Fri, 27 Jun 2025 20:15:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There was a failing test, so it turns out there is an implicit contract that even if a resize is requested without different w/h parameters, at least the even should still be generated.
>
> should we either add a comment or clean up (or both) then?

I cleaned it up. Typically, I'm +1 on adding more comments in the code, but not everyone likes that. In this case, it would create a precedent where we would then add tons of comments mainly to document what the tests are doing (or expecting).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189215582

From jvos at openjdk.org  Mon Jul  7 07:36:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:36:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>

On Thu, 19 Jun 2025 22:33:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 36:
> 
>> 34:     private float alpha;
>> 35:     private Pixels icon;
>> 36:     private Cursor cursor;
> 
> The following fields are never used, other than assigning a value:
> * `ptr`
> * `resizable`
> * `visible`
> * `isFocusable`
> * `enabled`
> * `closed`
> * `bg_r`, `bg_g`, `bg_b`
> * `alpha`
> * `icon`
> * `cursor`

I had those since I think they might be useful "later", when we add more configuration options, or in case there are tests that rely on them. But I believe it is better indeed to remove them, and re-introduce them when needed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189230076

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v5]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <ejMVO9gIiJtSRcyORKSF5SMRLs6FxgnKH0u4gmO_nhg=.379d7a00-9cc4-467f-b69d-5ad853ccc6f9@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process reviewer comments
  Remove unused code

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/743a3b7e..1962e05b

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

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

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

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <fzqMsh_QSmUWRf7tIEqfHQpV2LQfRFnUJTAhJK8J0Z0=.03df945c-911e-4028-bf52-65b581b0f7dc@github.com>

On Thu, 19 Jun 2025 22:13:09 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 293:
> 
>> 291:         if (button == MouseButton.BACK) return MouseEvent.BUTTON_BACK;
>> 292:         if (button == MouseButton.FORWARD) return MouseEvent.BUTTON_FORWARD;
>> 293:         return MouseEvent.BUTTON_NONE;
> 
> Use an expression to get compile-time exhaustiveness checks:
> Suggestion:
> 
>         return switch (button) {
>             case NONE -> MouseEvent.BUTTON_NONE;
>             case PRIMARY -> MouseEvent.BUTTON_LEFT;
>             case MIDDLE -> MouseEvent.BUTTON_OTHER;
>             case SECONDARY -> MouseEvent.BUTTON_RIGHT;
>             case BACK -> MouseEvent.BUTTON_BACK;
>             case FORWARD -> MouseEvent.BUTTON_FORWARD;
>         };

fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189249816

From jvos at openjdk.org  Mon Jul  7 07:47:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 07:47:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <BKAEDGPhH4ifVFa6AZtUXb6hCJeFXzxfycTwEtoG0QI=.3a0be2ba-de5c-483f-a470-3ed3daafd1e7@github.com>
Message-ID: <Y4PmxwsbjI0WVkhPW6lI_wkw9MmPDJL6gDWgx9PP1rg=.e92db160-231a-4d4d-b293-a6808c77107a@github.com>

On Mon, 7 Jul 2025 07:34:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 36:
>> 
>>> 34:     private float alpha;
>>> 35:     private Pixels icon;
>>> 36:     private Cursor cursor;
>> 
>> The following fields are never used, other than assigning a value:
>> * `ptr`
>> * `resizable`
>> * `visible`
>> * `isFocusable`
>> * `enabled`
>> * `closed`
>> * `bg_r`, `bg_g`, `bg_b`
>> * `alpha`
>> * `icon`
>> * `cursor`
>
> I had those since I think they might be useful "later", when we add more configuration options, or in case there are tests that rely on them. But I believe it is better indeed to remove them, and re-introduce them when needed.

ptr and visible are used, I removed the others.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189246617

From jvos at openjdk.org  Mon Jul  7 08:37:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 08:37:47 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <qCq8Rqf8QWB1d0fmYyhkMY0Ur-sDe5qeuqI7lRaG2iY=.1f0fdec0-1646-47bd-aab5-8bba6c90e552@github.com>

On Thu, 19 Jun 2025 22:37:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 23:
> 
>> 21:     private final HeadlessWindowManager windowManager = new HeadlessWindowManager();
>> 22:     private Screen[] screens = null;
>> 23:     private HeadlessCursor cursor;
> 
> This field is not used in this class, other than assigning a value.

removed and changed createCursor method

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 268:
> 
>> 266:     }
>> 267: 
>> 268:     boolean setFullscreen(boolean full) {
> 
> None of the two callers use the return value of this method.

changed return type to void

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189366361
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189364588

From jvos at openjdk.org  Mon Jul  7 08:37:48 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 08:37:48 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <XW0BaMtZ2wyeMcW8luUevHA7j8PlUc9Xtho5VI6qQ-M=.1ef3d039-7723-4e46-9bd5-415155b8897c@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
 <XW0BaMtZ2wyeMcW8luUevHA7j8PlUc9Xtho5VI6qQ-M=.1ef3d039-7723-4e46-9bd5-415155b8897c@github.com>
Message-ID: <E9XugatAcSHZPqKWbeRhpt0v25YbmIMT0bNzrz0xMl0=.001d7689-97f0-4bec-8c26-2ec0578f761a@github.com>

On Fri, 27 Jun 2025 19:59:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessView.java line 16:
>> 
>>> 14:     private Pixels pixels;
>>> 15: 
>>> 16:     private boolean imeEnabled;
>> 
>> The following fields are not read, but only assigned to in this class:
>> * `capabilities`
>> * `x`
>> * `y`
>> * `imeEnabled`
>> 
>> The field `parentPtr` is neither assigned nor read.
>
> x, y are read in View::getX/Y

removed capabilities and imeEnabled

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189369086

From jvos at openjdk.org  Mon Jul  7 09:06:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:06:08 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v6]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <S9UpXUTmaX0JbVUmWwnf77iTqvepKt3KA0I5iOsy9gY=.e79c5848-c51e-4f8c-af35-683dd23300c5@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  More reviewer processing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/1962e05b..541d8e55

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

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

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

From jvos at openjdk.org  Mon Jul  7 09:15:46 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:15:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <nJpDhAjLTAfR8jPFVXz7O-FZzbNpXPt84PpayjZQwok=.71104f21-73d2-4a25-885a-1a3a1cdb4bc5@github.com>

On Fri, 27 Jun 2025 16:54:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 22:
> 
>> 20:     private final NestedRunnableProcessor processor = new NestedRunnableProcessor();
>> 21:     private final HeadlessWindowManager windowManager = new HeadlessWindowManager();
>> 22:     private Screen[] screens = null;
> 
> minor: no need to assign null, also L24

removed.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 41:
> 
>> 39:     @Override
>> 40:     protected void _invokeAndWait(Runnable runnable) {
>> 41:         throw new UnsupportedOperationException("Not supported yet.");
> 
> is there a follow-up bug for this, or the list of things to do?

I think it's best to keep this here, because in case there is somehow an invocation of this method, we want to be notified about it, and then come up with the most appropriate way to implement it.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 92:
> 
>> 90:     @Override
>> 91:     protected void staticCursor_setVisible(boolean visible) {
>> 92:         throw new UnsupportedOperationException("Not supported yet.");
> 
> should it be a no-op instead?  will cursor be supported at all?

There is a Headless Cursor, but the setVisible method doesn't seem to be used in any of the tests currently.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 179:
> 
>> 177:     public void getScreenCapture(int x, int y, int width, int height, int[] data, boolean scaleToFit) {
>> 178:         checkWindowFocused();
>> 179:         ((HeadlessWindow)activeWindow).getScreenCapture(x, y, width, height, data, scaleToFit);
> 
> maybe the `activeWindow` can be declared as `HeadlessWindow` to avoid casting

good idea, done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189445871
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189447802
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189449818
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189454545

From jvos at openjdk.org  Mon Jul  7 09:15:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:15:47 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v2]
In-Reply-To: <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <mlNypKVcXnxK0631x7FQdmRlzwsO8iRZfnwz0Hpl-aY=.dd034394-3ce5-44f7-b511-b8e79c9f10f7@github.com>
 <yEfvm7xUQBUlNdyRUcEaPX48YUYMG0Zq7AgA0Oil70k=.75d2596c-aeb3-4e19-9448-dc5726ebf5a7@github.com>
Message-ID: <_buCzuGyzQikonLUXoiIZfr_anIbzoCQ36U3i1voA-M=.bec1c6e5-f2e1-41ad-9240-07bccac1f68e@github.com>

On Thu, 19 Jun 2025 22:45:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing ;
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 20:
> 
>> 18:     }
>> 19: 
>> 20:     void invokeLater(final Runnable r) {
> 
> The following methods are never used:
> * `invokeLater`
> * `runLater`
> * `invokeAndWait`
> * `stopProcessing`

invokeLater is used from HeadlessApplication
Others are removed now.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189444853

From jvos at openjdk.org  Mon Jul  7 09:18:44 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:18:44 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <-EWqPffHmp_NKfHW8QN5HmexgbxOnpNlT4BF8GMzYsY=.703b3cf5-a936-4922-8c90-4d5c2b75d77a@github.com>

On Fri, 27 Jun 2025 19:31:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 231:
> 
>> 229:         if (windows.isEmpty()) return null;
>> 230:         if (windows.size() == 1) return (HeadlessWindow)windows.get(0);
>> 231:         return (HeadlessWindow)windows.get(windows.size() -1);
> 
> call me old fashioned, but would a straightforward reverse `for` loop be better in this case?  no unnecessary memory allocations required.
> 
> here and in two methods below?

I'm not a fan of using Streams if it's not really needed, but in this case I think there might be benefits in eliminating the non-candidates in 1 statement -- I might be wrong though, didn't look yet at how this is compiled.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189460398

From jvos at openjdk.org  Mon Jul  7 09:22:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:22:45 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <5vBITMuRZ8SuWE2tVtR5s1qoA2yjmF2rf4c_S59H_CI=.0680f3f6-7b82-46a3-baea-761ac406b2af@github.com>

On Fri, 27 Jun 2025 20:00:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 19:
> 
>> 17: 
>> 18:     private static final AtomicInteger ptrCount = new AtomicInteger(0);
>> 19:     private long ptr;
> 
> since `ptr` is long, should `ptrCount` be `AtomicLong`?

it's more elegant indeed, so I changed it.
It's not really needed though, since contrary to native implementations, the pointer we return here is not a pointer to some memory, hence we don't need 64 bits. The method declaration for _createWindow requires a long though, so we need to return a long.

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 316:
> 
>> 314:         int b = rgba & 0xFF;
>> 315: 
>> 316:         Color color = Color.color(
> 
> could use `Color::rgb(int,int,int,double)`;

done

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189466725
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189468946

From jvos at openjdk.org  Mon Jul  7 09:29:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:29:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process more reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/541d8e55..479a8149

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

  Stats: 44 lines in 4 files changed: 2 ins; 34 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul  7 09:29:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 09:29:22 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <3jmKYq2h0Be_Qp02X2nJUAJatqxw98IHVQqfF12W3Ns=.33431bdc-bc82-43b9-ad5b-b441cc2d995a@github.com>

On Fri, 27 Jun 2025 20:19:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 329:
> 
>> 327:             for (int j = 0; j < width; j++) {
>> 328:                 int idx = i * width + j;
>> 329:                 int fidx = (y + i) * 1000 + x + j;
> 
> where does 1000 come from?

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 341:
> 
>> 339:         int offsetX = this.getX();
>> 340:         int offsetY = this.getY();
>> 341:         int stride = 1000;
> 
> same magic 1000 here

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 356:
> 
>> 354: 
>> 355:     void clearRect(int x0, int w0, int y0, int h0) {
>> 356:         int stride = 1000;
> 
> and here...

it's the stride used in the ByteBuffer holding the frame. I've moved it to a final int and removed all hard occurrences of 1000 .

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477073
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477376
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2189477514

From jpereda at openjdk.org  Mon Jul  7 14:19:52 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 7 Jul 2025 14:19:52 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
Message-ID: <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>

On Mon, 7 Jul 2025 09:29:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process more reviewer comments

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 129:

> 127:         view.notifyMouse(MouseEvent.DOWN, getGlassEventButton(buttons), (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
> 128:         int buttonCode = getGlassEventButton(buttons);
> 129:         view.notifyMouse(MouseEvent.DOWN, buttonCode, (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);

This code (`view.notifyMouse(...`) is duplicated, and there are two notifications of mouse down while there should be just one.

The first line can be removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190246607

From jvos at openjdk.org  Mon Jul  7 14:46:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:19 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v8]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <kxr1DwwMl9H8bBHEL503ggl9d4gg-SRgVDAN68hs6Gw=.8400b0e7-978a-4d84-abaa-bd2e17fe3e3d@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Do not invoke notifyMouse twice

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/479a8149..3d64f2ce

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

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

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

From jvos at openjdk.org  Mon Jul  7 14:46:19 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:19 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
 <mbueJAJ8EQaQAYbaIhrNOmfwImF04MWm1IFQjOXACzI=.252b2cb1-665a-42aa-986a-10ee913a2d56@github.com>
Message-ID: <ZHSaaTPZ3x75xy58oF3XVefBTcfw_Dj8JwMYx0t5E48=.65f72a3e-9540-4ad5-9eb5-5d85e8fa56e0@github.com>

On Mon, 7 Jul 2025 14:17:37 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process more reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 129:
> 
>> 127:         view.notifyMouse(MouseEvent.DOWN, getGlassEventButton(buttons), (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
>> 128:         int buttonCode = getGlassEventButton(buttons);
>> 129:         view.notifyMouse(MouseEvent.DOWN, buttonCode, (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, true, true);
> 
> This code (`view.notifyMouse(...`) is duplicated, and there are two notifications of mouse down while there should be just one.
> 
> The first line can be removed.

Right, good catch!
I removed that first line.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190305053

From jvos at openjdk.org  Mon Jul  7 14:46:20 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 14:46:20 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <Q3wjEB3nQCMdt-NFnKS9lLi5_3eUbxQZDoQq0rsMylk=.fde50dcb-d51f-461f-984f-958cee26d052@github.com>

On Fri, 27 Jun 2025 20:24:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/NestedRunnableProcessor.java line 40:
> 
>> 38:             latch.await();
>> 39:         } catch (InterruptedException e) {
>> 40:             e.printStackTrace();
> 
> should we print here or send to `Application.reportException(e)` ?

the method has been removed as it wasn't used.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190305902

From martinfox656 at gmail.com  Mon Jul  7 14:50:05 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 7 Jul 2025 07:50:05 -0700
Subject: Inconsistent drawing/layouts of Dialogs & show()/showAndWait()
 differences
In-Reply-To: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>
References: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>
Message-ID: <D51A5B9D-07DC-4B95-80EE-7E1B7FDD731C@gmail.com>

Cormac,

When you call Dialog.show everything happens in the order you expect. When you call Dialog.showAndWait the order of operations changes. For one, the Dialog code issues the DIALOG_SHOWN event *before* showing the window (it wants to send out that event before an internal call to Window.showAndWait blocks). For two, when Window.sizeToScene is called on a window that?s not yet visible it gets deferred. The end result is that with Dialog.showAndWait your onShown handler gets called before the window is sized to the scene but when you use Dialog.show your onShown handler is called after.

I don?t think any of this is documented. I've run into the deferred sizeToScene behavior before. I didn?t dig much but it looks like it was added over a decade ago in response to some bug reports. The timing of Dialog.setOnShown is also old behavior. There?s a comment in the Dialog.java about this:

>  // this is slightly odd - we fire the SHOWN event before the show()
>  // call, so that users get the event before the dialog blocks

So I can see what?s going on in case #2. Due to the re-ordering the sizeToScene logic is happening after the window?s minimum size is set. The docs don?t say what should happen if the scene?s desired size is less than the window?s minimum. What you?re getting is a scene that doesn?t fill the window. One work-around for case 2 is to call setOnShown on the dialog?s window instead of the dialog itself.

BTW, I think what you?re seeing in case #3 is correct and not a bug. You?re altering the size of the scene after the window has been sized and shown. I wouldn?t expect the window to automatically re-size to match the new scene dimensions. I think the expectation is that you would alter the scene?s dimensions in onShowing instead of onShown.

Martin

> On Jul 3, 2025, at 2:24?PM, Cormac Redmond <credmond at certak.com> wrote:
> 
> Hi,
> 
> I have noticed inconsistent and confusing size/layout behaviour with Dialogs when changing min width or height (after shown).
> 
> The behaviour depends on whether changing min width/height on the Stage, or the DialogPane itself, and whether show() or showAndWait() is used.
> 
> In summary:
> Set Stage mins + show()
> no bug
>  Set Stage mins + showAndWait()
> improper layout: background applies only to label (i.e., size before re-size), button wrong position, re-sizing window fixes the problem
> 3 Set DialogPane mins + show()
> min sizes are ignored, button is visible, until it comes into focus, and then the button disappears, you can find it if you resize window close to the mins set
> 4 Set DialogPane mins + showAndWait()
> no bug
> It's happening in JFX23/24/25. Note, these may seem trivial/fixable, or you may ask "why would you do that?", but there are reasons I won't clutter the mail with.
> 
> Anyway, it's best presented with a set of examples and code.
> 
> Re points 1 and 2 above, exact same code, except red is showAndWait() and green is show():
> 
> <image.png>
> 
> Obviously, they should behave the same. Then slightly resize the red one:
> 
> <image.png>
> 
> 
> Examples 3 and 4 above -- again, same code. Purple is show(), yellow is showAndWait().
> 
> <image.png>
> 
> After you close the yellow dialog:
> 
> <image.png>
> 
> They should be the same size from the outset.
> 
> 
> 
> public class DialogBug extends Dialog<Boolean> {
> 
>     public DialogBug(final String s, boolean flip) {
>         setTitle("Bug");
>         setResizable(true);
> 
>         final DialogPane dp = getDialogPane();
>         dp.setStyle(s);
>         dp.getButtonTypes().add(ButtonType.CLOSE);
>         dp.setContent(new Label("Content"));
> 
>         // Setting stage size causes the bug
>         setOnShown(e -> {
> 
>             if (flip) {
>                 // Set stage sizes
>                 Stage st = (Stage) dp.getScene().getWindow();
>                 st.setMinHeight(260);
>                 st.setMinWidth(360);
>             } else {
>                 // Set dialog sizes: note buttons disappear when you resize
>                 dp.setMinHeight(260);
>                 dp.setMinWidth(360);
>             }
>         });
>     }
> 
>     public static class BugApp extends Application {
>         @Override
>         public void start(final Stage st) throws Exception {
> 
>             final boolean FLIP_ME = true; // make true for other bug
> 
>             if (FLIP_ME) {
>                 // Note: bug doesn't happen when using show() only. Stage is fully green on show.
>                 new DialogBug("-fx-background-color: green;", true).show(); // NO BUG
> 
>                 // showAndWait presents the bug; background not fully drawn, button shifts on re-size
>                 new DialogBug("-fx-background-color: red;", true).showAndWait(); // BUG
>             } else {
>                 // A different type of issue: two different sizes and button behaviour
>                 // Notice:
>                 // - same dialogs, different sizes
>                 // - how button in purple dialog shifts when yellow dialog pane is closed
>                 new DialogBug("-fx-background-color: purple;", false).show(); // BUG
>                 
>                 new DialogBug("-fx-background-color: yellow;", false).showAndWait(); // NO BUG
>             }
>         }
>     }
> }
> 
> Thoughts?
> 
> 
> 
> Kind Regards,
> Cormac

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250707/6583727b/attachment.htm>

From angorya at openjdk.org  Mon Jul  7 15:06:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 15:06:50 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <dPBLv09XBCvhCatQ3aGccbZXv_dpfrPE1xdh6vGA00k=.0ea816cd-9a3e-4416-bb67-063306baa26c@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

It might be better to create a new JBS ticket if this is a new bug (or reference an existing one).

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3045549633

From angorya at openjdk.org  Mon Jul  7 15:30:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 15:30:47 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <MS8WacJV6w0NlBecoeWXmDsrAxQKLkjK53RYPhAmcMQ=.e05e1ddc-1699-4e99-9a80-db272aeac687@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Should the new library be copied to `rt/build/sdk/lib` as part of the build?

I've added the directory you mentioned to the `java.library.path` and it still fails to open the library:


-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl/msl"


Passing `rt/modules/javafx.graphics/build/msl` directory also fails:


-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/modules/javafx.graphics/build/msl"

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

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

From zelmidaoui at openjdk.org  Mon Jul  7 16:26:46 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 7 Jul 2025 16:26:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I tried it, the tests pass successfully however when trying in MonkeyTester I am not able to show characters and caret path when I check the box it throws an error :
`Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.oracle.tools.fx.monkey.util.TextShapeLogic.ordinal()" because "logic" is null`

(https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected)

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3045808969

From angorya at openjdk.org  Mon Jul  7 16:34:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 16:34:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <L88HaX0IpkgjMHjeeIwWy5J8jouCI4qMUdv5GoFPOjw=.990a4792-9c01-4178-b73b-e178c3c8c17a@github.com>
Message-ID: <PHdgcKUWOCclMZLb3KnVw_reH8P1bTzCWMSDvdqX2QU=.7b69013e-08fa-472e-a96c-e9325d737d10@github.com>

On Mon, 7 Jul 2025 16:23:43 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> when trying in MonkeyTester

Please update (git pull) the monkey tester and retry (or just select a value in the "API:" combo box.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3045849075

From mfox at openjdk.org  Mon Jul  7 16:59:13 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 16:59:13 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
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: <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@github.com>

> 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.

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.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1837/files
  - new: https://git.openjdk.org/jfx/pull/1837/files/9ba898a9..524b3f43

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

  Stats: 436 lines in 3 files changed: 295 ins; 128 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1837.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1837/head:pull/1837

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

From mfox at openjdk.org  Mon Jul  7 16:59:13 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 7 Jul 2025 16:59:13 GMT
Subject: RFR: 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: <1r5DEJWI74SZP4EohdKIwWNugj6sGmL4cKl-WFe4JAs=.a789ba5a-663e-4022-a5e3-f1446ffeb9a7@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.

Well, now I?ve gone and re-written this PR.

As stated earlier sometimes a single key press can lead to multiple calls to performKeyEquivalent. During testing I discovered that the way Glass checks for this doesn?t always work. Currently it tries to guess which key event might lead to a second one but there are cases where it guesses wrong (e.g. the Hebrew layout). I?ve decided to take a different approach, detecting and discarding the second event. The logic is:

- Is the new key event not the current event (theEvent != NSApp.currentEvent)?
- Are we still working on an earlier event (NSApp.currentEvent == lastKeyEvent)?

If both these conditions are true we can ignore the new key event.

I?ve reverted the changes to the manual test and added a system test. It covers a smattering of carefully selected keys including the combinations involved in this bug. Currently it?s restricted to macOS and Latin keyboards because the Hebrew keyboard on macOS is crazy. I will expand this to other platforms when I have time to do the testing. I?ve run this test on macOS using US English, French, German, Spanish, Hebrew, Devanagari, and a few other layouts.

(About that Hebrew layout. When you hold down Command all the keys start behaving like a US English layout, including the punctuation keys. So the key you press to type a period is entirely different from the key that generates Cmd+period.)

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

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

From jpereda at openjdk.org  Mon Jul  7 17:17:46 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 7 Jul 2025 17:17:46 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
Message-ID: <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>

On Mon, 7 Jul 2025 09:29:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process more reviewer comments

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 296:

> 294:         int b = rgba & 0xFF;
> 295: 
> 296:         Color color = Color.rgb(r, g, b, a);

`Color::rgb` requires opacity between 0 and 1, therefore, you need:


Color color = Color.rgb(r, g, b, a / 255.0);

Minor: you can inline the variable.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190667156

From jvos at openjdk.org  Mon Jul  7 17:56:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 17:56:06 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Specify A as a double.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/3d64f2ce..2925f42c

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

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

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

From jvos at openjdk.org  Mon Jul  7 17:56:06 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 7 Jul 2025 17:56:06 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v7]
In-Reply-To: <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <pwxyqdpeJbAsv4SGcu0lLLmnxEDu1kvuRbwrvCSx8nQ=.694b819f-4c90-4234-9f27-5238d95e12d6@github.com>
 <d03qpI8bH6Brecwhc9H_IpHtPbUggjSb3L57A2f_N0I=.8edb4ba4-a057-4a24-bb7d-159fb5dc6dec@github.com>
Message-ID: <9e-9LkDqiQl_GKfVnoEwDGLzL52OSzgrMfrA2UqypK4=.29879acf-c39b-41a1-9609-0bcb9468bc6b@github.com>

On Mon, 7 Jul 2025 17:15:12 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process more reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 296:
> 
>> 294:         int b = rgba & 0xFF;
>> 295: 
>> 296:         Color color = Color.rgb(r, g, b, a);
> 
> `Color::rgb` requires opacity between 0 and 1, therefore, you need:
> 
> 
> Color color = Color.rgb(r, g, b, a / 255.0);
> 
> Minor: you can inline the variable.

Good catch, thanks!
Fixed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2190726879

From azvegint at openjdk.org  Mon Jul  7 18:47:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 7 Jul 2025 18:47:45 GMT
Subject: Integrated: 8357584: [XWayland] [OL10] Robot.mousePress() is delivered
 to wrong place
In-Reply-To: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
References: <rs9zCS6RpV9mA3wFg7-toXaVzMUoL6aDdso4Qe7I058=.a783c480-481c-48bb-9079-d43dccd7f570@github.com>
Message-ID: <2bvZ8SFMbFUMSMORDVj8-BVlSAmrPS7HxIEQSaDu-ag=.547c2656-98fc-43de-afca-f207e6220211@github.com>

On Wed, 18 Jun 2025 15:33:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset introduces an adapted version of [the OpenJDK fix](https://github.com/openjdk/jdk/commit/2dfbf41d2a3dbcd44f9ed9a58a1b0932d7536977) for mouse and keyboard interactions with Robot.
> More info about the issue itself is available in the PR [description](https://github.com/openjdk/jdk/pull/25265#issue-3068640753)
> 
> In short, the currently used XTest for keyboard and mouse interactions may not be suitable for automated testing at some point, as it may require user confirmation to control the mouse or keyboard from time to time.
> 
> This fix adds support for the [Remote Desktop XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html).
> This allows us to control the keyboard and mouse with Robot on Wayland, even outside the XWayland server (e.g., clicking on window headers and Wayland native apps).
> 
> ----
> 
> * The remote desktop for Robot is enabled by default on GnomeShell 47+
> * It can be enabled manually by setting the `javafx.robot.screenshotMethod` system property to `dbusRemoteDesktop` (e.g. it works on Ubuntu 24.04 with GnomeShell 46)
> * The key handling might still have bugs.
> * The main goal is to add this new functionality.  If there are small issues that can't be solved right away,  I will prefer to fix them in follow up fixes.

This pull request has now been integrated.

Changeset: 639a5950
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/639a5950b6eae7870fd9d9e84f9ce81322aaab82
Stats:     1312 lines in 12 files changed: 1081 ins; 139 del; 92 mod

8357584: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place

Reviewed-by: lkostyra, arapte

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

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

From kevin.rushforth at oracle.com  Mon Jul  7 18:57:34 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 7 Jul 2025 11:57:34 -0700
Subject: Proposed schedule for JavaFX 25
In-Reply-To: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>
References: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>
Message-ID: <2de91cd1-655a-4f62-b525-4a5fd65dec0b@oracle.com>

As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 25 starts on Thursday, 
July 17, 2025 at 16:00 UTC (09:00 US/Pacific time), ten days from now.

During rampdown of JavaFX 25, the "master" branch of the jfx repo will 
be open for JavaFX 26 fixes.

Please allow sufficient time for any feature that needs a CSR. New 
features should be far enough along in the review process that you can 
finalize the CSR no later than Thursday, July 10, or it is likely to 
miss the window for this release, in which case it can be targeted for 
JavaFX 26.

We will follow the same process as in previous releases for getting 
fixes into JavaFX 25 during rampdown. I'll send a message with detailed 
information when we fork, but candidates for fixing during RDP1 are 
P1-P3 bugs (as long as they are not risky) and test or doc bugs of any 
priority. Some small enhancements might be considered during RDP1, but 
they require explicit approval; the bar will be high for such requests.

-- Kevin

On 5/10/2025 9:16 AM, Kevin Rushforth wrote:

> Here is the proposed schedule for JavaFX 25:
>
> RDP1: Jul 17, 2025 (aka ?feature freeze?)
> RDP2: Aug 7, 2025
> RC: Aug 28, 2025 (aka ?code freeze?)
> GA: Sep 16, 2025
>
> We plan to fork a jfx25 stabilization branch at RDP1.
>
> The start of RDP1, the start of RDP2, and the code freeze will be 
> 16:00 UTC on the respective dates.
>
> Please let Johan or me know if you have any questions.
>
> -- Kevin


From mstrauss at openjdk.org  Mon Jul  7 20:52:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 20:52:45 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I'm a bit skeptical with this approach. You describe the existing methods as "buggy". If that's the case, being good stewards of the API should point us towards fixing the bugs instead of adding new methods that seem confusingly similar.

The JBS ticket includes the following information:

> This bug might present a compatibility risk for existing applications which tried to compensate for it by getting the borders and padding from the corresponding Nodes and adding it to each path element (or setting translateX/Y).

Is this just a guess, or do you have any data to corroborate the problem? Messing up the API and baking "buggy" implementations into JavaFX forever should require quite a bit of justification.

Have alternatives been discussed? For example, we could have a system property to fall back to the old behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046484454

From angorya at openjdk.org  Mon Jul  7 20:59:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 20:59:46 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
Message-ID: <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>

On Mon, 7 Jul 2025 20:49:38 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Have alternatives been discussed?

Yes, internally.  This PR has been out for quite a while, too.

The priority here is not to break the existing applications that might have coded a workaround.  We offer a new set of (better named) APIs withe the right behavior, while deprecating (not for removal) the existing ones.

Adding a system property seems a worse choice since it will break the apps and force the change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046500268

From mstrauss at openjdk.org  Mon Jul  7 21:13:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 7 Jul 2025 21:13:43 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
 <GEGw21M1QTiePejMgKxMpWCrySo8iEm_sMObPoVQqpM=.576730ee-53fb-4452-add3-24aa571ce9c5@github.com>
 <zW0C1RWDj1PK2Cavy6hgk23yCqrZvAddYUS6Nx6kf9Y=.160e2fc7-1958-434d-930d-d2b2c29a68e8@github.com>
Message-ID: <BAvSCu0oxktifrjbfWiWv-YEOs-ST1wxISMWF08fHac=.f8b76475-d0f8-4b7e-8760-c5df7adbf46f@github.com>

On Mon, 7 Jul 2025 20:56:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Have alternatives been discussed?
> 
> Yes, internally. This PR has been out for quite a while, too.

Okay... the OpenJFX project states in CONTRIBUTING.md, section "New features / API additions":
_Discuss the proposed feature on the [openjfx-dev](https://mail.openjdk.org/mailman/listinfo/openjfx-dev) mailing list._

I'm not sure how "internal" discussions qualify. Oracle is not the only stakeholder in this project.

> The priority here is not to break the existing applications that might have coded a workaround.

My question was whether this is an educated guess, or whether this problem is corroborated by data.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046533056

From andy.goryachev at oracle.com  Mon Jul  7 21:23:30 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 7 Jul 2025 21:23:30 +0000
Subject: Enhanced Text/TextFlow APIs
Message-ID: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Summary

This change adds new methods to the TextFlow which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.

Problem

A number of methods in TextFlow fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
?         caretShape
?         hitTest
?         rangeShape

Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the TextFlow and the Text classes.

Solution

The solution is two-fold:
1.     deprecate the buggy methods (not for removal), adding explanations in their javadoc comments
2.     add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.

The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670

Testing

Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):

https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Issues
?         JDK-8341438<https://bugs.openjdk.org/browse/JDK-8341438>: TextFlow: incorrect caretShape(), hitTest(), rangeShape() with non-empty padding/border (Bug - P4)
?         JDK-8357594<https://bugs.openjdk.org/browse/JDK-8357594>: Text/TextFlow: strike through shape (Enhancement - P4)
?         JDK-8358000<https://bugs.openjdk.org/browse/JDK-8358000>: Enhanced Text/TextFlow APIs (CSR)

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

From angorya at openjdk.org  Mon Jul  7 21:27:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 7 Jul 2025 21:27:44 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <TXLJanaTrCFRDuOBYk1EqinImHJbheqvduWrCs2HkdE=.e42cdeb7-22be-4e19-b24f-7fe314520d8e@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

Point taken.  Posted to the mailing list.

> My question was whether this is an educated guess

It's an educated guess.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046564373

From duke at openjdk.org  Mon Jul  7 23:47:46 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Mon, 7 Jul 2025 23:47:46 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <z7mqZMo_ZfO4qVvJlAzoz7knjEadpJrCrZXN8x4uUNI=.c09e28e8-6d89-4931-96c1-5c006302988f@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

FYI to any reviewer: I've been using this branch's EXTENDED/HeaderBar extensively now without any new issues...

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

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3046847252

From almatvee at openjdk.org  Tue Jul  8 01:05:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 01:05:43 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
 <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
Message-ID: <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>

On Fri, 4 Jul 2025 13:03:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm line 806:
>> 
>>> 804: 
>>> 805:         NSMutableData* readData = nil;
>>> 806:         bool isRandomAccess = locatorStream->GetCallbacks()->IsRandomAccess();
>> 
>> `URIConnectionHolder` always return `false` for "jar" or "jrt" protocol. Why it was added?
>
> In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
> The cacheEntry is created by the `NativeMediaAudioClip<init>` which is indirectly called by the AudioClip constructor.
> 
> In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.
> 
> Alternatively, we might try to use the already-created ConnectionHolder instead of creating a new one in OSXMediaPlayer.mm.

Yes, you right `MemoryConnectionHolder` in case of jar, but only for AudioClip. MediaPlayer does not use it. I tested AudioClip with jar with and without random access. Without random access I only hear some clicking sounds, so looks like it does not work completely. With random access I can only hear audio for like 30 seconds and then it loops, so looks like it is broken as well.

Can you play audio file correctly via AudioClip?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2191270417

From michaelstrau2 at gmail.com  Tue Jul  8 02:40:48 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 8 Jul 2025 04:40:48 +0200
Subject: Enhanced Text/TextFlow APIs
In-Reply-To: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>

In most cases, I would advise against having similarly-named methods
that exhibit different semantics. If the behavior of the existing
methods is indeed a bug (and not just different, but legitimate
semantics), then fixing that would be best. We've done breaking
changes in the past where appropriate, and expect applications to make
necessary changes in their API use when switching to a new version of
JavaFX. Always keeping old behavior around runs the risk of
fossilizing the API in the long run.

In rare cases, and especially when necessary changes would be more
involved, there's the option to hide the previous behavior behind a
system property. Setting a system property in lieu of changing code is
a low-effort option for applications that are not prepared to fix
their code just yet.

If we want to keep the old methods around indefinitely, another option
would be to make the new methods clearly different to indicate their
changed semantics.

For example, for the existing method `rangeShape(int, int)`, we could
add another method `rangeShapeWithLineSpacing(int, int)`. This makes
the semantics of the method abundantly clear to users, and keeps the
old method around. It also avoids the proposed boolean argument
`includeLineSpacing`, which is usually better API design.

As another example, the existing method `caretShape(int, boolean)`
could be paired with `caretShapeWithInsets(int, boolean)`.

My main criticism is that method pairings like `rangeShape` and
`getRangeShape` muddy the API waters. We'd never have done that, had
we thought about the correct semantics earlier. Evolving an API is
always hard, but the goal should be to have the new API fit well with
the existing API, as if it had been thought of from the beginning.

From almatvee at openjdk.org  Tue Jul  8 02:53:45 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 02:53:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <Vm76amfyp2_Iv73xYFq0tgEmSAEF1YQSvIVZU0-F8fk=.72f101fd-40c0-4a52-a432-d31038f38bcb@github.com>
 <22PIxR2s2anSeuUZsJ84DhBzM9ceP9-2V6WuOhvBDvQ=.d55f0884-7818-4dd3-b16f-bd46924f242f@github.com>
 <QaImQFOS68XPwqwjQ8QTErcAqw9OCvuWdibkEoo62tc=.1be626fe-4fab-4268-b1e4-6d2f9165412f@github.com>
Message-ID: <aiqgrMkwcD-w_0JWZ6-CU-Wiiv6nFUJu2-O7UQ_ts0s=.5f8b1b73-2475-4205-9400-4593c0783ce9@github.com>

On Tue, 8 Jul 2025 01:03:23 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> In case of jar, the ConnectionHolder is a `MemoryConnectionHolder` (because Locator already has a cacheEntry) which has true for isRandomAccess. 
>> The cacheEntry is created by the `NativeMediaAudioClip<init>` which is indirectly called by the AudioClip constructor.
>> 
>> In case `readNextBlock` is used on a MemoryConnectionHolder, it seems all chuncks are asked  and played simultaneously (bug in MemoryConnectionHolder.readNextBlock?). With `readBlock` the order and sequence seem to be ok.
>> 
>> Alternatively, we might try to use the already-created ConnectionHolder instead of creating a new one in OSXMediaPlayer.mm.
>
> Yes, you right `MemoryConnectionHolder` in case of jar, but only for AudioClip. MediaPlayer does not use it. I tested AudioClip with jar with and without random access. Without random access I only hear some clicking sounds, so looks like it does not work completely. With random access I can only hear audio for like 30 seconds and then it loops, so looks like it is broken as well.
> 
> Can you play audio file correctly via AudioClip?

I figure it out. Seek is ignored for random access, so setting `pos = 0` will always read from begging of the file. We should read from `dataRequest.requestedOffset`. I am attaching proposed patch which I tested and works fine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2191370087

From almatvee at openjdk.org  Tue Jul  8 02:58:44 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 02:58:44 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

[8357714.0.patch](https://github.com/user-attachments/files/21113478/8357714.0.patch)
- Patch which does not do seek with random access and it will read data starting from `dataRequest.requestedOffset`.
- For size `requestedLength` is used. I do not see a need to use anything else. It will be limited to requested length or 1 Megabyte.
- Added `NULL` checks and `callbacks` release.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3047188025

From michaelstrau2 at gmail.com  Tue Jul  8 04:22:24 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Tue, 8 Jul 2025 06:22:24 +0200
Subject: Debugger
In-Reply-To: <007f01dbee96$e1011050$a30330f0$@weichi.com>
References: <007f01dbee96$e1011050$a30330f0$@weichi.com>
Message-ID: <CAJEpuXTceik+zdEqXO2=Lp+zUSFtz+SexiXRATSLjgr8Nu+qdw@mail.gmail.com>

Probably because no one felt the need to work on a public API for it yet.
There seems to be some prior work for WebView debugging, maybe this
can be of some use: https://github.com/vsch/Javafx-WebView-Debugger


On Sun, Jul 6, 2025 at 6:56?PM <maw at weichi.com> wrote:
>
> Why is WebEngine Debugger private?
>
> Marvin Wolfthal
> maw at weichi.com
> http://www.marvinwolfthal.com
> https://www.youtube.com/@marvinwolfthal6402
>

From jvos at openjdk.org  Tue Jul  8 07:26:28 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 8 Jul 2025 07:26:28 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v2]
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Process reviewer comments
  Add null checks
  Fix errors in position and length calculations

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1839/files
  - new: https://git.openjdk.org/jfx/pull/1839/files/b1459d09..e99a8504

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

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

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

From jvos at openjdk.org  Tue Jul  8 07:26:28 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 8 Jul 2025 07:26:28 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <7-ERCruD2E_15AH94Bm_SNsKYEQKgbfIyVTIaE6y-mI=.10476736-c536-4b6f-9d22-5448b7bf48f7@github.com>
Message-ID: <AIPROV-1aZ09SPr9otDP7rnzX_5vuvrwHigDd7sKis0=.dd73d09c-749d-4671-82e7-167f19fcc6d4@github.com>

On Tue, 8 Jul 2025 02:55:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> [8357714.0.patch](https://github.com/user-attachments/files/21113478/8357714.0.patch)
> - Patch which does not do seek with random access and it will read data starting from `dataRequest.requestedOffset`.
> - For size `requestedLength` is used. I do not see a need to use anything else. It will be limited to requested length or 1 Megabyte.
> - Added `NULL` checks and `callbacks` release.

@sashamatveev Thanks a lot. That all makes sense, and it seems to work indeed with the corrected position/length calculations.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3047688717

From lkostyra at openjdk.org  Tue Jul  8 12:06:53 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 8 Jul 2025 12:06:53 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Good work!

Reviewed the Metal-native-side of this commit (`native-prism-mtl` folder) and left some comments to talk through, nothing extremely major though. I'll verify the code on my side once we get closer to review completion.

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

> 1435:     [pCtx endCurrentRenderEncoder];
> 1436: 
> 1437:     id<MTLCommandBuffer> commandBuffer = [pCtx getCurrentCommandBuffer];

I think most of this function should become a `MetalContext` method that would be called here. That way we separate the Metal-related implementation from JNI entry points and it follows the pattern of other JNI entry points in this file.

modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m line 167:

> 165:         pipeState = [[context getPipelineManager] getPipeStateWithFragFunc:fragmentFunction
> 166:                                                              compositeMode:compositeMode];
> 167:         [psDict setObject:pipeState forKey:keyCompMode];

I am not 100% sure why there is a need to duplicate PipelineState dictionaries here and to create a Shader-specific cache of States. If you need to get a PipelineState, why not always directly call on `MetalPipelineManager`?

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 235:

> 233:     id<MTLCommandBuffer> commandBuffer = [context getCurrentCommandBuffer];
> 234:     @autoreleasepool {
> 235:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

Similarly to `MetalContext` comment, I think we should separate JNI entry point code and argument parsing/converting from actual Metal-reaching implementation. I would also move this to a `MetalTexture` method.

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 300:

> 298: 
> 299:     @autoreleasepool {
> 300:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

As above

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 364:

> 362: 
> 363:     @autoreleasepool {
> 364:         id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

As above

modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 407:

> 405: 
> 406:     @autoreleasepool {
> 407:         id<MTLDevice> device = [context getDevice];

As above

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-2961851748
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192155071
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192281270
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192317134
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192305858
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192306212
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192307217

From lkostyra at openjdk.org  Tue Jul  8 12:06:55 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 8 Jul 2025 12:06:55 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v4]
In-Reply-To: <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
Message-ID: <vV30OHb08gx26owOe_1_czcHd680PfVmlC3k-P3ycmQ=.51d079c1-8175-4ef9-8d6e-4d3c00622bbd@github.com>

On Wed, 25 Jun 2025 11:28:57 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:
> 
>   Use appropriate layer for setting opacity

modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.h line 78:

> 76:     id<MTLRenderCommandEncoder> phongEncoder;
> 77:     id<MTLRenderCommandEncoder> lastPhongEncoder;
> 78:     MetalShader* currentShader;

Might be my obj-C lack-of-knowledge - why some objects here use pointers, while others use `id<>`?

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

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

From andy.goryachev at oracle.com  Tue Jul  8 15:16:56 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 8 Jul 2025 15:16:56 +0000
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In-Reply-To: <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
Message-ID: <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>

I generally agree.  In this particular case, the distinction is clear and explained in the docs (perhaps it could be explained better, your suggestions are always welcomed).

The new names, I think, fit better: getCaretShape() are far better than getCaretShapeWithInsets (what insets?  why?  what makes insets so special?).

The proposed solution provides the new API without breaking the existing apps.  The apps can take their time to migrate to the new API in due course.  I believe we've done this in the past where things got deprecated but not for removal.

So I think this is a good compromise - things get fixed without immediately breaking the existing apps, a win-win.

Cheers,
-andy





From: Michael Strau? <michaelstrau2 at gmail.com>
Date: Monday, July 7, 2025 at 19:41
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In most cases, I would advise against having similarly-named methods
that exhibit different semantics. If the behavior of the existing
methods is indeed a bug (and not just different, but legitimate
semantics), then fixing that would be best. We've done breaking
changes in the past where appropriate, and expect applications to make
necessary changes in their API use when switching to a new version of
JavaFX. Always keeping old behavior around runs the risk of
fossilizing the API in the long run.

In rare cases, and especially when necessary changes would be more
involved, there's the option to hide the previous behavior behind a
system property. Setting a system property in lieu of changing code is
a low-effort option for applications that are not prepared to fix
their code just yet.

If we want to keep the old methods around indefinitely, another option
would be to make the new methods clearly different to indicate their
changed semantics.

For example, for the existing method `rangeShape(int, int)`, we could
add another method `rangeShapeWithLineSpacing(int, int)`. This makes
the semantics of the method abundantly clear to users, and keeps the
old method around. It also avoids the proposed boolean argument
`includeLineSpacing`, which is usually better API design.

As another example, the existing method `caretShape(int, boolean)`
could be paired with `caretShapeWithInsets(int, boolean)`.

My main criticism is that method pairings like `rangeShape` and
`getRangeShape` muddy the API waters. We'd never have done that, had
we thought about the correct semantics earlier. Evolving an API is
always hard, but the goal should be to have the new API fit well with
the existing API, as if it had been thought of from the beginning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250708/0feff1af/attachment-0001.htm>

From kevin.rushforth at oracle.com  Tue Jul  8 16:50:33 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 8 Jul 2025 09:50:33 -0700
Subject: [External] : Re: Enhanced Text/TextFlow APIs
In-Reply-To: <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CY8PR10MB726523BEC6E79CABE8221A7FE54FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAJEpuXR63FDKWKog13=FtWqc_TJHu1fX4OwD_9o9FQu-FWcu6w@mail.gmail.com>
 <CY8PR10MB7265E48948A4430A17A5EAD8E54EA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <2ba0c52a-8703-4fed-9272-e5a9c5412214@oracle.com>

I agree with Andy on this, provided that we explain it well. The 
proposed names are what I would have chosen in the first place, and by 
leaving the existing methods in place -- deprecated, but not for removal 
-- we avoid the very real possibility of introducing a regression. It 
isn't an ideal choice, but I think it's the best on in this case.

-- Kevin

On 7/8/2025 8:16 AM, Andy Goryachev wrote:
>
> I generally agree.? In this particular case, the distinction is clear 
> and explained in the docs (perhaps it could be explained better, your 
> suggestions are always welcomed).
>
> The new names, I think, fit better: getCaretShape() are far better 
> than getCaretShapeWithInsets (what insets?? why? what makes insets so 
> special?).
>
> The proposed solution provides the new API without breaking the 
> existing apps.? The apps can take their time to migrate to the new API 
> in due course.? I believe we've done this in the past where things got 
> deprecated but not for removal.
>
> So I think this is a good compromise - things get fixed without 
> immediately breaking the existing apps, a win-win.
>
> Cheers,
>
> -andy
>
> *From: *Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Monday, July 7, 2025 at 19:41
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Cc: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: Enhanced Text/TextFlow APIs
>
> In most cases, I would advise against having similarly-named methods
> that exhibit different semantics. If the behavior of the existing
> methods is indeed a bug (and not just different, but legitimate
> semantics), then fixing that would be best. We've done breaking
> changes in the past where appropriate, and expect applications to make
> necessary changes in their API use when switching to a new version of
> JavaFX. Always keeping old behavior around runs the risk of
> fossilizing the API in the long run.
>
> In rare cases, and especially when necessary changes would be more
> involved, there's the option to hide the previous behavior behind a
> system property. Setting a system property in lieu of changing code is
> a low-effort option for applications that are not prepared to fix
> their code just yet.
>
> If we want to keep the old methods around indefinitely, another option
> would be to make the new methods clearly different to indicate their
> changed semantics.
>
> For example, for the existing method `rangeShape(int, int)`, we could
> add another method `rangeShapeWithLineSpacing(int, int)`. This makes
> the semantics of the method abundantly clear to users, and keeps the
> old method around. It also avoids the proposed boolean argument
> `includeLineSpacing`, which is usually better API design.
>
> As another example, the existing method `caretShape(int, boolean)`
> could be paired with `caretShapeWithInsets(int, boolean)`.
>
> My main criticism is that method pairings like `rangeShape` and
> `getRangeShape` muddy the API waters. We'd never have done that, had
> we thought about the correct semantics earlier. Evolving an API is
> always hard, but the goal should be to have the new API fit well with
> the existing API, as if it had been thought of from the beginning.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250708/5988b371/attachment.htm>

From vdyakov at openjdk.org  Tue Jul  8 18:05:44 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 8 Jul 2025 18:05:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <snIlRRTOvjEd6LTdgLxDlmIfRp8TZDpCvWGfTTpz2JQ=.6c1e342b-368a-4a2d-b47b-5cc16064e94b@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

@andy-goryachev-oracle @arapte please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1840#issuecomment-3049844834

From angorya at openjdk.org  Tue Jul  8 18:15:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 18:15:49 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <bgDUVn04XduDIy9ySSB0Scw7qhSq0wSF-4T28OuWZ-4=.797b41f5-9db9-4622-93cf-6a6ab084b342@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Did a bit more digging in Eclipse:

1. the resource is in `javafx.graphics.jar` under correct path `com/sun/prism/mtl/msl/jfxshaders.metallib`
2. the class loader fails to locate it in BuildinClassLoader:findResourceAsStream() L293
because it tries to load the stream from the file system, not a jar.

Even after I add the dir with the resource to the `java.library.path`

-Djava.library.path="/Users/angorya/Projects/jfx3/jfx/rt/build/sdk/lib:/Users/angorya/Projects/jfx3/jfx/rt/build/modular-sdk/modules/javafx.graphics/com/sun/prism/mtl"


The reason is that eclipse is looking for the resources for the graphics module in
`rt/modules/javafx.graphics/bin` where the module classes are compiled to, and not in other places.

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

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

From kcr at openjdk.org  Tue Jul  8 19:04:49 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 19:04:49 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
Message-ID: <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>

On Fri, 20 Jun 2025 01:39:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
> 
>  - Merge branch 'master' into feature/media-queries
>  - Merge branch 'master' into feature/media-queries
>  - Merge branch 'master' into feature/media-queries
>  - use custom mediaFeature javadoc tag
>  - Merge branch 'master' into feature/media-queries
>  - fix wrong <br> HTML tags
>  - Merge branch 'master' into feature/media-queries
>  - doc
>  - reorder Scene.Preferences.colorScheme
>  - move doc from Scene.Preferences to Platform.Preferences
>  - ... and 40 more: https://git.openjdk.org/jfx/compare/fc4642db...b01f0414

The API changes look good. The cssref docs and the class docs for the new Scene.Preferences class look good. The one problem I see is that the `@mediaFeature` javadoc tag doesn't render anything, at least not when I run `gradle javadoc` using the default JDK 24.

You might need to revert this change and link to the cssref manually.

I note that the CSR spec was done before this change, so depending on how you resolve this, the spec should be regenerated.

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:

> 615:          *
> 616:          * @return the {@code persistentScrollBars} property
> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>

I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).

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

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2998731760
PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193197562

From kcr at openjdk.org  Tue Jul  8 20:29:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 20:29:59 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
Message-ID: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
> 
> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.

Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
 - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
 - set gradle version min to 8.10.2
 - 8359387: Bump minimum JDK version for JavaFX to JDK 23

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

Changes: https://git.openjdk.org/jfx/pull/1827/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1827&range=01
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1827.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1827/head:pull/1827

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

From mstrauss at openjdk.org  Tue Jul  8 20:32:51 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 20:32:51 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
Message-ID: <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>

On Tue, 8 Jul 2025 18:32:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:
>> 
>>  - Merge branch 'master' into feature/media-queries
>>  - Merge branch 'master' into feature/media-queries
>>  - Merge branch 'master' into feature/media-queries
>>  - use custom mediaFeature javadoc tag
>>  - Merge branch 'master' into feature/media-queries
>>  - fix wrong <br> HTML tags
>>  - Merge branch 'master' into feature/media-queries
>>  - doc
>>  - reorder Scene.Preferences.colorScheme
>>  - move doc from Scene.Preferences to Platform.Preferences
>>  - ... and 40 more: https://git.openjdk.org/jfx/compare/fc4642db...b01f0414
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:
> 
>> 615:          *
>> 616:          * @return the {@code persistentScrollBars} property
>> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>
> 
> I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).

That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.

So it seems like we have several options:
1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
3. Don't use a custom javadoc tag at all.

I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193389437

From mstrauss at openjdk.org  Tue Jul  8 20:39:48 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 20:39:48 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
Message-ID: <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>

On Tue, 8 Jul 2025 20:30:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 617:
>> 
>>> 615:          *
>>> 616:          * @return the {@code persistentScrollBars} property
>>> 617:          * @mediaFeature <a href="../scene/doc-files/cssref.html#mediafeatures">{@code -fx-prefers-persistent-scrollbars}</a>
>> 
>> I note that this tag seems to be ineffective (perhaps because this is a property and gets special javadoc treatment).
>
> That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.
> 
> So it seems like we have several options:
> 1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
> 2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
> 3. Don't use a custom javadoc tag at all.
> 
> I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.

I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193400531

From kcr at openjdk.org  Tue Jul  8 20:40:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 20:40:44 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23
In-Reply-To: <3u6WMk3UjdyP3ccVO-ZFk_JPI-Mg4O-dT4LeSpuQvUk=.0034a9e5-8827-4562-9f07-9eb335129f97@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <3u6WMk3UjdyP3ccVO-ZFk_JPI-Mg4O-dT4LeSpuQvUk=.0034a9e5-8827-4562-9f07-9eb335129f97@github.com>
Message-ID: <J06eGVpGOE1MQpSXy9VYypGnB3SNLjnNrFfcPl-4nxk=.cd1e0384-5db5-4d5c-a95c-b52e432b2a8b@github.com>

On Wed, 18 Jun 2025 17:26:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I will also need to merge master some time after #1832 is integrated, since there will be a (trivial) merge conflict for me to resolve.

This is now merged. The trivial conflict was in the surrounding context, not the diffs themselves.

@tiainen @arapte Can you re-review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1827#issuecomment-3050239003

From almatvee at openjdk.org  Tue Jul  8 20:58:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 8 Jul 2025 20:58:43 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v2]
In-Reply-To: <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>
Message-ID: <HONVxy6EdI1qlqte7zvVjtskITPnXTIfGNsRVWswWAc=.7a0eea44-8efc-4c74-ae92-d33b6f4492fc@github.com>

On Tue, 8 Jul 2025 07:26:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Process reviewer comments
>   Add null checks
>   Fix errors in position and length calculations

modules/javafx.media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm line 331:

> 329:         CJavaInputStreamCallbacks *callbacks = new (nothrow) CJavaInputStreamCallbacks();
> 330:         jobject jConnectionHolder = CLocator::CreateConnectionHolder(env, jLocator);
> 331:         if (callbacks == NULL  || jConnectionHolder == NULL) {

Extra space after `callbacks == NULL`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2193427264

From kcr at openjdk.org  Tue Jul  8 21:11:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 21:11:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
Message-ID: <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>

On Tue, 8 Jul 2025 20:37:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> That's correct, the javadoc tool copies javadocs from the property field to its accessor methods. But it doesn't do a throrough job: it only copies standard tags and a few custom tags (`@defaultValue` for example). I think that's either a bug or a missing feature of the javadoc tool. I can't find a single example where it would be useful to _not_ copy a javadoc tag from the property field to its accessor methods.
>> 
>> So it seems like we have several options:
>> 1. Keep the custom `@mediaFeature` tag in JavaFX, and file an enhancement with the javadoc tool to copy _all_ tags to property accessors. Then the media feature tags would start to show up in generated docs once the javadoc enhancement is in.
>> 2. File an enhancement, but only start using the `@mediaFeature` tag once javadoc is fixed.
>> 3. Don't use a custom javadoc tag at all.
>> 
>> I would prefer option 1, because it is the most structured form of documentation, and doesn't require us to come back later. In general, custom javadoc tags are a very useful feature to present structured information, and I think we should prefer it to prose.
>
> I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.

Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.

I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193441226

From kcr at openjdk.org  Tue Jul  8 21:11:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 21:11:52 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
 <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
Message-ID: <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>

On Tue, 8 Jul 2025 21:05:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I notice that I've described the behavior of the javadoc tool for property fields, but this is a property method. However, my conclusion is the same: not rendering custom tags is a bug in the tool.
>
> Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.
> 
> I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.

Whichever option you decide, update the CSR to match. Then I'll Review the CSR and you can finalize it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193446590

From mstrauss at openjdk.org  Tue Jul  8 21:27:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:27:06 GMT
Subject: RFR: 8345348: CSS media feature queries [v35]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <0Lu1396k5Dan8mVuMmowdrsnmJJws7NwNwjSRHWduz4=.07bedb53-f9ca-481c-9132-3113b596faf5@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

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

  documentation changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/b01f0414..9405d47a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=34
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=33-34

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

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

From angorya at openjdk.org  Tue Jul  8 21:31:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 21:31:54 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:

> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];

this change seems unrelated - is it a part of some other work?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193474924

From angorya at openjdk.org  Tue Jul  8 21:40:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 21:40:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

Like this very much, a good cleanup.

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 99:

> 97: }
> 98: 
> 99: - (jobject)getJAccessible {

should this K&R brace be reverted to the _objectively better_ style used elsewhere in this file?

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 113:

> 111:     GET_MAIN_JENV;
> 112:     if (env == NULL) return NULL;
> 113:     jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible],

not an expert, but do we really need to initialize `jresult` to NULL in line 110?
can the variable be declared in line 113 ?

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:

> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
> 190:     id s = [self requestNodeAttribute:@"AXSize"];
> 191:     if (p == NULL || s == NULL) {

not a big issue, but would it be (marginally) better to bail out early if p == NULL ?

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

PR Review: https://git.openjdk.org/jfx/pull/1840#pullrequestreview-2999152480
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193476993
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193479120
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193484839

From mstrauss at openjdk.org  Tue Jul  8 21:44:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:44:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

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

  documentation changes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1655/files
  - new: https://git.openjdk.org/jfx/pull/1655/files/9405d47a..0feee0dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=35
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=34-35

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

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

From mstrauss at openjdk.org  Tue Jul  8 21:44:35 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 8 Jul 2025 21:44:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v34]
In-Reply-To: <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <lvPvoFR7ESf9G9b4KD3pBe78ohUBLYUG1c0tmigUCcs=.807be71b-7d75-4912-86ff-32583a35670f@github.com>
 <bTuxF6NBNGPnSH2ko0ATk6ndC8UY34sUPedKc7Lv_aY=.b9a5ca82-e8a0-4969-9280-3088494846da@github.com>
 <mj28Ry5MLDqL5xhs28zmCBGucWI9I5asU0auaMy1j8w=.fba687ec-d8a8-4639-93f0-9035fd357f8c@github.com>
 <AifMQO0AbIYsmRcK0twYTYOs0WVh-fgUCU5UgO-ThPM=.65b99496-d59d-4bdd-b2f9-4b90c4c19a97@github.com>
 <9r63rL4Tlp0_0Fw0WYlo6IBraJjpJ5eN57vmHWH31ME=.5629796e-a09f-4609-8eed-f1502a5fee46@github.com>
 <zBH5BQSVrvNrN3sW4_wF5TN3R8JMtiPbyPkFqBb7yRw=.a109ce34-23ba-47dc-bd4f-731f7357bcf7@github.com>
Message-ID: <-E8Wn5Rgmy1xJzzxsdSuwOEIJr08d6EpltqTWlEhWXM=.382f2ab9-60bd-450f-aa87-14ee5b47b947@github.com>

On Tue, 8 Jul 2025 21:08:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Very likely this is a javadoc limitation. I don't know how likely it will be to get it fixed, but it would be no earlier than in JDK 26, which means that it would be (at least) JavaFX 27 before it started working. That makes option 1 less attractive.
>> 
>> I would probably recommend option 2. Otherwise, we won't see any reference to media feature queries in the Preferences doc any time soon.
>
> Whichever option you decide, update the CSR to match. Then I'll Review the CSR and you can finalize it.

I've updated the CSR to match.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2193489323

From angorya at openjdk.org  Tue Jul  8 22:00:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 22:00:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <ZPxk2BzO6aSkRjKdhLzzcWm_C-YLmnu0cZaTjfTgriE=.c29db434-699d-4836-88b6-2523deb1d112@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

I don't see any obvious issues in the monkey tester with the Logging -> Accessibility enabled.

Here, for example, what it logs for the focusable label:


{time:1752011850468, log:"accessibility", "TEXT":""[?????????\n????????\n?????]""}
{time:1752011850468, log:"accessibility", "ROLE":""TEXT""}
{time:1752011850468, log:"accessibility", "LABELED_BY":"null"}

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

PR Comment: https://git.openjdk.org/jfx/pull/1840#issuecomment-3050405287

From angorya at openjdk.org  Tue Jul  8 22:16:48 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 8 Jul 2025 22:16:48 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
Message-ID: <zUMr9hYfrUk9y-8eQyqszlDdg11IcSuCWe_XzHcUcwY=.0eb96daf-17a6-48e5-923d-e9c20117bec9@github.com>

On Tue, 8 Jul 2025 21:44:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation changes

#mediafeatures works from `Platform.Preferences` and `Scene.Preferences`

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-2999219850

From kcr at openjdk.org  Tue Jul  8 23:17:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:17:43 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
Message-ID: <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>

On Wed, 18 Jun 2025 18:34:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This doesn't read like a proper English sentence to me. In Microsoft Word, there's a spinner control titled "Default tab stops:", which I suppose should be read as, for example: "Default tab stops every 0.5 cm".
>> 
>> As for naming the API, I suggest something like `defaultTabWidth` or `defaultWidth` (the word "tab" doesn't need to be repeated, as it's declared in a class named `TabStopPolicy`).
>
> Not sure if defaultTabWidth is a good choice here though, because it's not, it's actually tab stops - think of the typewriter (I know, referring to an ancient technology like floppy disk for the 'save' icon does not age well)
> 
> I am open to suggestions.  I am used to "default tab stops", perhaps we could just explain it better?

Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?

If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:

- defaultStop
- defaultStops
- defaultStopInterval
- Something Else?

I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2193588491

From kcr at openjdk.org  Tue Jul  8 23:17:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:17:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v3]
In-Reply-To: <nocHjNTQqEskrC0ITlVfvuXPe4T1duTPkjmU2K4ZtO4=.04991ab9-8d33-4dea-928e-a9faaecabfe3@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <-ZPztHXde-v0OE43I-uHgjVMVyfM21fOfUWMprMgKjY=.6fa6969c-d162-49b7-8ca4-814f561319e4@github.com>
 <8kn9gHv11OUy41PcmhSXbjWYNgiObaSk2IDCzuzda30=.47cfe6ff-7ce8-41f7-af68-cfff2e30f115@github.com>
 <nocHjNTQqEskrC0ITlVfvuXPe4T1duTPkjmU2K4ZtO4=.04991ab9-8d33-4dea-928e-a9faaecabfe3@github.com>
Message-ID: <yH2vBtFeveTuTsrQd6YgBdMdCT9K6TEzeHLlHxohqt8=.80361439-8031-4785-848e-842bda854fdd@github.com>

On Wed, 18 Jun 2025 18:41:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 67:
>> 
>>> 65:      *
>>> 66:      * @return the default tab stops property
>>> 67:      * @defaultValue 0
>> 
>> Would "8" be a better default value? I think having tabs do something (instead of effectively being ignored) by default when you create a TabStopPolicy would be less surprising to app developers.
>
> No, this value is in pixels (unlike the `tabSize` property).  I think it's better to let the application specify it explicitly.

OK, this seems like a good reason to leave it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2193589109

From kcr at openjdk.org  Tue Jul  8 23:42:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 8 Jul 2025 23:42:44 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <R6qFiECAE_QgIUUSPgauBfJIDzlBj_gpxSt_yGWf0qc=.909d7af1-5ffd-45b2-a4be-077d2a68f092@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I left a couple doc comments inline. I'm left wondering if we should do the same thing in Text that you are doing in TextFlow. Namely, deprecate the following four methods, adding getXxxxx methods as replacements:

- hitTest
- caretShape
- rangeShape
- underlineShape

Unlike TextFlow, there is no functional reason we need to do it. So the question is one of consistency. I note that you are already adding one of the four, getRangeShape (to add the lineSpacing parameter). What do you think?

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1092:

> 1090:      * Returns the shape for the range of the text in local coordinates.
> 1091:      * <p>
> 1092:      * NOTE: this shapes returned do not include line spacing.

I would remove the "NOTE:", making it a simple statement (and probably no need for the `<p`> tag), since this is just what the method does.

Question: should this method be deprecated to be consistent with TextFlow?

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 197:

> 195:      * Maps local point to {@link HitInfo} in the content.
> 196:      * <p>
> 197:      * NOTE: this method may return incorrect value with non-empty border or padding.

You should be more explicit, and say that it will not take border or padding into account.

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

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-2999329020
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2193621878
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2193603871

From arapte at openjdk.org  Wed Jul  9 00:04:42 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 9 Jul 2025 00:04:42 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
Message-ID: <kbzmI6yvwEmDjrWcqwYeviRA8a_-rDdpLu4VybFOGyc=.6439b6f1-c272-462e-b82a-39a8c1371a88@github.com>

On Tue, 8 Jul 2025 20:29:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
>> 
>> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
>> 
>> This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
>> 
>> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - set gradle version min to 8.10.2
>  - 8359387: Bump minimum JDK version for JavaFX to JDK 23

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-2999398915

From kizune at openjdk.org  Wed Jul  9 04:18:47 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:18:47 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
Message-ID: <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>

On Tue, 8 Jul 2025 21:29:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:
> 
>> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
>> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
>> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];
> 
> this change seems unrelated - is it a part of some other work?

When i implemented radio buttons one of the roles this implementation was supposed to fulfill was tab button for the tabbed pane. But without the new implementation of Tab Group it did not work - focus was funky and announcement was not correct. So i commented out this role assignment. When i pushed Tab Group implementation i haven't uncommented this line so now since i do clean up and refactoring on this exact file i tested that now it works properly and uncommented it. Just trying not to spawn too many pull requests for the minimal changes.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193974994

From kizune at openjdk.org  Wed Jul  9 04:23:30 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:23:30 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v2]
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <2HiCNXyevx9srfL4T22am5Vqiej_ZrnG7UY73MHggKc=.07fa1488-b65b-4d43-8c01-3e9aec10dcff@github.com>

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

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

  Reverting the curly bracket placement

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1840/files
  - new: https://git.openjdk.org/jfx/pull/1840/files/92c74cbf..9bee13ac

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

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

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

From kizune at openjdk.org  Wed Jul  9 04:23:31 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 04:23:31 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v2]
In-Reply-To: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
Message-ID: <A6-YBNHxfxmYgIjIhUHXUTGG0o1o1GCz24Zi8U8Aerw=.f0eb8a91-c614-460b-a89a-a50a02fa833e@github.com>

On Tue, 8 Jul 2025 21:31:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting the curly bracket placement
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 99:
> 
>> 97: }
>> 98: 
>> 99: - (jobject)getJAccessible {
> 
> should this K&R brace be reverted to the _objectively better_ style used elsewhere in this file?

I would object to objectively - i think this is subjective - but sure, i will fix that :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2193978982

From kizune at openjdk.org  Wed Jul  9 05:01:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 05:01:14 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

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

  Remove explicit jresult declaration

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1840/files
  - new: https://git.openjdk.org/jfx/pull/1840/files/9bee13ac..3609f528

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

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

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

From kizune at openjdk.org  Wed Jul  9 05:01:15 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 05:01:15 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <iuVZAF7d4V_1HkDGNe9ld06S6JBJFGPJ4Ah57iHa-e0=.2c975b62-9c13-4deb-97fe-f68be316f2a5@github.com>
Message-ID: <vsLA4sNMv4Rdz-uUkDAnS1YTqCQOmCMBjy9fgEqZwHM=.e023ec84-ad7b-499b-9325-e29fc9fc9bce@github.com>

On Tue, 8 Jul 2025 21:33:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove explicit jresult declaration
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 113:
> 
>> 111:     GET_MAIN_JENV;
>> 112:     if (env == NULL) return NULL;
>> 113:     jresult = (jobject)(*env)->CallLongMethod(env, [self getJAccessible],
> 
> not an expert, but do we really need to initialize `jresult` to NULL in line 110?
> can the variable be declared in line 113 ?

Well this pattern was used to initialize the result value to the default return value so if assignment does not happen due to the Java exception we have something meaningful to return but in case of NULL it is not really required because it will produce the same result anyways.

> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:
> 
>> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
>> 190:     id s = [self requestNodeAttribute:@"AXSize"];
>> 191:     if (p == NULL || s == NULL) {
> 
> not a big issue, but would it be (marginally) better to bail out early if p == NULL ?

But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2194014740
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2194018393

From sykora at openjdk.org  Wed Jul  9 06:14:45 2025
From: sykora at openjdk.org (Joeri Sykora)
Date: Wed, 9 Jul 2025 06:14:45 GMT
Subject: RFR: 8359387: Bump minimum JDK version for JavaFX to JDK 23 [v2]
In-Reply-To: <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
 <ryStWoTI7Loe4LlHp5GFqv36iXS_2LlyrzcjpzsbB70=.8c11be37-a86e-428e-bd0b-7433ab9b125f@github.com>
Message-ID: <laMQ0r73dyBS_bEt-NlwlHBkgX4gq0i1C6zKLLre_vY=.bb06a02f-2c21-44a2-b620-835520c576d8@github.com>

On Tue, 8 Jul 2025 20:29:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
>> 
>> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
>> 
>> This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
>> 
>> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.
>
> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - Merge remote-tracking branch 'upstream/master' into 8359387-min-jdk-23
>  - set gradle version min to 8.10.2
>  - 8359387: Bump minimum JDK version for JavaFX to JDK 23

Marked as reviewed by sykora (Author).

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

PR Review: https://git.openjdk.org/jfx/pull/1827#pullrequestreview-3000131274

From angorya at openjdk.org  Wed Jul  9 14:59:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 14:59:46 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
Message-ID: <TB0f9Q6iQbUuu4vq59d75kVEWm9w0_iBO_jUUbm6KJE=.d349443b-4841-4a06-8374-a36dca40400a@github.com>

On Wed, 9 Jul 2025 05:01:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove explicit jresult declaration

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1840#pullrequestreview-3001910165

From angorya at openjdk.org  Wed Jul  9 14:59:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 14:59:47 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
Message-ID: <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>

On Wed, 9 Jul 2025 04:15:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 50:
>> 
>>> 48:     [rolesMap setObject:@"JFXButtonAccessibility" forKey:@"SPLIT_MENU_BUTTON"];
>>> 49:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"RADIO_BUTTON"];
>>> 50:     [rolesMap setObject:@"JFXRadiobuttonAccessibility" forKey:@"TAB_ITEM"];
>> 
>> this change seems unrelated - is it a part of some other work?
>
> When i implemented radio buttons one of the roles this implementation was supposed to fulfill was tab button for the tabbed pane. But without the new implementation of Tab Group it did not work - focus was funky and announcement was not correct. So i commented out this role assignment. When i pushed Tab Group implementation i haven't uncommented this line so now since i do clean up and refactoring on this exact file i tested that now it works properly and uncommented it. Just trying not to spawn too many pull requests for the minimal changes.

does it mean we missed something during the testing, something was supposed to work and did not?

since there will be more a-y work, I think it should be ok.

>> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 191:
>> 
>>> 189:     id p = [self requestNodeAttribute:@"AXPosition"];
>>> 190:     id s = [self requestNodeAttribute:@"AXSize"];
>>> 191:     if (p == NULL || s == NULL) {
>> 
>> not a big issue, but would it be (marginally) better to bail out early if p == NULL ?
>
> But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.

but it will save a couple of nanoseconds!

the code is ok.  one question though: what are the circumstances when these calls would return NULL?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195249304
PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195244238

From angorya at openjdk.org  Wed Jul  9 15:28:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:28:08 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v3]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
 - Merge branch 'master' into 8341438.text.shapes.insets
 - cleanup
 - Merge branch 'master' into 8341438.text.shapes.insets
 - layout info
 - tests
 - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
 - cleanup
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - ... and 62 more: https://git.openjdk.org/jfx/compare/639a5950...16ed27eb

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

Changes: https://git.openjdk.org/jfx/pull/1817/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=02
  Stats: 556 lines in 5 files changed: 522 ins; 18 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817

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

From angorya at openjdk.org  Wed Jul  9 15:28:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:28:08 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v2]
In-Reply-To: <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <ruSuB3FNLdJQ618Tfakh56kCCB3Tb8GXc6MOKcOxFL0=.7c5420ca-dff6-4bb6-a958-d6f5e5414697@github.com>
Message-ID: <o5bPPpAytstOHPWlkBoFlQGnbkIy2AMkGY0uIwTOvWA=.19f9150f-628c-4076-b6a0-2e0fd04cc93e@github.com>

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

> Question: should this method be deprecated to be consistent with TextFlow?

> Namely, deprecate the following four methods, adding getXxxxx methods as replacements

I am open to suggestions, but currently leaning toward leaving `Text` as is.  As you correctly mentioned, it is not functionally required, and would only add more noise.

I feel making `Text` such a heavy object (with properties and all) might have been a design mistake: it would have been much better to use `TextFlow` everywhere, including `Labels`, `TextFields`, and `TextAreas`, and use `Text` as immutable objects similar to `GlyphList` to store runs of characters with the same font and attributes.  Doing so might have allowed easy introduction of rich text into these controls too, but oh well.

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3053071927

From angorya at openjdk.org  Wed Jul  9 15:32:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:32:45 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
Message-ID: <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>

On Tue, 8 Jul 2025 23:11:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Not sure if defaultTabWidth is a good choice here though, because it's not, it's actually tab stops - think of the typewriter (I know, referring to an ancient technology like floppy disk for the 'save' icon does not age well)
>> 
>> I am open to suggestions.  I am used to "default tab stops", perhaps we could just explain it better?
>
> Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?
> 
> If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:
> 
> - defaultStop
> - defaultStops
> - defaultStopInterval
> - Something Else?
> 
> I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.

ooh, I like `defaultStopInterval`, thank you.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195324654

From kizune at openjdk.org  Wed Jul  9 15:45:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 9 Jul 2025 15:45:52 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
 <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
Message-ID: <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>

On Wed, 9 Jul 2025 14:54:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> But that would require two conditions - one for position and one for size - with the same logic which would look not that compact and pretty.
>
> but it will save a couple of nanoseconds!
> 
> the code is ok.  one question though: what are the circumstances when these calls would return NULL?

1. Custom component that has no role assigned at all
2. Exception happens on Java side processing the request
That was just two popped out - probably there are more scenarios.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195351917

From angorya at openjdk.org  Wed Jul  9 15:48:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 15:48:44 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <1u-hYthxiNr8QHU8vRjQtXJ7lwJJOkW6bBAYFJLI2Cg=.02259fa9-0509-4ede-9a67-27b28d7e1dd3@github.com>
 <J1gCbq1TXhP3UPCEuwfYJUE8_63teSka_mRqpUAwElY=.0c103254-5ef6-438d-863f-a5ef7e676fad@github.com>
 <fwN0ngbPGOqRGMBoQZ2-o-j7mvJsDAzanc6hGbaQg9Y=.ea1cc3a9-684e-49b1-af5e-f6cfdcf313bf@github.com>
 <oUlLIf0-Fkun2HScEW4Tch4tzcI0Eeuy7BGjAgVFTfE=.9f486255-9452-43b2-be1f-f82a01a768be@github.com>
Message-ID: <W32hyd3XbTskT5hfipOvWeqrM3E55BcegN9b-do3Tqk=.3e1a427e-d199-4755-98fb-fc92a45286f2@github.com>

On Wed, 9 Jul 2025 15:43:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> but it will save a couple of nanoseconds!
>> 
>> the code is ok.  one question though: what are the circumstances when these calls would return NULL?
>
> 1. Custom component that has no role assigned at all
> 2. Exception happens on Java side processing the request
> That was just two popped out - probably there are more scenarios.

right, thank you for clarification!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1840#discussion_r2195358693

From mfox at openjdk.org  Wed Jul  9 17:23:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 9 Jul 2025 17:23:48 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

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

> 8652:      * @since 26
> 8653:      */
> 8654:     Node getFocusDelegate(Node hoistingNode) {

I tried to tweak the InputMethodStateManager to deal with delegates and discovered there?s no easy way to get a node?s delegate. Shouldn?t there be a public way of retrieving the current delegate?

I don?t think getFocusDelegate should take a parameter. If I was creating a node with multiple focus delegates I would probably want to track the current one in some simple way. But getFocusDelegate doesn?t allow me to do that, I always have to respect the hoisting node parameter being passed in and dig through my descendant nodes to figure out which delegate is being requested. And it implies the only way to change the delegate is to requestFocus on the new delegate and take it through the hoisting process. That seems overly restrictive. I can see why a focus scope node would need to know which node hoisted focus but only at the time the hoist happens.

We?re spending a lot of time thinking about controls that may have more than one delegate. I really doubt anyone will ever create one. If they do it raises a bunch of questions related to accessibility and keyboard traversal that we?re not even discussing.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2195566726

From mstrauss at openjdk.org  Wed Jul  9 17:26:44 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 9 Jul 2025 17:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
 <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
Message-ID: <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>

On Wed, 9 Jul 2025 15:29:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Getting back to this, there are two naming questions here. First, should "tab" be in the name (it does seem a bit redundant, since the name of the class is TabStopPolicy)? Second, what is the best name for the value that defines a repeating set of stops?
>> 
>> If we drop the word "tab" the list of tab stops would just be named "stops", which seems fine. Here are some possible names for the default:
>> 
>> - defaultStop
>> - defaultStops
>> - defaultStopInterval
>> - Something Else?
>> 
>> I kind of like the last of these, `defaultStopInterval`, as it is the most descriptive. Whatever we do will need to be documented well.
>
> ooh, I like `defaultStopInterval`, thank you.

Maybe make it even shorter and do `TabStopPolicy.defaultInterval`. The reasoning for dropping the "stop" is the same as before, it's already the class name.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195577224

From angorya at openjdk.org  Wed Jul  9 17:26:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 17:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v2]
In-Reply-To: <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <uxXQUmfa3S4jkzEKjPZ44t0oGgDPulZ_93K9FIj23lQ=.e86a4575-7390-48aa-9da8-5cb9d4a077a1@github.com>
 <V0iRICbS3-pzANYrq05pXS4ILRIbgVxdQHquQXuWdrE=.141476ba-793f-4eff-abc9-2527d802a7e8@github.com>
 <fqHwmRCXPd5oj6zsHRY7To-IuraHFnaFV5Y4jImjD2Y=.203f1b26-cd5c-4279-9bbd-b685c18974e3@github.com>
 <GHCHp8Cy01UgC46nCyIH0oG3Dyfoj_tQ22UpNWd1-aQ=.2d5ecee6-2003-43e9-868f-49e06e0da471@github.com>
 <6zcqoKa3kn0Y5xDuVs3ZOotMag_Pmg62Ba60RShIHDo=.ac38509d-64ae-4c3a-b31f-c6628ed78332@github.com>
 <yR26ktod2slXfDfNd_vdjUfkwlGisD2FoxcpWKAksgg=.5abc4c38-5d38-475f-bf7e-f6e7d77ceb9a@github.com>
 <GqP-j1kLfFvQIz1qOu-b8WZr6Nm76SHhpyNGrWS2Wv8=.c12aa33d-de35-42e4-a234-8aac5ace921c@github.com>
 <3PsBocUacz2AKtUIyI3TaZeVEKuJ77fEXQS47sZJ_B0=.0170a96b-1f3a-4223-87e7-2f9efa562f09@github.com>
 <de5HZNL7E_LFPaiCAAwq9EIYgpuYclz70cjdOpbIZuM=.39824280-be04-40f7-9b02-3445f1168f68@github.com>
Message-ID: <k8aIfFL2dOKojstwMmILEPg543D0FErbJBTnnShxtz4=.429c4efe-f290-49c4-bed1-13d2135cbe1d@github.com>

On Wed, 9 Jul 2025 17:23:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> ooh, I like `defaultStopInterval`, thank you.
>
> Maybe make it even shorter and do `TabStopPolicy.defaultInterval`. The reasoning for dropping the "stop" is the same as before, it's already the class name.

even better!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195584151

From kcr at openjdk.org  Wed Jul  9 19:53:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 19:53:43 GMT
Subject: Integrated: 8359387: Bump minimum JDK version for JavaFX to JDK 23
In-Reply-To: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
References: <c6Keg-sVC5l8k04vIlXNRa5xdp3UmabB-5w67e9t3fI=.b9cd6a72-bb0c-4edd-92a7-54dafb5bdca4@github.com>
Message-ID: <dbOMghB98Q-nOtPd_qnNt-uB_Rikkg-m0kKGMqis5sI=.e548f1c3-99d2-4efb-b1a6-5490f9bddd80@github.com>

On Fri, 13 Jun 2025 17:57:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR bumps the minimum version of the JDK needed to run JavaFX to JDK 23.
> 
> In order for JavaFX to be able to use more recent JDK features, we should increase the minimum version of the JDK that can run the latest JavaFX. Additionally, there is an ongoing cost to keeping JavaFX buildable and runnable on older versions of Java, and little reason to continue to do so.
> 
> This continues our recent practice of setting the minimum JDK for JavaFX N to JDK N-2. JavaFX N is primarily intended for use with JDK N and we also build and test it against JDK N-1 (which is typically what we use as the boot JDK). Anything older than that, including the proposed minimum JDK N-2 (23 in this specific case), is untested.
> 
> This PR targeted to JavaFX 25, and must not be backported to any earlier version. This needs a CSR and a release note.

This pull request has now been integrated.

Changeset: 6029e3e4
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6029e3e4058e2a87ecb0f5c07689f7d4783a1c65
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8359387: Bump minimum JDK version for JavaFX to JDK 23

Reviewed-by: arapte, sykora

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

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

From kcr at openjdk.org  Wed Jul  9 20:23:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:23:48 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v3]
In-Reply-To: <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <Yc-XapZXvW91BUSLomVPWoaJv2FP5r9ARe0CfFxIycM=.5689ac87-29e2-4e41-885e-36b208af286f@github.com>
Message-ID: <qFeFAkZiFnUkAPsls873lia9f-Hu_4VNHC94Hgt3fn0=.29f9a430-48e4-4cfd-ac20-e472c781b3bb@github.com>

On Wed, 9 Jul 2025 15:28:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 62 more: https://git.openjdk.org/jfx/compare/639a5950...16ed27eb

The API and docs look good to me now. I left a minor formatting suggestion for the deprecated methods (use `@link` to point to the replacement methods).

Update the CSR to match, and I'll Review it.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 202:

> 200:      * @return a {@code HitInfo} representing the character index found
> 201:      * @since 9
> 202:      * @deprecated replaced by {@code getHitInfo()}

I recommend `@link` here.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 245:

> 243:      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
> 244:      * @since 9
> 245:      * @deprecated replaced by {@code getCaretShape()}

`@link` (here and in. other deprecated methods).

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

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-3002944702
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2195889785
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2195894529

From angorya at openjdk.org  Wed Jul  9 20:27:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:27:07 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - since 25
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - cleanup
 - api
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

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

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=05
  Stats: 588 lines in 12 files changed: 558 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Wed Jul  9 20:34:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:34:21 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v4]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <9q1cNyuoXi0Zz0xlESAO8QIg-IkhO-hb1_uOKZTQdw8=.b626ca6d-f1b8-42f8-8e1d-9143fb2212d9@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  link

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1817/files
  - new: https://git.openjdk.org/jfx/pull/1817/files/16ed27eb..d466ebc9

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

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

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

From kcr at openjdk.org  Wed Jul  9 20:47:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:47:51 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
Message-ID: <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>

On Wed, 9 Jul 2025 20:27:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - cleanup
>  - api
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

APi looks good with one question and a few working suggestions.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 54:

> 52:      * @return the non-null list of tab stops
> 53:      */
> 54:     public final ObservableList<TabStop> tabStops() {

Did you consider also dropping "tab" from the name here? Either is fine with me, so I'll leave it up to you.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 61:

> 59:      * Specifies the default tab stop interval (beyond the last tab stop provided by {@code #tabStops()}),
> 60:      * as a fixed repeating distance (in pixels) to the next tab stop computed at regular intervals
> 61:      * relative to the leading edge of the {@code TextFlow} node.

This is a bit of a run-on sentence. Maybe consider breaking it up into two sentences, with the detail about "a fixed, repeating distance..." in the second sentence? Something like:


    * Specifies the default tab stop interval for tabs beyond the last stop provided
    * by {@code #tabStops()}. This is a fixed repeating distance (in pixels) to the
    * next tab stop computed at regular intervals relative to the leading edge
    * of the {@code TextFlow} node.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 531:

> 529:      * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> 530:      * with different fonts are contained within this {@code TextFlow}.
> 531:      * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.

either drop the word "the" before "setTabStopPolicy" or add "method" after.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 569:

> 567: 
> 568:     /**
> 569:      * {@code TabStopPolicy} determines the tab stop positions within this {@code TextFlow}.

I think you can remove `{@code TabStopPolicy}` since that's what this property is. Start with "Determines the ..."

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

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3003009745
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195925106
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195927394
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195934301
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195937805

From angorya at openjdk.org  Wed Jul  9 20:48:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 20:48:04 GMT
Subject: RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(),
 rangeShape() with non-empty padding/border [v5]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  javadoc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1817/files
  - new: https://git.openjdk.org/jfx/pull/1817/files/d466ebc9..a2099f02

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

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

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

From kcr at openjdk.org  Wed Jul  9 20:50:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 20:50:46 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
Message-ID: <FgYaYhly6ot92G9LvvRy0ejnqcxXy_1mVL9Go1240vs=.d596ad30-5560-46d1-a9b1-6c516233a1b9@github.com>

On Wed, 9 Jul 2025 20:27:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
> 
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - cleanup
>  - api
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 68:

> 66:      * @defaultValue 0
> 67:      */
> 68:     public final DoubleProperty defaultInterval() {

Oops. This should be `defaultIntervalProperty()`, which explains the GHA build failure.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195944153

From angorya at openjdk.org  Wed Jul  9 21:08:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:08:00 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v7]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  oops

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1744/files
  - new: https://git.openjdk.org/jfx/pull/1744/files/00bcf4b0..9851c92d

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

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

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

From angorya at openjdk.org  Wed Jul  9 21:08:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:08:01 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v6]
In-Reply-To: <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <po1EhcSmDpgbNpbe4Kw-tCeF8xtIYiIRHS2cu7V6Wps=.af5060ba-f798-4cf9-8561-d6e5109d199a@github.com>
 <eNE4aKNFEBWcAIxqnDGAq-tvAC12l9Ld7ejd6IJB5DA=.6fe93fd4-5fc8-45a7-a33b-6cddf3dd5016@github.com>
Message-ID: <Wr3pnip9yAWQ-EvetuN_3P3apHTQJqezzR-FQpIXLrc=.458ad2b7-e14a-4343-978a-123349c13892@github.com>

On Wed, 9 Jul 2025 20:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:
>> 
>>  - since 25
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - final tab stop
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - cleanup
>>  - api
>>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>>  - ... and 52 more: https://git.openjdk.org/jfx/compare/639a5950...00bcf4b0
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 54:
> 
>> 52:      * @return the non-null list of tab stops
>> 53:      */
>> 54:     public final ObservableList<TabStop> tabStops() {
> 
> Did you consider also dropping "tab" from the name here? Either is fine with me, so I'll leave it up to you.

I prefer `tabStops`.

> modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 61:
> 
>> 59:      * Specifies the default tab stop interval (beyond the last tab stop provided by {@code #tabStops()}),
>> 60:      * as a fixed repeating distance (in pixels) to the next tab stop computed at regular intervals
>> 61:      * relative to the leading edge of the {@code TextFlow} node.
> 
> This is a bit of a run-on sentence. Maybe consider breaking it up into two sentences, with the detail about "a fixed, repeating distance..." in the second sentence? Something like:
> 
> 
>     * Specifies the default tab stop interval for tabs beyond the last stop provided
>     * by {@code #tabStops()}. This is a fixed repeating distance (in pixels) to the
>     * next tab stop computed at regular intervals relative to the leading edge
>     * of the {@code TextFlow} node.

much better, thank you!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195966406
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2195968373

From kcr at openjdk.org  Wed Jul  9 21:26:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 9 Jul 2025 21:26:44 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v7]
In-Reply-To: <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <CjIVtbifhEw5fnqqHMFmV01uSxXRwV1_6O4n4VM5obY=.1e27ba08-3e6e-43fa-a577-296983f2b3a9@github.com>
Message-ID: <mE0AUFk9xlV6_TPQgMDXr3FiukPEoz78KGDvCvPO4y8=.c632caf0-c16c-4907-b793-5b1786837c7a@github.com>

On Wed, 9 Jul 2025 21:08:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oops

API / docs looks good with one formatting issue that I noticed when looking at the generated API docs.

I'll review the CSR next.

modules/javafx.graphics/src/main/java/javafx/scene/text/TabStopPolicy.java line 60:

> 58:     /**
> 59:      * Specifies the default tab stop interval for tabs beyond the last stop provided
> 60:      * by {@code #tabStops()}.  This is a fixed repeating distance (in pixels) to the

Change this to a `@link` or remove the `#` and `()` since they show up in the docs.

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

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3003151060
PR Review Comment: https://git.openjdk.org/jfx/pull/1744#discussion_r2196012493

From angorya at openjdk.org  Wed Jul  9 21:30:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:30:59 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v8]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  link

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1744/files
  - new: https://git.openjdk.org/jfx/pull/1744/files/9851c92d..2a1e479b

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

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

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

From angorya at openjdk.org  Wed Jul  9 21:43:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 21:43:46 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v8]
In-Reply-To: <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <-lXny8kskQ3aQzl1vP4ac_DB8abSrDoejVUDwkCPusg=.2aa3b9b0-e332-4dfb-98ab-0bc560b782ef@github.com>
Message-ID: <ho8tSKDGKv44PSJ5erWxAlLkgDDCGnajDF8p1gfXTfY=.3893827a-3ed3-4d85-87bb-db318730bbed@github.com>

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

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link

created the CSR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-3054161142

From angorya at openjdk.org  Wed Jul  9 22:45:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 9 Jul 2025 22:45:52 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v5]
In-Reply-To: <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
Message-ID: <4pnPG_GZAI6fcSeKFMYV7yr2-83JJlI_ORFH_iaJfDU=.3f24ad97-f2fb-460d-b471-9bf2c39325a4@github.com>

On Wed, 9 Jul 2025 20:48:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

Made https://bugs.openjdk.org/browse/JDK-8357594 to be the main issue, closed https://bugs.openjdk.org/browse/JDK-8341438 as a duplicate of JDK-8357594 .

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

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3054323225

From nlisker at gmail.com  Thu Jul 10 05:25:51 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 10 Jul 2025 08:25:51 +0300
Subject: Wrong behavior of Stage header
Message-ID: <CA+0ynh-tpveew_X=14=Dt-HG-N2PtG1mXREYGk+KjZEEmwLXzw@mail.gmail.com>

Hi,

After 8313424: JavaFX controls in the title bar (Preview), on Win 10 I
found that the header bar is wrong:
[image: image.png]
The close button is disabled and the control buttons are on the wrong side.

The reproducer is trivial:

import javafx.application.Application;

import javafx.stage.Stage;


public class StageTest extends Application {


@Override

public void start(Stage stage) {

stage.show();

}


public static void main(String[] args) {

Application.launch(args);

}

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250710/9d3f9cbd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2102 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250710/9d3f9cbd/image-0001.png>

From jvos at openjdk.org  Thu Jul 10 07:45:26 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 10 Jul 2025 07:45:26 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1839/files
  - new: https://git.openjdk.org/jfx/pull/1839/files/e99a8504..15ce1ee6

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

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

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

From jvos at openjdk.org  Thu Jul 10 07:45:27 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 10 Jul 2025 07:45:27 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v2]
In-Reply-To: <HONVxy6EdI1qlqte7zvVjtskITPnXTIfGNsRVWswWAc=.7a0eea44-8efc-4c74-ae92-d33b6f4492fc@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <iqqXs7NehJANJe9cLKTIAcvG9woAC9q2cmEIKZNYdtc=.f00efd25-d684-4661-ac2b-0666bf8bad8f@github.com>
 <HONVxy6EdI1qlqte7zvVjtskITPnXTIfGNsRVWswWAc=.7a0eea44-8efc-4c74-ae92-d33b6f4492fc@github.com>
Message-ID: <PMcFaiptANEFj58saniSoVIFIYpIbewONWwkLO_YDMI=.2bd8aa7b-1483-41fa-8f91-4e79f6121025@github.com>

On Tue, 8 Jul 2025 20:55:05 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>>   Add null checks
>>   Fix errors in position and length calculations
>
> modules/javafx.media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm line 331:
> 
>> 329:         CJavaInputStreamCallbacks *callbacks = new (nothrow) CJavaInputStreamCallbacks();
>> 330:         jobject jConnectionHolder = CLocator::CreateConnectionHolder(env, jLocator);
>> 331:         if (callbacks == NULL  || jConnectionHolder == NULL) {
> 
> Extra space after `callbacks == NULL`.

fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1839#discussion_r2196876883

From jvos at openjdk.org  Thu Jul 10 07:48:45 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 10 Jul 2025 07:48:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <xUBJLrM0xK-tsWqvgYH7j-eETRKwUJbYf3WorASAu10=.8a030e7a-e935-4774-9d3e-36caae739ce8@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <xUBJLrM0xK-tsWqvgYH7j-eETRKwUJbYf3WorASAu10=.8a030e7a-e935-4774-9d3e-36caae739ce8@github.com>
Message-ID: <IMLVq-ZcFtSMg2LZb5PviFCE4gbqgXEDscQisNJ3XLY=.af6c8d15-0c2a-46e1-8c0d-52be626e9fec@github.com>

On Thu, 3 Jul 2025 14:56:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Would it be possible to come up with a system test?

It would be great to have a system test, but we currently have no framework for testing media in the system tests. It would be good to create this, but I expect it to be lots of work (dealing with native code and different frameworks based on platform), so I think it's better in a separate issue

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3056123278

From kcr at openjdk.org  Thu Jul 10 12:34:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 12:34:52 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar
In-Reply-To: <IMLVq-ZcFtSMg2LZb5PviFCE4gbqgXEDscQisNJ3XLY=.af6c8d15-0c2a-46e1-8c0d-52be626e9fec@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <xUBJLrM0xK-tsWqvgYH7j-eETRKwUJbYf3WorASAu10=.8a030e7a-e935-4774-9d3e-36caae739ce8@github.com>
 <IMLVq-ZcFtSMg2LZb5PviFCE4gbqgXEDscQisNJ3XLY=.af6c8d15-0c2a-46e1-8c0d-52be626e9fec@github.com>
Message-ID: <jEaEdY_Dmjt58pcIeg1__nTrurbBeWYmsPtuLSIwh4s=.6912c9a4-4eb5-49e8-9228-bc0a9398a1d1@github.com>

On Thu, 10 Jul 2025 07:46:11 GMT, Johan Vos <jvos at openjdk.org> wrote:

> > Would it be possible to come up with a system test?
> 
> It would be great to have a system test, but we currently have no framework for testing media in the system tests. It would be good to create this, but I expect it to be lots of work (dealing with native code and different frameworks based on platform), so I think it's better in a separate issue

Correct. We do not have such a framework, and it would be out of scope for this issue.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3057261842

From kcr at openjdk.org  Thu Jul 10 14:02:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 14:02:46 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
Message-ID: <y9p-QHMnyC-XhPBho1109u8PDUjM0OL3vfBdUVv7huo=.6c7bcff9-bb5a-4d18-b7a3-dd54c8a209b8@github.com>

On Thu, 3 Jul 2025 19:30:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding missing APIs related to styling the highlights with CSS:
>> 
>> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
>> 
>> 
>> 
>> Adds methods to the `RichParagraph.Builder`:
>> 
>> 
>>         /**
>>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addWavyUnderline(int start, int length, String ... css) {
>> 
>> 
>> 
>>         /**
>>          * Adds a highlight with the specified style name(s).
>>          * Use translucent colors to enable multiple highlights in the same region of text.
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addHighlight(int start, int length, String ... css) {
>> 
>> 
>> 
>> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
>> 
>> 
>>     /**
>>      * Adds a highlight of the given color to the specified range within the last paragraph,
>>      * with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
>> 
>> 
>>     /**
>>      * Adds a wavy underline (typically used as a spell checker indicator)
>>      * to the specified range within the last paragraph, with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8355774.css
>  - Merge remote-tracking branch 'origin/master' into 8355774.css
>  - tab
>  - css

Looks good. Create the CSR and I'll review it.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1802#pullrequestreview-3005843456

From kcr at openjdk.org  Thu Jul 10 14:47:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 14:47:19 GMT
Subject: RFR: 8361710: Mark QPathTest as unstable on all platforms
Message-ID: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>

This PR marks QPathTest as "unstable" on all platforms. QPathTest is known to timeout intermittently. See [JDK-8328222](https://bugs.openjdk.org/browse/JDK-8328222). It is already skipped on Linux, since it was causing a lot of noise in our nightly and developer headful test runs. In the last few months, we've seen an increase of failures, especially when running tests with JDK 24 or 25. As a result, I will mark the test as unstable on all platforms by removing the `isLinux()` check.

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

Commit messages:
 - 8361710: Mark QPathTest as unstable on all platforms

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

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

From angorya at openjdk.org  Thu Jul 10 15:00:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 15:00:47 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
Message-ID: <uIbytdLGMDp2nP4py5hotRXVGusCinSBobUjJ_iJbPM=.69713eda-ee4b-476c-9692-84badb834134@github.com>

On Thu, 3 Jul 2025 19:30:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding missing APIs related to styling the highlights with CSS:
>> 
>> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
>> 
>> 
>> 
>> Adds methods to the `RichParagraph.Builder`:
>> 
>> 
>>         /**
>>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addWavyUnderline(int start, int length, String ... css) {
>> 
>> 
>> 
>>         /**
>>          * Adds a highlight with the specified style name(s).
>>          * Use translucent colors to enable multiple highlights in the same region of text.
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addHighlight(int start, int length, String ... css) {
>> 
>> 
>> 
>> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
>> 
>> 
>>     /**
>>      * Adds a highlight of the given color to the specified range within the last paragraph,
>>      * with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
>> 
>> 
>>     /**
>>      * Adds a wavy underline (typically used as a spell checker indicator)
>>      * to the specified range within the last paragraph, with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8355774.css
>  - Merge remote-tracking branch 'origin/master' into 8355774.css
>  - tab
>  - css

created the CSR.

@Ziad-Mid could you review this PR please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1802#issuecomment-3057822207
PR Comment: https://git.openjdk.org/jfx/pull/1802#issuecomment-3057823776

From angorya at openjdk.org  Thu Jul 10 15:02:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 15:02:46 GMT
Subject: RFR: 8361710: Mark QPathTest as unstable on all platforms
In-Reply-To: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
References: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
Message-ID: <yMVpxyr3L_rw3fkxW3F-dRvzJMdbxZtJ-I4LiMsDt6I=.b3bd1b68-13f4-4082-86c6-a486fea47c50@github.com>

On Thu, 10 Jul 2025 13:42:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR marks QPathTest as "unstable" on all platforms. QPathTest is known to timeout intermittently. See [JDK-8328222](https://bugs.openjdk.org/browse/JDK-8328222). It is already skipped on Linux, since it was causing a lot of noise in our nightly and developer headful test runs. In the last few months, we've seen an increase of failures, especially when running tests with JDK 24 or 25. As a result, I will mark the test as unstable on all platforms by removing the `isLinux()` check.

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1841#pullrequestreview-3006135138

From kizune at openjdk.org  Thu Jul 10 15:28:48 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 10 Jul 2025 15:28:48 GMT
Subject: RFR: 8361710: Mark QPathTest as unstable on all platforms
In-Reply-To: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
References: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
Message-ID: <NCMc7UqlGjLcqLrg1fWn_lJ7W720d6hlGSLDqeElVp8=.043bb446-95c7-4a10-b5ab-82f46e8a9f16@github.com>

On Thu, 10 Jul 2025 13:42:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR marks QPathTest as "unstable" on all platforms. QPathTest is known to timeout intermittently. See [JDK-8328222](https://bugs.openjdk.org/browse/JDK-8328222). It is already skipped on Linux, since it was causing a lot of noise in our nightly and developer headful test runs. In the last few months, we've seen an increase of failures, especially when running tests with JDK 24 or 25. As a result, I will mark the test as unstable on all platforms by removing the `isLinux()` check.

Marked as reviewed by kizune (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1841#pullrequestreview-3006242837

From kizune at openjdk.org  Thu Jul 10 15:36:49 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 10 Jul 2025 15:36:49 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage
In-Reply-To: <c2Jss3QiH7Eyx0w_pvV46I5ldTQkLAJLGpvxsH3mteE=.a417f0f8-08b7-4e3b-b117-e5de968f9768@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
 <O9bh37SAM5U9YqzdRu2_byv9VimuZqxvH9zeWBdbW3k=.55551027-ce05-4f83-89c1-3931fdbf2321@github.com>
 <c2Jss3QiH7Eyx0w_pvV46I5ldTQkLAJLGpvxsH3mteE=.a417f0f8-08b7-4e3b-b117-e5de968f9768@github.com>
Message-ID: <9BU9id5PU64TGx-IBq1OtMCM3QwGRQIqSGvau9EZd3o=.fe734a5e-6a11-4559-969f-694796e1c696@github.com>

On Wed, 18 Jun 2025 10:43:38 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java line 349:
>> 
>>> 347:         flow = (VirtualFlow<?>)control.lookup("#virtual-flow");
>>> 348: 
>>> 349:         if (sl != null) {
>> 
>> should we have a check here with a helpful message (which recommends to use `StageLoader`), instead of returning `null`?
>
> I thought about this as well. No strong opinion from my side.

Depends on the amount of noise it will produce during the test run but in general i would also prefer some kind of message here.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1829#discussion_r2198083367

From kcr at openjdk.org  Thu Jul 10 15:39:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 15:39:25 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2
Message-ID: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>

Release notes for JavaFX 24.0.2.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=47734

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=47733

As usual, I excluded test bugs, cleanup bugs, etc.

NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

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

Commit messages:
 - 8361887: Create release notes for JavaFX 24.0.2

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

PR: https://git.openjdk.org/jfx24u/pull/28

From kcr at openjdk.org  Thu Jul 10 15:52:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 15:52:50 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <FR43M2fi9-5SWuuOcybT9eFmMWQt3wrsgS-mHKvNmOk=.42e1d966-1ee6-4f23-b5b0-e5ab62fd2d37@github.com>

On Thu, 10 Jul 2025 15:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

Reviewers: @arapte or @andy-goryachev-oracle

@tiainen or @abhinayagarwal : can one of you take a look as well?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/28#issuecomment-3058019890

From angorya at openjdk.org  Thu Jul 10 16:03:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 16:03:51 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <ZZmRWShSOGc8zo8eXcwQ-IOSeyOSjePBy0C-Uh9zc3c=.58e53006-ae25-43bc-9cc4-655f258a7000@github.com>

On Thu, 10 Jul 2025 15:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

the bug list corresponds to the filter.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx24u/pull/28#pullrequestreview-3006371535

From angorya at openjdk.org  Thu Jul 10 17:44:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 17:44:45 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <3UwugMVC185nmeyRMuqVJ4NuXdJZzfVm607nXZwbXK4=.d98e8239-e9a5-4d42-8066-2020c8f5aeba@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

Got a reproducer for you: added AudioClip to the Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest

Build a jar and run it.  Select AudioClip page, then pressing "Play XX" button would play .wav or .mp3 file from the said jar.

What I see is that while the .wav file is being played correctly, the .mp3 does not play (no audio).

The bad news is that if I randomly press these buttons, it crashes

#  SIGSEGV (0xb) at pc=0x0000000104425918, pid=37242, tid=61703
#
# JRE version: Java(TM) SE Runtime Environment (23.0.1+11) (build 23.0.1+11-39)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0.1+11-39, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x509918]  jni_IsInstanceOf+0x260

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058356049

From angorya at openjdk.org  Thu Jul 10 17:48:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 17:48:47 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <Mec0pH-8ybfwppVLZQ-9zVMd18RWgYn7AX_1X2Hqno0=.07a2b790-294c-4bed-8b9d-c547b130a58d@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

Unrelated to this PR: 
- Changing the rate property for mp3 has no effect (but does change the rate for a .wav).  Changing the volume property does work.  I wonder if this should be documented.
- AudioClip properties specify no default values, we may need to address that.

I'll create a separate ticket later.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058371737

From angorya at openjdk.org  Thu Jul 10 17:55:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 17:55:49 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <cPI5Tm1wkaHDvFJSollpWHP52bHa4eLDm-brXeovsvY=.6278b6d9-6da2-4cad-a12e-3f0059c31f5a@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

With JDK24 crashes on the first try:

#  SIGSEGV (0xb) at pc=0x00000001047cf18c, pid=37494, tid=30723
#
# JRE version: OpenJDK Runtime Environment (24.0+36) (build 24+36-3646)
# Java VM: OpenJDK 64-Bit Server VM (24+36-3646, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x53718c]  jni_IsInstanceOf+0x1a8

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058390712

From angorya at openjdk.org  Thu Jul 10 18:20:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 18:20:54 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <B-pv2kChzjDSXWUYmthMfwy7zPMa1CAe-zd-aYZm0JM=.ad49e6be-c14c-494b-8f20-b699c6ea1f6f@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

My apologies - forgot to build with `-PCOMPILE_MEDIA=true`.

The fixed code plays .mp3 from a jar without crashing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058464919

From angorya at openjdk.org  Thu Jul 10 18:25:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 18:25:46 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <_30sA7Po0y0YUVPixPBOYNYK5mfg_d3umBSd0C2KvPQ=.aced9891-13f1-4d36-a1ad-8bc04a90deb2@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

- the fix works with jdk23 or jdk24.
- native code changes look ok to me

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1839#pullrequestreview-3006812063

From angorya at openjdk.org  Thu Jul 10 18:30:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 18:30:42 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <nlIE2ulxz0n1HdJx7dQfjazESJrClRmtcnJ2XgEGyK4=.43115df0-4bdb-4608-ae7a-172671b66364@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

Should we test with other audio formats, or everything is piped through the same code path?

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058493521

From angorya at openjdk.org  Thu Jul 10 19:46:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 19:46:44 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage
In-Reply-To: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
Message-ID: <fqaoFOvAwxwgUu3QXtwiKMsviI2RqvQO7j2QBCASiis=.b3d0724c-9bc6-4400-9e38-982290c7c5ee@github.com>

On Sun, 15 Jun 2025 13:56:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls.
> 
> It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise.
> 
> Take the following test code:
> 
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after.
> 
> This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic.
> 
> So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods.
> 
> For the example above, this would result in:
> 
> stageLoader = new StageLoader(tableView);
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> The stageLoader should be disposed in an @AfterEach.
> 
> Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty.
> Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly.

Sorry for a long delay reviewing this PR.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1829#pullrequestreview-3007107654

From angorya at openjdk.org  Thu Jul 10 19:46:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 19:46:45 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage
In-Reply-To: <c2Jss3QiH7Eyx0w_pvV46I5ldTQkLAJLGpvxsH3mteE=.a417f0f8-08b7-4e3b-b117-e5de968f9768@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
 <O9bh37SAM5U9YqzdRu2_byv9VimuZqxvH9zeWBdbW3k=.55551027-ce05-4f83-89c1-3931fdbf2321@github.com>
 <c2Jss3QiH7Eyx0w_pvV46I5ldTQkLAJLGpvxsH3mteE=.a417f0f8-08b7-4e3b-b117-e5de968f9768@github.com>
Message-ID: <TIQbo_iOICWnSx3hQxO-iRawYsHjSPvf8wpLL9qX4V4=.c9323576-4c9d-462f-83d2-9dabd922d35a@github.com>

On Wed, 18 Jun 2025 10:43:38 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java line 349:
>> 
>>> 347:         flow = (VirtualFlow<?>)control.lookup("#virtual-flow");
>>> 348: 
>>> 349:         if (sl != null) {
>> 
>> should we have a check here with a helpful message (which recommends to use `StageLoader`), instead of returning `null`?
>
> I thought about this as well. No strong opinion from my side.

there should be no noise: it's more of a question of instructing the developer why their test failed.  if there is no message, the NPE will happen in the context of the failing test which makes it rather obvious.  I agree with @Maran23 , either way is fine.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1829#discussion_r2198570177

From almatvee at openjdk.org  Thu Jul 10 19:54:43 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 10 Jul 2025 19:54:43 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <nlIE2ulxz0n1HdJx7dQfjazESJrClRmtcnJ2XgEGyK4=.43115df0-4bdb-4608-ae7a-172671b66364@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
 <nlIE2ulxz0n1HdJx7dQfjazESJrClRmtcnJ2XgEGyK4=.43115df0-4bdb-4608-ae7a-172671b66364@github.com>
Message-ID: <XqoqWABTydYX1y2PzJLHxQ-RDoveeLkEoV0ELauYjlY=.0abe2690-4ff9-4ebc-82c4-ec3f25d30157@github.com>

On Thu, 10 Jul 2025 18:28:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Should we test with other audio formats, or everything is piped through the same code path?

I tested with all supported formats.

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

PR Comment: https://git.openjdk.org/jfx/pull/1839#issuecomment-3058829108

From almatvee at openjdk.org  Thu Jul 10 19:54:42 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 10 Jul 2025 19:54:42 GMT
Subject: RFR: 8357714: AudioClip.play crash on macOS when loading resource
 from jar [v3]
In-Reply-To: <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
 <GfHU4op5Zr0kzfsjuEmICihFDuDdgnqmXDgWxiMQNCg=.ee1aee66-2cdc-4cba-9f44-7b50051aefb5@github.com>
Message-ID: <7yxadtW2B6verQnK8pP27ITzFGEshE-e2e3gBSAe3qw=.f43e852f-f07d-4502-8baa-778848340c7c@github.com>

On Thu, 10 Jul 2025 07:45:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
>> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
>> 
>> The 2 changes I made are:
>> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
>> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove whitespace

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1839#pullrequestreview-3007140384

From michaelstrau2 at gmail.com  Thu Jul 10 20:27:37 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 10 Jul 2025 22:27:37 +0200
Subject: Wrong behavior of Stage header
In-Reply-To: <CA+0ynh-tpveew_X=14=Dt-HG-N2PtG1mXREYGk+KjZEEmwLXzw@mail.gmail.com>
References: <CA+0ynh-tpveew_X=14=Dt-HG-N2PtG1mXREYGk+KjZEEmwLXzw@mail.gmail.com>
Message-ID: <CAJEpuXQipm_cydoycubj4m18h95_4jgr8o4ZkCYSJYv_OBn65Q@mail.gmail.com>

I can't reproduce this issue with the latest jfx/master running on Windows
10 22H2 build 19045.3803 in LTR or RTL locales.
What version are you using?

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250710/8e9d2b32/attachment.htm>

From nlisker at gmail.com  Thu Jul 10 20:33:11 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 10 Jul 2025 23:33:11 +0300
Subject: Wrong behavior of Stage header
In-Reply-To: <CAJEpuXQipm_cydoycubj4m18h95_4jgr8o4ZkCYSJYv_OBn65Q@mail.gmail.com>
References: <CA+0ynh-tpveew_X=14=Dt-HG-N2PtG1mXREYGk+KjZEEmwLXzw@mail.gmail.com>
 <CAJEpuXQipm_cydoycubj4m18h95_4jgr8o4ZkCYSJYv_OBn65Q@mail.gmail.com>
Message-ID: <CA+0ynh_GzqNUjPYdkk7MoFD+RMoE-_6ppJ83vMpazC3Mbr=o2g@mail.gmail.com>

22H2 build 19045.
If I move HEAD to 1 commit before this one then there's no issue, but in
any commit that includes this one (master included) I get this issue.

On Thu, Jul 10, 2025 at 11:27?PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> I can't reproduce this issue with the latest jfx/master running on Windows
> 10 22H2 build 19045.3803 in LTR or RTL locales.
> What version are you using?
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250710/8fc13570/attachment.htm>

From michaelstrau2 at gmail.com  Thu Jul 10 20:47:53 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 10 Jul 2025 22:47:53 +0200
Subject: Wrong behavior of Stage header
In-Reply-To: <CA+0ynh_GzqNUjPYdkk7MoFD+RMoE-_6ppJ83vMpazC3Mbr=o2g@mail.gmail.com>
References: <CA+0ynh-tpveew_X=14=Dt-HG-N2PtG1mXREYGk+KjZEEmwLXzw@mail.gmail.com>
 <CAJEpuXQipm_cydoycubj4m18h95_4jgr8o4ZkCYSJYv_OBn65Q@mail.gmail.com>
 <CA+0ynh_GzqNUjPYdkk7MoFD+RMoE-_6ppJ83vMpazC3Mbr=o2g@mail.gmail.com>
Message-ID: <CAJEpuXQP=OG2tvjvcvKNXoyW2-EwA8M6Z8a19W+O2_NrJxSPeA@mail.gmail.com>

This seems to be the same version that I am using.
Is there anything else that is significant about your Windows environment?
Do you have multiple language packs installed?


On Thu, Jul 10, 2025 at 10:33?PM Nir Lisker <nlisker at gmail.com> wrote:
>
> 22H2 build 19045.
> If I move HEAD to 1 commit before this one then there's no issue, but in any commit that includes this one (master included) I get this issue.
>
> On Thu, Jul 10, 2025 at 11:27?PM Michael Strau? <michaelstrau2 at gmail.com> wrote:
>>
>> I can't reproduce this issue with the latest jfx/master running on Windows 10 22H2 build 19045.3803 in LTR or RTL locales.
>> What version are you using?

From angorya at openjdk.org  Thu Jul 10 22:34:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 22:34:45 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <0hfPZORC7trBy8iv9Oa8e8Ks_yIunsvCcQzMnnpGs70=.daab54a6-6ad9-4034-b9bc-985659b77526@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <0hfPZORC7trBy8iv9Oa8e8Ks_yIunsvCcQzMnnpGs70=.daab54a6-6ad9-4034-b9bc-985659b77526@github.com>
Message-ID: <ozoHWl19WoSqhdSwFmy4OQbxttrapOaLlNUoWKUAvmo=.c23307f0-5a40-45ac-b9c3-79a68aeaa629@github.com>

On Thu, 12 Jun 2025 23:30:24 GMT, Kevin Rushforth <kcr 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...
>
> @tiainen Would you be able to look at the build changes and also do a test build?

Got it running in Eclipse (thank you @kevinrushforth !), please pick up changes from this branch:
https://github.com/andy-goryachev-oracle/jfx/tree/ag.metal

will test and report.

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

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

From angorya at openjdk.org  Thu Jul 10 22:56:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 10 Jul 2025 22:56:43 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
Message-ID: <RmUFUPBQzyb-KMDkWshP8KVVCjle6BWbisXDb9eT2yw=.69a53fd0-692b-4f7c-918f-aafbcd8046c7@github.com>

On Wed, 2 Jul 2025 07:53:24 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:
> 
>   add @Override

Went through all the controls in the monkey tester (inc. animated), saw no problems or graphic artifacts.

Encountered a weird issue with the WebView - not sure if related.  Had to go off VPN to load https://yahoo.com, then logged back into VPN and the application froze completely with the beach ball icon.  Can drag the window to another monitor (looks fuzzy bc resolution), but otherwise locked up.

I don't know when it locked up exactly, but you may want to investigate (I don't think network going up or down should have any impact on the application responsiveness).

Here is where it is stuck in the FX application thread:
<img width="918" height="1046" alt="Screenshot 2025-07-10 at 15 46 40" src="https://github.com/user-attachments/assets/b0c35b62-0d2c-40dc-84b3-7480caba0caf" />

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

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

From duke at openjdk.org  Fri Jul 11 00:31:46 2025
From: duke at openjdk.org (duke)
Date: Fri, 11 Jul 2025 00:31:46 GMT
Subject: Withdrawn: 8357067: Platform preference change can emit multiple
 notifications
In-Reply-To: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
References: <KgJ9HVQPeXBT-93ANfJsaIeuiqe8Fhng81psUSmDnwE=.44cc42bb-14a6-4933-9522-053a693546b7@github.com>
Message-ID: <ZCXTyEn5c0HPxnNobI-ASIkyyQQBarrgrhQ_RG9JMvQ=.b4ea957c-95ac-4d0e-a011-7f95d37d4a5a@github.com>

On Thu, 15 May 2025 17:50:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Some platform preference changes can trigger the emission of multiple notifications. For example, when switching from a high-contrast theme on Windows to the regular theme, the following notifications are emitted (log can be viewed in `PlatformPreferencesChangedTest`):
> 
> 
> changed:
> 	Windows.UIColor.Accent=0x0078d4ff
> 	Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
> 	Windows.SysColor.COLOR_WINDOW=0xffffffff
> 	Windows.UIColor.AccentLight1=0x0091f8ff
> 	Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
> 	Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
> 	Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
> 	Windows.SysColor.COLOR_BTNTEXT=0x000000ff
> 	Windows.UIColor.Foreground=0x000000ff
> 	Windows.UIColor.AccentDark1=0x0067c0ff
> 	Windows.UIColor.Background=0xffffffff
> 	Windows.UIColor.AccentLight3=0x99ebffff
> 	Windows.UIColor.AccentLight2=0x4cc2ffff
> 	Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
> 	Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
> 	Windows.UIColor.AccentDark2=0x003e92ff
> 	Windows.UIColor.AccentDark3=0x001a68ff
> 
> changed:
> 	-Windows.SPI.HighContrastColorScheme
> 	Windows.SPI.HighContrast=false
> 
> changed:
> 	Windows.UIColor.Foreground=0xffffffff
> 	Windows.UIColor.Background=0x000000ff
> 
> 
> Notably, the values for Windows.UIColor.Foreground/Background are inconsistent between the notifications (although they are eventually correct). In general, only a single notification should be emitted that includes all of the changed preferences.
> 
> This artifact is only visible on Windows. The reason is that changing some system settings (like high-contrast theme) causes a number of different window messages to be sent to the application. We should wait for all window messages to come in, and then aggregate all of the changed preferences into a single notification.
> 
> In order to minimize the delay between changing a system setting and sending out the notification in JavaFX, the implementation only waits when instructed to do so by the native toolkit. This allows us to instantly send out notifications for most changes, but selectively wait a bit for changes where the native toolkit knows that more changes might be coming in.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Fri Jul 11 04:38:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 11 Jul 2025 04:38:56 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
Message-ID: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>

Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 

The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
[which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
`
is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
 so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null

Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.

Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java

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

Commit messages:
 - whitespace
 - 8141391: DnD doesn't work for JFXPanel

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

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

From jhendrikx at openjdk.org  Fri Jul 11 08:55:35 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 11 Jul 2025 08:55:35 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
Message-ID: <T09SKDKB_XtFieZLG-l1wabSmJkc8OMotJIuVyVDNEA=.178e961b-e9a4-49b7-86d3-f65153700c24@github.com>

On Tue, 8 Jul 2025 21:44:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation changes

This looks good to me now.

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-3009271906

From jhendrikx at openjdk.org  Fri Jul 11 10:16:49 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 11 Jul 2025 10:16:49 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <3aSB7rI_fyAC8GOg9nouMtdm1odQMkumZJIHjZsHH1o=.534d3ab2-0a3d-4ae4-a23c-c9334920f5d6@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DelegatingEventDispatcher.java line 57:

> 55:             retarget = true;
> 56:             event = event.copyFor(event.getSource(), delegate);
> 57:         }

I think this improves the code by avoiding a reassignment:
Suggestion:

        boolean retarget = event.getTarget() == parent;

        // Focus delegation is the only scenario in which the event target may be the parent node.
        // Since we are in the capturing phase, we need to retarget the event to the focus delegate.
        if (retarget) {
            event = event.copyFor(event.getSource(), delegate);
        }

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2200139903

From jhendrikx at openjdk.org  Fri Jul 11 10:16:50 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 11 Jul 2025 10:16:50 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
Message-ID: <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>

On Wed, 9 Jul 2025 17:21:06 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8654:
> 
>> 8652:      * @since 26
>> 8653:      */
>> 8654:     Node getFocusDelegate(Node hoistingNode) {
> 
> I tried to tweak the InputMethodStateManager to deal with delegates and discovered there?s no easy way to get a node?s delegate. Shouldn?t there be a public way of retrieving the current delegate?
> 
> I don?t think getFocusDelegate should take a parameter. If I was creating a node with multiple focus delegates I would probably want to track the current one in some simple way. But getFocusDelegate doesn?t allow me to do that, I always have to respect the hoisting node parameter being passed in and dig through my descendant nodes to figure out which delegate is being requested. And it implies the only way to change the delegate is to requestFocus on the new delegate and take it through the hoisting process. That seems overly restrictive. I can see why a focus scope node would need to know which node hoisted focus but only at the time the hoist happens.
> 
> We?re spending a lot of time thinking about controls that may have more than one delegate. I really doubt anyone will ever create one. If they do it raises a bunch of questions related to accessibility and keyboard traversal that we?re not even discussing.

Does `resolveFocusDelegate` do what you need?  Perhaps that method should be public (and maybe renamed) and the version taking the parameter can be kept internal.  I think it would be unwise to assume there can only be one delegate as this mechanism is there primarily for skins, which are public API and would be used to construct advanced controls that would benefit from multiple delegates.  While FX itself is unlikely to have need of this as its focus is (and must be) on basic, composable controls, there is an infinite amount of useful composed controls that would benefit from having multiple focus delegates.

Examples that would work well with multiple delegates:

- The Date/Time entry control I mentioned with separated TextFields
- Similar to the above but for credit card entry, ip addresses, or any other field with fixed separators; of course this can be done with a single TextField as well, but that's much harder (and you get less context for each field for accessibility -- ie. for a date field it can specifically mention you are in the "month" part instead of just asking for a full date where it may need to explain the order of the individual parts).
- Spreadsheet cells can have controls embedded while the cell retains focus
- Tag editor (where you type something, which is autocompleted from a list of options, and when selected becomes a removable/editable tag -- the address fields of an email client are such an example)

At a minimum IMHO we should ensure this design doesn't prevent the possibility of multiple focus delegates, but preferably it should support it immediately.  I'm less well versed in the accessibility points you raised, could you elaborate?  For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2200312566

From kcr at openjdk.org  Fri Jul 11 12:46:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 12:46:56 GMT
Subject: Integrated: 8361710: Mark QPathTest as unstable on all platforms
In-Reply-To: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
References: <XnUSutFSBxvXshFQxnO0gilXqWGEeUEPRKdABUseIyc=.4d2c63c4-91c6-43a8-b594-64c0e362878a@github.com>
Message-ID: <bhluolS-N_IkU-ZA4K4kVP5WkbcZEPJl7n2kSRj-FCs=.87ab80b4-0ca4-4b1c-acb1-a48d82fc4ac7@github.com>

On Thu, 10 Jul 2025 13:42:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR marks QPathTest as "unstable" on all platforms. QPathTest is known to timeout intermittently. See [JDK-8328222](https://bugs.openjdk.org/browse/JDK-8328222). It is already skipped on Linux, since it was causing a lot of noise in our nightly and developer headful test runs. In the last few months, we've seen an increase of failures, especially when running tests with JDK 24 or 25. As a result, I will mark the test as unstable on all platforms by removing the `isLinux()` check.

This pull request has now been integrated.

Changeset: d6265e49
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d6265e49c3832972e8005913fbb3c126ba930577
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8361710: Mark QPathTest as unstable on all platforms

Reviewed-by: angorya, kizune

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

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

From kcr at openjdk.org  Fri Jul 11 14:12:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:12:26 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
Message-ID: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>

This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.

Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).

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

Commit messages:
 - Use custom gradle task to fix dependency issue
 - 8361713: JavaFX API docs overview is missing an intro section

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

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

From kcr at openjdk.org  Fri Jul 11 14:12:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:12:26 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
In-Reply-To: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
Message-ID: <9O5m8BLqWCpBuvs3ZxuUZSf6L6tW2A4nrH8UIyfdgNQ=.273f3cc6-05b0-4a07-ae9c-38eeb4601774@github.com>

On Fri, 11 Jul 2025 00:17:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
> 
> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).

Here is what the JavaFX API docs index page will look like after this fix:

<img width="1134" height="955" alt="javafx-docs-overview" src="https://github.com/user-attachments/assets/da2cf601-c008-4ea9-b38c-a9b24ef963fc" />

Reviewers: @arapte and either @johanvos or @tiainen 

@irisclark Can you also take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1842#issuecomment-3062468904
PR Comment: https://git.openjdk.org/jfx/pull/1842#issuecomment-3062479235

From kcr at openjdk.org  Fri Jul 11 14:17:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:17:07 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v2]
In-Reply-To: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
Message-ID: <_4IevTndCWOJ7URLTOXH1qRwOjSS7dlFi75JcGuXlyU=.03df4d2a-1bb1-4833-956c-b95c8812bd6a@github.com>

> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
> 
> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  add missing </li> tag

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1842/files
  - new: https://git.openjdk.org/jfx/pull/1842/files/392ec6df..4a0e3f3b

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

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

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

From kcr at openjdk.org  Fri Jul 11 14:20:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:20:50 GMT
Subject: RFR: 8345348: CSS media feature queries [v36]
In-Reply-To: <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
 <9K7Qd0ht4x9ln0dwwHApBzHT0_K64MgN9_20WEc--uI=.277bca6f-ff4a-4302-8491-bbd40e134953@github.com>
Message-ID: <V4dyYKaHzDGJr88mdXkvsbhJZKd9qv5wUN4SXRmnwWM=.101bdc5e-ad41-40da-8478-564a1c9d8b9a@github.com>

On Tue, 8 Jul 2025 21:44:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation changes

I think this is ready to go in. I've reviewed the API, and will rely on Andy's and John's review of the implementation.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1655#pullrequestreview-3010510359

From kcr at openjdk.org  Fri Jul 11 14:23:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:23:44 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
Message-ID: <k1qBkclcueVpO3ZH00_tcQ6JvMPeZ-UYoGz8WDnr548=.29afccc4-f60f-41a7-b889-b23be59ccf8c@github.com>

On Fri, 11 Jul 2025 04:17:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
> 
> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
> `
> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
> 
> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
> 
> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java

Reviewers: @kevinrushforth @lukostyra

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3062525506

From angorya at openjdk.org  Fri Jul 11 14:35:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 14:35:43 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v2]
In-Reply-To: <_4IevTndCWOJ7URLTOXH1qRwOjSS7dlFi75JcGuXlyU=.03df4d2a-1bb1-4833-956c-b95c8812bd6a@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <_4IevTndCWOJ7URLTOXH1qRwOjSS7dlFi75JcGuXlyU=.03df4d2a-1bb1-4833-956c-b95c8812bd6a@github.com>
Message-ID: <rskKxKygpWXEhwNV8q4tzrO6dpSu8m4Dmixsb4Ddhrs=.a480781d-683a-4b6e-abad-1dc004d712f7@github.com>

On Fri, 11 Jul 2025 14:17:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
>> 
>> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing </li> tag

overview.html line 9:

> 7:     The JavaFX API is composed of the following groups of modules:
> 8: 
> 9:     <ul>

minor: JDK uses `<blockquote>`, `<dt>`, and `<dd>` instead of `<ul>`.  should we do the same?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1842#discussion_r2200889891

From duke at openjdk.org  Fri Jul 11 14:49:48 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Fri, 11 Jul 2025 14:49:48 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <o78Oiimx4uZo4Vp4ztXrbOAsaIVDlfDsGRDB4fHmRHI=.81f8a368-5a78-4dcb-af06-f08c33a61d13@github.com>

On Thu, 10 Jul 2025 15:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

LGTM

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

Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jfx24u/pull/28#pullrequestreview-3010602489

From kcr at openjdk.org  Fri Jul 11 14:55:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 14:55:46 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v5]
In-Reply-To: <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <dOu1Ivodm93MSOAyKmytGuT-idR32H5eG2MHLwSJfk4=.98507407-215a-407b-8790-f2763cba0b1f@github.com>
Message-ID: <rCf_xXVX4twaFlc0z6-q4nJemRv9N-6agQtks9Hg4N8=.a9dc3fbe-6204-4131-a66f-9bfbe33c2bf6@github.com>

On Wed, 9 Jul 2025 20:48:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc

LGTM

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 468:

> 466:         double dx;
> 467:         double dy;
> 468:         if(accountForInsets) {

Minor: space after `if`

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-3010576759
PR Review Comment: https://git.openjdk.org/jfx/pull/1817#discussion_r2200903451

From kcr at openjdk.org  Fri Jul 11 15:11:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 15:11:27 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v3]
In-Reply-To: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
Message-ID: <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>

> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
> 
> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Use <blockquote><dl><dt><dd> tags to better align with JDK docs

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1842/files
  - new: https://git.openjdk.org/jfx/pull/1842/files/4a0e3f3b..92c32d2c

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

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

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

From kcr at openjdk.org  Fri Jul 11 15:11:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 15:11:27 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v2]
In-Reply-To: <rskKxKygpWXEhwNV8q4tzrO6dpSu8m4Dmixsb4Ddhrs=.a480781d-683a-4b6e-abad-1dc004d712f7@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <_4IevTndCWOJ7URLTOXH1qRwOjSS7dlFi75JcGuXlyU=.03df4d2a-1bb1-4833-956c-b95c8812bd6a@github.com>
 <rskKxKygpWXEhwNV8q4tzrO6dpSu8m4Dmixsb4Ddhrs=.a480781d-683a-4b6e-abad-1dc004d712f7@github.com>
Message-ID: <K-RMbKGMJVqTWiKHAi_N0c410GD_zw4m1kAdk4KXpWY=.2e5421b0-ac00-40eb-89b6-c758997d5bd4@github.com>

On Fri, 11 Jul 2025 14:33:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing </li> tag
>
> overview.html line 9:
> 
>> 7:     The JavaFX API is composed of the following groups of modules:
>> 8: 
>> 9:     <ul>
> 
> minor: JDK uses `<blockquote>`, `<dt>`, and `<dd>` instead of `<ul>`.  should we do the same?

Good idea. Done.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1842#discussion_r2200958900

From kcr at openjdk.org  Fri Jul 11 15:11:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 15:11:27 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v2]
In-Reply-To: <K-RMbKGMJVqTWiKHAi_N0c410GD_zw4m1kAdk4KXpWY=.2e5421b0-ac00-40eb-89b6-c758997d5bd4@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <_4IevTndCWOJ7URLTOXH1qRwOjSS7dlFi75JcGuXlyU=.03df4d2a-1bb1-4833-956c-b95c8812bd6a@github.com>
 <rskKxKygpWXEhwNV8q4tzrO6dpSu8m4Dmixsb4Ddhrs=.a480781d-683a-4b6e-abad-1dc004d712f7@github.com>
 <K-RMbKGMJVqTWiKHAi_N0c410GD_zw4m1kAdk4KXpWY=.2e5421b0-ac00-40eb-89b6-c758997d5bd4@github.com>
Message-ID: <WW_PlwZkfIvvJjZSaltdlJOqHg-v1ioMTzKFFFV14XI=.c07a76ee-c1fe-4697-aed1-b9edebaf3e8e@github.com>

On Fri, 11 Jul 2025 15:06:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> overview.html line 9:
>> 
>>> 7:     The JavaFX API is composed of the following groups of modules:
>>> 8: 
>>> 9:     <ul>
>> 
>> minor: JDK uses `<blockquote>`, `<dt>`, and `<dd>` instead of `<ul>`.  should we do the same?
>
> Good idea. Done.

I updated the screenshot to show the results.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1842#discussion_r2200962450

From angorya at openjdk.org  Fri Jul 11 15:11:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 15:11:57 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v6]
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <94H6TDMN363BQH8cEWAUMavTESt0zaNDRbpp0Kv4le0=.067999ca-c973-425d-839f-d5e69d6e9496@github.com>

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:

 - if
 - Merge branch 'master' into 8341438.text.shapes.insets
 - javadoc
 - link
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
 - Merge branch 'master' into 8341438.text.shapes.insets
 - cleanup
 - Merge branch 'master' into 8341438.text.shapes.insets
 - layout info
 - ... and 66 more: https://git.openjdk.org/jfx/compare/d6265e49...a283479f

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

Changes: https://git.openjdk.org/jfx/pull/1817/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1817&range=05
  Stats: 556 lines in 5 files changed: 522 ins; 18 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1817/head:pull/1817

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

From angorya at openjdk.org  Fri Jul 11 15:15:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 15:15:44 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v3]
In-Reply-To: <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
Message-ID: <PqOXmCwQYivkfqJMhkXNNhwRnv2wIZaLiBZ8k-BU4Ns=.2085b3df-fab5-4f17-812c-6db756c66142@github.com>

On Fri, 11 Jul 2025 15:11:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
>> 
>> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use <blockquote><dl><dt><dd> tags to better align with JDK docs

looks good, thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1842#pullrequestreview-3010691570

From kcr at openjdk.org  Fri Jul 11 15:24:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 15:24:47 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v6]
In-Reply-To: <94H6TDMN363BQH8cEWAUMavTESt0zaNDRbpp0Kv4le0=.067999ca-c973-425d-839f-d5e69d6e9496@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <94H6TDMN363BQH8cEWAUMavTESt0zaNDRbpp0Kv4le0=.067999ca-c973-425d-839f-d5e69d6e9496@github.com>
Message-ID: <uBdbBANIdbgMUTcbaKdH_CJpiofJhYsY84DAkcaGP9o=.e4dab82d-1a78-4ba0-8ac3-a6250ba6c924@github.com>

On Fri, 11 Jul 2025 15:11:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - if
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - javadoc
>  - link
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - ... and 66 more: https://git.openjdk.org/jfx/compare/d6265e49...a283479f

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-3010738728

From angorya at openjdk.org  Fri Jul 11 15:31:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 15:31:45 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
Message-ID: <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>

On Fri, 11 Jul 2025 04:17:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
> 
> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
> `
> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
> 
> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
> 
> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java

modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingDnD.java line 203:

> 201:                         javafx.embed.swing.JFXPanel jfxPanel = (javafx.embed.swing.JFXPanel)comp;
> 202: 
> 203:                         if (jfxPanel.getScene().getFocusOwner() instanceof javafx.scene.control.TextField tf) {

This cannot possibly work:

a) does not build
b) what if the drop target is not a TextField, but some other editable text component (a TextArea or a rich text editor of some sort)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2201031586

From kcr at openjdk.org  Fri Jul 11 16:24:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 11 Jul 2025 16:24:48 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
Message-ID: <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>

On Fri, 11 Jul 2025 15:29:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>
> modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingDnD.java line 203:
> 
>> 201:                         javafx.embed.swing.JFXPanel jfxPanel = (javafx.embed.swing.JFXPanel)comp;
>> 202: 
>> 203:                         if (jfxPanel.getScene().getFocusOwner() instanceof javafx.scene.control.TextField tf) {
> 
> This cannot possibly work:
> 
> a) does not build
> b) what if the drop target is not a TextField, but some other editable text component (a TextArea or a rich text editor of some sort)?

Yes, this the wrong approach. The javafx.swing module does not (and should not) depend on javafx.controls. Drag and Drop is a scene graph operation and can be targeted to any node, even nodes that are not Controls.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2201184345

From mstrauss at openjdk.org  Fri Jul 11 16:26:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Jul 2025 16:26:54 GMT
Subject: Integrated: 8345348: CSS media feature queries
In-Reply-To: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
References: <PPUB0S2fQ6QnJnwIK6TBQEUr-zfpGhKNSI4ajPFvk6Q=.1f2a127a-9403-4915-b898-dc44861d9a4e@github.com>
Message-ID: <KcYOICqBZ7ltU-cIGE938oyy_kuFEo3zZaZi2AM87UE=.e0a12821-1a43-42af-a772-6cf939ac4df9@github.com>

On Mon, 2 Dec 2024 16:19:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).

This pull request has now been integrated.

Changeset: e0f8e720
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e0f8e720752aecffb9090d1a3b82317b518f94a6
Stats:     5243 lines in 43 files changed: 4082 ins; 1048 del; 113 mod

8345348: CSS media feature queries

Reviewed-by: angorya, jhendrikx, kcr

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

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

From mfox at openjdk.org  Fri Jul 11 16:32:47 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 11 Jul 2025 16:32:47 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
Message-ID: <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>

On Fri, 11 Jul 2025 10:14:03 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Does `resolveFocusDelegate` do what you need?

Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.

If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.

> For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?

The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.

In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.

In any case the question is whether a monolithic control with multiple delegates is expected to roll its own internal traversal mechanism or if we need to extend the existing mechanism to include delegates. Having each control roll its own internal traversal would hide it from the accessibility frameworks. And if we expect the existing traversal keys (like Tab) to work internally we should extend the existing traversal machinery to work with delegates.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2201216087

From psadhukhan at openjdk.org  Fri Jul 11 16:51:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 11 Jul 2025 16:51:42 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
 <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>
Message-ID: <myuhxFCIZWATZyCkbuwEmMfXBYOaXY86L5YC8NGRJPU=.a27d8757-f8c6-4630-825c-9e368a52fcb0@github.com>

On Fri, 11 Jul 2025 16:21:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingDnD.java line 203:
>> 
>>> 201:                         javafx.embed.swing.JFXPanel jfxPanel = (javafx.embed.swing.JFXPanel)comp;
>>> 202: 
>>> 203:                         if (jfxPanel.getScene().getFocusOwner() instanceof javafx.scene.control.TextField tf) {
>> 
>> This cannot possibly work:
>> 
>> a) does not build
>> b) what if the drop target is not a TextField, but some other editable text component (a TextArea or a rich text editor of some sort)?
>
> Yes, this the wrong approach. The javafx.swing module does not (and should not) depend on javafx.controls. Drag and Drop is a scene graph operation and can be targeted to any node, even nodes that are not Controls.

a) Yes, couple of module-info file was changed but not pushed in
b) I could use TextInputControl or the parent

Any other suggestion as clearly we cannot use Scene.DragEvent return value?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2201278285

From angorya at openjdk.org  Fri Jul 11 16:59:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 16:59:45 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <myuhxFCIZWATZyCkbuwEmMfXBYOaXY86L5YC8NGRJPU=.a27d8757-f8c6-4630-825c-9e368a52fcb0@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
 <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>
 <myuhxFCIZWATZyCkbuwEmMfXBYOaXY86L5YC8NGRJPU=.a27d8757-f8c6-4630-825c-9e368a52fcb0@github.com>
Message-ID: <xOMuX0dbDsnZ-eyBA6EmnTcIbo4y9OKgNMWcQIjvs3A=.ac8efab5-3906-4315-8b40-855aadfcd759@github.com>

On Fri, 11 Jul 2025 16:48:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, this the wrong approach. The javafx.swing module does not (and should not) depend on javafx.controls. Drag and Drop is a scene graph operation and can be targeted to any node, even nodes that are not Controls.
>
> a) Yes, couple of module-info file was changed but not pushed in
> b) I could use TextInputControl or the parent
> 
> Any other suggestion as clearly we cannot use Scene.DragEvent return value?

What code path does it take when pasting from an FX component?  Maybe we can look how it differs and try to redirect to that path, so the content gets pasted correctly.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2201311812

From jvos at openjdk.org  Fri Jul 11 17:30:43 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 11 Jul 2025 17:30:43 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v3]
In-Reply-To: <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
Message-ID: <DZ6rk_mTdTGsgmjVVHnCpSkockxm3FH4c8XSVf62cu0=.a956ed72-a969-44b7-b22c-8ad67d21244a@github.com>

On Fri, 11 Jul 2025 15:11:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
>> 
>> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use <blockquote><dl><dt><dd> tags to better align with JDK docs

+1

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1842#pullrequestreview-3011325795

From jvos at openjdk.org  Fri Jul 11 17:31:44 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 11 Jul 2025 17:31:44 GMT
Subject: Integrated: 8357714: AudioClip.play crash on macOS when loading
 resource from jar
In-Reply-To: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
References: <RNRjD-_bDYXg0pfQCwOwyguOt4mEDWCv4uwNTCe7bO8=.55f8d638-07c5-49ac-95f3-12c1d7c9ebed@github.com>
Message-ID: <LvwbWiZmPUdLgyjl4N8gxUJVfkhrIe_vrmf7lT8h1h8=.29439501-79e0-4c18-a2f3-32419817ca73@github.com>

On Wed, 2 Jul 2025 21:47:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After JDK-8287822 (https://bugs.openjdk.org/browse/JDK-8287822), mpeg file content is no longer played via GSTPlatform but via OSXPlatform. 
> We need to correctly handle data in case the source is a file inside a jar, in which case CJavaInputStreamCallbacks is used.
> 
> The 2 changes I made are:
> 1. Use ConnectionHolder instead of Locator for CJavaInputStreamCallbacks in case a jar resource is used.
> 2. In case of random access datasource, use readBlock instead of readNextBlock in AVMediaPlayer

This pull request has now been integrated.

Changeset: 203c049a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/203c049a671ca00e6012dfedd6aa9848e2584b85
Stats:     27 lines in 2 files changed: 18 ins; 4 del; 5 mod

8357714: AudioClip.play crash on macOS when loading resource from jar

Reviewed-by: angorya, almatvee

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

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

From iris at openjdk.org  Fri Jul 11 17:35:43 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 11 Jul 2025 17:35:43 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v3]
In-Reply-To: <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
Message-ID: <CEA0tt81RFnXxDF2XO3VrC5nmJZt9v2X5O-euUiT_l8=.2734daa6-1f62-492a-aebe-d0309fca3d12@github.com>

On Fri, 11 Jul 2025 15:11:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
>> 
>> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use <blockquote><dl><dt><dd> tags to better align with JDK docs

Looks great!  I agree that adding individual tabs for each of the three groups of modules would be a bit much given that the total set of modules is small.

Thanks!

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

Marked as reviewed by iris (no project role).

PR Review: https://git.openjdk.org/jfx/pull/1842#pullrequestreview-3011341261

From mstrauss at openjdk.org  Fri Jul 11 22:30:49 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 11 Jul 2025 22:30:49 GMT
Subject: RFR: 8357594: Additional geometry-based Text/TextFlow APIs [v6]
In-Reply-To: <94H6TDMN363BQH8cEWAUMavTESt0zaNDRbpp0Kv4le0=.067999ca-c973-425d-839f-d5e69d6e9496@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
 <94H6TDMN363BQH8cEWAUMavTESt0zaNDRbpp0Kv4le0=.067999ca-c973-425d-839f-d5e69d6e9496@github.com>
Message-ID: <fSOh4G4HEq-X1OcYlKPQRBoSGH-Pd7PgzzDUNBYQTSY=.8e420d8c-4816-46f4-bfbc-d70cb9621e8b@github.com>

On Fri, 11 Jul 2025 15:11:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - if
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - javadoc
>  - link
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8341438.text.shapes.insets
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - ... and 66 more: https://git.openjdk.org/jfx/compare/d6265e49...a283479f

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1817#pullrequestreview-3012176501

From angorya at openjdk.org  Fri Jul 11 22:33:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 22:33:45 GMT
Subject: Integrated: 8357594: Additional geometry-based Text/TextFlow APIs
In-Reply-To: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
References: <Sc7OdCxHGrSYq2TPROxrKhSjAmqM3ics9toWocCOBXE=.9eea1ffb-eaa2-4cff-8dfd-4192db775abf@github.com>
Message-ID: <p77TI5dXvSfe9ZZvhOGtceA6rwW1saZIHDeC_A1a_jE=.8a4b9e4a-3e68-4c9d-a8da-be5fe4d3d38a@github.com>

On Tue, 27 May 2025 18:48:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> ## Summary
> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
> 
> ## Problem
> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
> - caretShape 
> - hitTest 
> - rangeShape
> 
> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
> 
> ## Solution
> The solution is two-fold: 
> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
> 
> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
> 
> ## Testing
> 
> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
> 
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected

This pull request has now been integrated.

Changeset: 04c5e40c
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/04c5e40cc116cb42150572959b53d1e465700e0e
Stats:     556 lines in 5 files changed: 522 ins; 18 del; 16 mod

8357594: Additional geometry-based Text/TextFlow APIs

Reviewed-by: kcr, mstrauss

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

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

From angorya at openjdk.org  Fri Jul 11 22:42:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 11 Jul 2025 22:42:23 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v9]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <Mv1KQt1JDzxH1OtRRBcZObcl1gbobNPBUnmwT3Enk5s=.8ef19420-0b0d-4512-8139-60d31d9b00e5@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:

 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - link
 - oops
 - since 25
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - ... and 55 more: https://git.openjdk.org/jfx/compare/04c5e40c...7bdb6ac7

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

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=08
  Stats: 589 lines in 12 files changed: 559 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From mfox at openjdk.org  Fri Jul 11 23:25:44 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 11 Jul 2025 23:25:44 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel
In-Reply-To: <xOMuX0dbDsnZ-eyBA6EmnTcIbo4y9OKgNMWcQIjvs3A=.ac8efab5-3906-4315-8b40-855aadfcd759@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
 <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>
 <myuhxFCIZWATZyCkbuwEmMfXBYOaXY86L5YC8NGRJPU=.a27d8757-f8c6-4630-825c-9e368a52fcb0@github.com>
 <xOMuX0dbDsnZ-eyBA6EmnTcIbo4y9OKgNMWcQIjvs3A=.ac8efab5-3906-4315-8b40-855aadfcd759@github.com>
Message-ID: <OymUNc1FxbMRFRZW4q4HhelV9KBomqWcoxP_-t-ClDY=.8421a46a-6bba-45ae-a87c-2c2e37cc48c8@github.com>

On Fri, 11 Jul 2025 16:56:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> a) Yes, couple of module-info file was changed but not pushed in
>> b) I could use TextInputControl or the parent
>> 
>> Any other suggestion as clearly we cannot use Scene.DragEvent return value?
>
> What code path does it take when pasting from an FX component?  Maybe we can look how it differs and try to redirect to that path, so the content gets pasted correctly.

Am I missing something? I can't find any evidence that a JavaFX text input control processes drag-and-drop in any way or that it ever did (though I could only easily look back to jfx14). Did the manual test referenced here ever work?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2202051971

From credmond at certak.com  Fri Jul 11 23:39:22 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 12 Jul 2025 00:39:22 +0100
Subject: Inconsistent drawing/layouts of Dialogs & show()/showAndWait()
 differences
In-Reply-To: <D51A5B9D-07DC-4B95-80EE-7E1B7FDD731C@gmail.com>
References: <CAG_-AaAHBN9HET4KBrD2UWPSMgGZnOo+wV2ORCkMubfwFEGokg@mail.gmail.com>
 <D51A5B9D-07DC-4B95-80EE-7E1B7FDD731C@gmail.com>
Message-ID: <CAG_-AaAELLnQ4UQp=ekursFjSF0H_b9r8DpUGVSci-PeAccFnw@mail.gmail.com>

Hi Martin,

Just to say thanks for looking into it and the following explanation, it's
good to know. There's some quirks to be aware of for sure.


Kind Regards,
Cormac

On Mon, 7 Jul 2025 at 15:50, Martin Fox <martinfox656 at gmail.com> wrote:

> Cormac,
>
> When you call Dialog.show everything happens in the order you expect. When
> you call Dialog.showAndWait the order of operations changes. For one, the
> Dialog code issues the DIALOG_SHOWN event *before* showing the window (it
> wants to send out that event before an internal call to Window.showAndWait
> blocks). For two, when Window.sizeToScene is called on a window that?s not
> yet visible it gets deferred. The end result is that with
> Dialog.showAndWait your onShown handler gets called before the window is
> sized to the scene but when you use Dialog.show your onShown handler is
> called after.
>
> I don?t think any of this is documented. I've run into the deferred
> sizeToScene behavior before. I didn?t dig much but it looks like it was
> added over a decade ago in response to some bug reports. The timing of
> Dialog.setOnShown is also old behavior. There?s a comment in the
> Dialog.java about this:
>
>  // this is slightly odd - we fire the SHOWN event before the show()
>  // call, so that users get the event before the dialog blocks
>
>
> So I can see what?s going on in case #2. Due to the re-ordering the
> sizeToScene logic is happening after the window?s minimum size is set. The
> docs don?t say what should happen if the scene?s desired size is less than
> the window?s minimum. What you?re getting is a scene that doesn?t fill the
> window. One work-around for case 2 is to call setOnShown on the dialog?s
> window instead of the dialog itself.
>
> BTW, I think what you?re seeing in case #3 is correct and not a bug.
> You?re altering the size of the scene after the window has been sized and
> shown. I wouldn?t expect the window to automatically re-size to match the
> new scene dimensions. I think the expectation is that you would alter the
> scene?s dimensions in onShowing instead of onShown.
>
> Martin
>
> On Jul 3, 2025, at 2:24?PM, Cormac Redmond <credmond at certak.com> wrote:
>
> Hi,
>
> I have noticed inconsistent and confusing size/layout behaviour with
> Dialogs when changing min width or height (after shown).
>
> The behaviour depends on whether changing min width/height on the Stage,
> or the DialogPane itself, and whether show() or showAndWait() is used.
>
> In summary:
>
>    1. Set Stage mins + show()
>       - no bug
>    2.  Set Stage mins + showAndWait()
>       - improper layout: background applies only to label (i.e., size
>       before re-size), button wrong position, re-sizing window fixes the problem
>    3. 3 Set DialogPane mins + show()
>       - min sizes are ignored, button is visible, until it comes into
>       focus, and then the button disappears, you can find it if you resize window
>       close to the mins set
>    4. 4 Set DialogPane mins + showAndWait()
>       - no bug
>
> It's happening in JFX23/24/25. Note, these may seem trivial/fixable, or
> you may ask "why would you do that?", but there are reasons I won't clutter
> the mail with.
>
> Anyway, it's best presented with a set of examples and code.
>
> Re points 1 and 2 above, exact same code, except red is showAndWait() and
> green is show():
>
> <image.png>
>
> Obviously, they should behave the same. Then slightly resize the red one:
>
> <image.png>
>
>
> Examples 3 and 4 above -- again, same code. Purple is show(), yellow is
> showAndWait().
>
> <image.png>
>
> After you close the yellow dialog:
>
> <image.png>
>
> They should be the same size from the outset.
>
>
>
> public class DialogBug extends Dialog<Boolean> {
>
>     public DialogBug(final String s, boolean flip) {
>         setTitle("Bug");
>         setResizable(true);
>
>         final DialogPane dp = getDialogPane();
>         dp.setStyle(s);
>         dp.getButtonTypes().add(ButtonType.CLOSE);
>         dp.setContent(new Label("Content"));
>
>         // Setting stage size causes the bug
>         setOnShown(e -> {
>
>             if (flip) {
>                 // Set stage sizes
>                 Stage st = (Stage) dp.getScene().getWindow();
>                 st.setMinHeight(260);
>                 st.setMinWidth(360);
>             } else {
>                 // Set dialog sizes: note buttons disappear when you resize
>                 dp.setMinHeight(260);
>                 dp.setMinWidth(360);
>             }
>         });
>     }
>
>     public static class BugApp extends Application {
>         @Override
>         public void start(final Stage st) throws Exception {
>
>             final boolean FLIP_ME = true; // make true for other bug
>
>             if (FLIP_ME) {
>                 // Note: bug doesn't happen when using show() only. Stage
> is fully green on show.
>                 new DialogBug("-fx-background-color: green;",
> true).show(); // NO BUG
>
>                 // showAndWait presents the bug; background not fully
> drawn, button shifts on re-size
>                 new DialogBug("-fx-background-color: red;",
> true).showAndWait(); // BUG
>             } else {
>                 // A different type of issue: two different sizes and
> button behaviour
>                 // Notice:
>                 // - same dialogs, different sizes
>                 // - how button in purple dialog shifts when yellow dialog
> pane is closed
>                 new DialogBug("-fx-background-color: purple;",
> false).show(); // BUG
>
>                 new DialogBug("-fx-background-color: yellow;",
> false).showAndWait(); // NO BUG
>             }
>         }
>     }
> }
>
> Thoughts?
>
>
>
> Kind Regards,
> Cormac
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250712/2529c7c2/attachment.htm>

From michaelstrau2 at gmail.com  Sat Jul 12 05:16:41 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 12 Jul 2025 07:16:41 +0200
Subject: Viewport characteristics media features
Message-ID: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>

JavaFX 25 introduces user-preference media queries, which allows
developers to probe user preferences in stylesheets.

I propose to enhance media queries by adding the following viewport
characteristics media features [0]:
1. width
2. height
3. aspect-ratio (=width/height)
4. orientation (with values "portrait" and "landscape")
5. display-mode (with values "fullscreen" and "standalone")

These additional media features make it easier to create responsive
user interfaces. For example, a stylesheet could have different styles
depending on the window width:

    @media (width <= 500) {
        // ...
    }

    @media (500 < width < 1000) {
        // ...
    }

    @media (width >= 1000) {
        // ...
    }

[0] https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics

From mstrauss at openjdk.org  Sat Jul 12 05:23:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 12 Jul 2025 05:23:29 GMT
Subject: RFR: 8358450: Viewport characteristics media features
Message-ID: <deVaITCP-Otfaf9pGYjmgW3Lb87XC9qyHAwy_T_BjV4=.ff26c847-dc0b-4c58-aaf5-4a0adf9bee45@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)

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

Commit messages:
 - Add viewport characteristics media features

Changes: https://git.openjdk.org/jfx/pull/1844/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358450
  Stats: 2424 lines in 37 files changed: 1909 ins; 202 del; 313 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 jhendrikx at openjdk.org  Sat Jul 12 10:17:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 12 Jul 2025 10:17:46 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
 <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
Message-ID: <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>

On Fri, 11 Jul 2025 16:30:14 GMT, Martin Fox <mfox at openjdk.org> wrote:

> > Does `resolveFocusDelegate` do what you need?
> 
> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.

Alright, so a method to get the current delegate would really help there, and I think that information should be available easily enough.

> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.

I think the variant with a parameter has a different intent, and so I think we should not attempt to combine the two.

> > For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?
> 
> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.
> 
> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.

Tab would definitely be the most intuitive model, and that's also what I would expect (and how this has worked for such controls since ages past).  So what I think is missing here is that in order to do correct navigation, Scene must be able to query the delegate of its current focus owner.  I think this could be done transparently:

- This PR already directs events to the current delegate, including events that are interpreted as navigation events
- Events targeted at a delegate already bubble up in the usual way, eventually reaching Scene
- Scene, when it wants to act on such an event for navigation, can ask its current focus owner to find out the actual control that received the event (the delegate).  This could be a parameterless `getFocusDelegate` or some such or a property.
- Scene then initiates the navigation logic from the delegate node (let's say it is in a field of a composed DateEntryControl -- the normal logic would find a next/previous field, or if there is none, a next unrelated node).  Navigation in FX works like this everywhere, where the child order determines navigation order, and I think we should keep that.
- A new Node now has been found that should receive focus.  If this node was a node external to the DateEntryControl, it won't have hoist focus set; proceed as normal as make it the focus owner.
- If the new Node does have hoist focus set, then find out its parent, and inform it that the delegate changed; this parent (whether it is the same or different) becomes or already is the new focus owner -- the focus owner may not have changed at all if the navigation only changed the active delegate -- which is probably a good thing

For input methods then I think the missing piece is to find out the delegate chain, but as Scene would need to know this for correct navigation (and so we don't have to build a navigation override system on a per Node basis) I think it could use the same mechanism.

> In any case the question is whether a monolithic control with multiple delegates is expected to roll its own internal traversal mechanism or if we need to extend the existing mechanism to include delegates. Having each control roll its own internal traversal would hide it from the accessibility frameworks. And if we expect the existing traversal keys (like Tab) to work internally we should extend the existing traversal machinery to work with delegates.

I would really not want to see custom traversal mechanisms, because on top of what you said I think it would be unintuitive as well.  I think relying on child order is more than sufficient.  Any custom mechanism is I think more likely to be unintuitive for the user as there is IMHO only one way to navigate intuitively through a UI -- tab/shift tab to focus the next **logical** component (defined by child order and UI hierarchy), and arrow keys go to the visually best next component -- this is what Scene does already, and allowing controls to deviate here further is just not something that is a requirement ever.  Controls already have more than sufficient leeway to define the next "logical" node, even to the point that it would be unintuitive for users...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2202486786

From mhanl at openjdk.org  Sat Jul 12 10:35:23 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 12 Jul 2025 10:35:23 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage [v2]
In-Reply-To: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
Message-ID: <-kM6dG6Jkeoc4twiNjOjTR9Vu9lp2qwGJgMC_kWfM4c=.39aaa145-5ea1-4d3c-baeb-c87b1bee5a89@github.com>

> Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls.
> 
> It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise.
> 
> Take the following test code:
> 
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after.
> 
> This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic.
> 
> So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods.
> 
> For the example above, this would result in:
> 
> stageLoader = new StageLoader(tableView);
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> The stageLoader should be disposed in an @AfterEach.
> 
> Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty.
> Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly.

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  Exception message

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1829/files
  - new: https://git.openjdk.org/jfx/pull/1829/files/5cde6fd6..8c5d40eb

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

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

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

From mhanl at openjdk.org  Sat Jul 12 10:35:23 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 12 Jul 2025 10:35:23 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage [v2]
In-Reply-To: <TIQbo_iOICWnSx3hQxO-iRawYsHjSPvf8wpLL9qX4V4=.c9323576-4c9d-462f-83d2-9dabd922d35a@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
 <O9bh37SAM5U9YqzdRu2_byv9VimuZqxvH9zeWBdbW3k=.55551027-ce05-4f83-89c1-3931fdbf2321@github.com>
 <c2Jss3QiH7Eyx0w_pvV46I5ldTQkLAJLGpvxsH3mteE=.a417f0f8-08b7-4e3b-b117-e5de968f9768@github.com>
 <TIQbo_iOICWnSx3hQxO-iRawYsHjSPvf8wpLL9qX4V4=.c9323576-4c9d-462f-83d2-9dabd922d35a@github.com>
Message-ID: <zHRPb6_vxsiGVM6cduuYGCcsrXf6bcr7CpAA8IV2Uhg=.2e32b75f-1777-4c45-9a34-cba79a066ee8@github.com>

On Thu, 10 Jul 2025 19:43:15 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I thought about this as well. No strong opinion from my side.
>
> there should be no noise: it's more of a question of instructing the developer why their test failed.  if there is no message, the NPE will happen in the context of the failing test which makes it rather obvious.  I agree with @Maran23 , either way is fine.

Since they were two similar opinions about this, I added an exception with a clear message why the flow might be null. :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1829#discussion_r2202499498

From zjx001202 at gmail.com  Sat Jul 12 11:18:26 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 12 Jul 2025 19:18:26 +0800
Subject: For fonts with localized names, JavaFX cannot find the font by the
 default name on Windows
Message-ID: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>

Hi,

We recently noticed a problem: For fonts with localized names,
Font.font(String) can only find the font based on the localized name in the
current locale.

For example, the Chinese version of Windows comes with a font called
"YouYuan", and its Chinese name is "??".
When the system language is Chinese, JavaFX has the following behaviors:

jshell> Font.font("YouYuan")
$2 ==> Font[name=System Regular, family=System, style=Regular,
size=13.333333015441895]

jshell> Font.font("??")
$3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
size=13.333333015441895]

jshell> $3.getFamily()
$4 ==> "YouYuan"


As you can see, we cannot find the font based on the English name, we can
only use the Chinese name.
But Font::getName() returns the English name, so we can't get the Chinese
name from the Font.
This makes it impossible to generate a style sheet based on a Font object,
because

"-fx-font-family: \"%s\";".formatted(font.getFamily())

will not work with these fonts.

The only workaround I can think of is to generate a mapping table from
English names to Chinese names like this:


Font.getFamilies().stream().collect(Collectors.toMap(it ->
Font.font(it).getFamily(), Function.identity()))


But this seems like a lot of overhead :(

So, I want JavaFX to provide the following features:

   1. Regardless of the current system language, Font.font(String) should
   be able to find the font by its English name;
   2. Provide a new method Font::getLocalizedFamily() to get the localized
   name of the font.

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250712/e0d1b40c/attachment.htm>

From mhanl at openjdk.org  Sat Jul 12 12:12:44 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Sat, 12 Jul 2025 12:12:44 GMT
Subject: RFR: 8361713: JavaFX API docs overview is missing an intro section
 [v3]
In-Reply-To: <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
 <sr9UiyLgjG03rz-2iyCOnpDazRerv3vmJrQl35UkMnk=.39b82033-fb70-4b92-af16-b5130e05dcbf@github.com>
Message-ID: <dnD2JD8Ni1R2CLZ7HIDVNbhj82LpnT6v-TqHFrZKWgA=.90cfda20-af75-48b2-8346-1e6d15448662@github.com>

On Fri, 11 Jul 2025 15:11:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
>> 
>> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use <blockquote><dl><dt><dd> tags to better align with JDK docs

I like that addition! Changes look good as well.

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1842#pullrequestreview-3013001844

From crschnick at xpipe.io  Sat Jul 12 16:03:19 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sat, 12 Jul 2025 18:03:19 +0200
Subject: Viewport characteristics media features
In-Reply-To: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
Message-ID: <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>

That is very exciting.

Would it be possible to create custom boolean properties that one can 
then use for media queries? For example, having a ObservableMap<String, 
ObservableBooleanValue> in the new scene preferences to define custom 
features that can then be matched in the stylesheet.

On 12/07/2025 07:16, Michael Strau? wrote:
> JavaFX 25 introduces user-preference media queries, which allows
> developers to probe user preferences in stylesheets.
>
> I propose to enhance media queries by adding the following viewport
> characteristics media features [0]:
> 1. width
> 2. height
> 3. aspect-ratio (=width/height)
> 4. orientation (with values "portrait" and "landscape")
> 5. display-mode (with values "fullscreen" and "standalone")
>
> These additional media features make it easier to create responsive
> user interfaces. For example, a stylesheet could have different styles
> depending on the window width:
>
>      @media (width <= 500) {
>          // ...
>      }
>
>      @media (500 < width < 1000) {
>          // ...
>      }
>
>      @media (width >= 1000) {
>          // ...
>      }
>
> [0] https://www.w3.org/TR/mediaqueries-5/#mf-viewport-characteristics

From michaelstrau2 at gmail.com  Sat Jul 12 17:49:19 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 12 Jul 2025 19:49:19 +0200
Subject: Viewport characteristics media features
In-Reply-To: <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
 <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
Message-ID: <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>

In general, I'm skeptical about inventing non-standard CSS features.
What would be the use case for custom properties in the way that you describe?


On Sat, Jul 12, 2025 at 6:03?PM Christopher Schnick <crschnick at xpipe.io> wrote:
>
> That is very exciting.
>
> Would it be possible to create custom boolean properties that one can
> then use for media queries? For example, having a ObservableMap<String,
> ObservableBooleanValue> in the new scene preferences to define custom
> features that can then be matched in the stylesheet.
>

From crschnick at xpipe.io  Sat Jul 12 18:13:10 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sat, 12 Jul 2025 20:13:10 +0200
Subject: Viewport characteristics media features
In-Reply-To: <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
 <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
 <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>
Message-ID: <1593302d-2e32-4c1f-b422-8f527597258e@xpipe.io>

Assuming this would be available, I would implement custom css 
breakpoints to refer to common layout changes for our application. This 
would prevent a lot of repetition. For example, something similar to the 
tailwindcss breakpoints:


I could also use it to define more advanced breakpoint conditions that 
are not possible to achieve with just css expressions.

In general, having the media queries only available in css is also 
limiting for many more advanced customizations. If I want to for example 
subscribe to a certain states, e.g. when the width crosses a certain 
breakpoint, to run a listener that changes some node properties.

Custom media queries can also just be implemented using a listener that 
sets pseudo class states on the root node for each scene. However, 
always found it annoying having to specify something like .root:xl 
.button {} to replicate these breakpoints. If there was such a thing as 
recursive pseudo classes that would allow querying them in css via 
.button:xl when they are only set for a parent or root node, that would 
work as well as an alternative.

On 12/07/2025 19:49, Michael Strau? wrote:
> In general, I'm skeptical about inventing non-standard CSS features.
> What would be the use case for custom properties in the way that you describe?
>
>
> On Sat, Jul 12, 2025 at 6:03?PM Christopher Schnick<crschnick at xpipe.io> wrote:
>> That is very exciting.
>>
>> Would it be possible to create custom boolean properties that one can
>> then use for media queries? For example, having a ObservableMap<String,
>> ObservableBooleanValue> in the new scene preferences to define custom
>> features that can then be matched in the stylesheet.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250712/958ad047/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01SvdR9BqB0m9JAa.png
Type: image/png
Size: 25822 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250712/958ad047/01SvdR9BqB0m9JAa-0001.png>

From michaelstrau2 at gmail.com  Sat Jul 12 18:24:25 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 12 Jul 2025 20:24:25 +0200
Subject: Viewport characteristics media features
In-Reply-To: <1593302d-2e32-4c1f-b422-8f527597258e@xpipe.io>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
 <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
 <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>
 <1593302d-2e32-4c1f-b422-8f527597258e@xpipe.io>
Message-ID: <CAJEpuXRM_ZXdL5rHOZMsg7pEU9Eza=HquUM957=Pzw+1OJWrPg@mail.gmail.com>

Maybe @custom-media queries can get you part of the way there:
https://www.w3.org/TR/mediaqueries-5/#custom-mq

So instead of repeating a media query multiple times, you can define a
custom media query like this:
    @custom-media --sm (width >= 40);

And use it with the regular syntax:
    @media (--sm) {
        // ...
    }

On Sat, Jul 12, 2025 at 8:13?PM Christopher Schnick <crschnick at xpipe.io>
wrote:

> Assuming this would be available, I would implement custom css breakpoints
> to refer to common layout changes for our application. This would prevent a
> lot of repetition. For example, something similar to the tailwindcss
> breakpoints:
>
>
> I could also use it to define more advanced breakpoint conditions that are
> not possible to achieve with just css expressions.
>
> In general, having the media queries only available in css is also
> limiting for many more advanced customizations. If I want to for example
> subscribe to a certain states, e.g. when the width crosses a certain
> breakpoint, to run a listener that changes some node properties.
>
> Custom media queries can also just be implemented using a listener that
> sets pseudo class states on the root node for each scene. However, always
> found it annoying having to specify something like .root:xl .button {} to
> replicate these breakpoints. If there was such a thing as recursive pseudo
> classes that would allow querying them in css via .button:xl when they are
> only set for a parent or root node, that would work as well as an
> alternative.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250712/03664ccd/attachment.htm>

From mstrauss at openjdk.org  Sun Jul 13 01:38:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 13 Jul 2025 01:38:38 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v2]
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: <rM09Ojpu-Uqmz1TLUX1fADue0-Irpiys3DGIrZPr6Zw=.34ff48f8-1905-4223-9fa0-39c844c84750@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 incrementally with one additional commit since the last revision:

  Replace context awareness flags with EnumSet

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/abdccad9..cc0d44c1

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

  Stats: 191 lines in 16 files changed: 102 ins; 34 del; 55 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 crschnick at xpipe.io  Sun Jul 13 01:46:02 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sun, 13 Jul 2025 03:46:02 +0200
Subject: Viewport characteristics media features
In-Reply-To: <CAJEpuXRM_ZXdL5rHOZMsg7pEU9Eza=HquUM957=Pzw+1OJWrPg@mail.gmail.com>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
 <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
 <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>
 <1593302d-2e32-4c1f-b422-8f527597258e@xpipe.io>
 <CAJEpuXRM_ZXdL5rHOZMsg7pEU9Eza=HquUM957=Pzw+1OJWrPg@mail.gmail.com>
Message-ID: <86c2b5db-4284-4b00-8ec7-3c0b0bc244b8@xpipe.io>

Yeah that would definitely improve the situation when it comes to 
repetitiveness. Would I need to define such custom media queries per 
stylesheet or can they apply globally?

On 12/07/2025 20:24, Michael Strau? wrote:
> Maybe @custom-media queries can get you part of the way there:
> https://www.w3.org/TR/mediaqueries-5/#custom-mq
>
> So instead of repeating a media query multiple times, you can define a 
> custom media query like this:
> ? ??@custom-media --sm (width >= 40);
>
> And use it with the regular syntax:
> ? ??@media (--sm) {
> ? ? ? ? // ...
> ? ? }
>
> On Sat, Jul 12, 2025 at 8:13?PM Christopher Schnick 
> <crschnick at xpipe.io> wrote:
>
>     Assuming this would be available, I would implement custom css
>     breakpoints to refer to common layout changes for our application.
>     This would prevent a lot of repetition. For example, something
>     similar to the tailwindcss breakpoints:
>
>
>     I could also use it to define more advanced breakpoint conditions
>     that are not possible to achieve with just css expressions.
>
>     In general, having the media queries only available in css is also
>     limiting for many more advanced customizations. If I want to for
>     example subscribe to a certain states, e.g. when the width crosses
>     a certain breakpoint, to run a listener that changes some node
>     properties.
>
>     Custom media queries can also just be implemented using a listener
>     that sets pseudo class states on the root node for each scene.
>     However, always found it annoying having to specify something like
>     .root:xl .button {} to replicate these breakpoints. If there was
>     such a thing as recursive pseudo classes that would allow querying
>     them in css via .button:xl when they are only set for a parent or
>     root node, that would work as well as an alternative.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250713/9cce3b31/attachment-0001.htm>

From mstrauss at openjdk.org  Sun Jul 13 05:16:43 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 13 Jul 2025 05:16:43 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
Message-ID: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>

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.

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

Commit messages:
 - Window decorations adapt to color scheme

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

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

From psadhukhan at openjdk.org  Sun Jul 13 08:52:31 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 13 Jul 2025 08:52:31 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v2]
In-Reply-To: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
Message-ID: <Ttbp8_xBapxRUT26msB5C9pgJKwpn4G0WDxwgGxN0W0=.8123e709-35fa-46bc-96ad-882feb4432f3@github.com>

> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
> 
> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
> `
> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
> 
> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
> 
> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  module-info

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1843/files
  - new: https://git.openjdk.org/jfx/pull/1843/files/2e1fca33..0f1c0491

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

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

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

From mstrauss at openjdk.org  Sun Jul 13 21:39:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 13 Jul 2025 21:39:29 GMT
Subject: RFR: 8362095: HeaderButtonMetrics should not be used across toolkit
 boundary
Message-ID: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>

The record `com.sun.glass.ui.HeaderButtonMetrics` is used by Glass, but also in the FX layer (in `Stage` and `HeaderBar`). This is architectually unsound, as the FX layer should not directly reference the Glass implementation.

The solution here is to introduce another record that is used in the FX layer, and translate between the Glass/FX types in quantum toolkit.

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

Commit messages:
 - HeaderButtonMetrics refactor

Changes: https://git.openjdk.org/jfx/pull/1846/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362095
  Stats: 64 lines in 7 files changed: 56 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1846.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1846/head:pull/1846

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

From jhendrikx at openjdk.org  Mon Jul 14 07:19:46 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Jul 2025 07:19:46 GMT
Subject: RFR: 8362095: HeaderButtonMetrics should not be used across
 toolkit boundary
In-Reply-To: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
References: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
Message-ID: <UdXr5D00q_Tuk5eXaqrnu49Jp__kVIR0Sa_h4thQdAU=.561a3ec5-f92f-450a-b0e2-8fc085c6dcc5@github.com>

On Sun, 13 Jul 2025 21:34:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The record `com.sun.glass.ui.HeaderButtonMetrics` is used by Glass, but also in the FX layer (in `Stage` and `HeaderBar`). This is architectually unsound, as the FX layer should not directly reference the Glass implementation.
> 
> The solution here is to introduce another record that is used in the FX layer, and translate between the Glass/FX types in quantum toolkit.

Looks fine.

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

Marked as reviewed by jhendrikx (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1846#pullrequestreview-3015036473

From kcr at openjdk.org  Mon Jul 14 12:01:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 12:01:52 GMT
Subject: RFR: 8362095: HeaderButtonMetrics should not be used across
 toolkit boundary
In-Reply-To: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
References: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
Message-ID: <HEJ8He1JbnIJt5-mBoWyKbgWqjM3IgRAjZ1xwBnOazc=.8d60cec8-3778-4c81-a18d-6b8d2e40383c@github.com>

On Sun, 13 Jul 2025 21:34:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The record `com.sun.glass.ui.HeaderButtonMetrics` is used by Glass, but also in the FX layer (in `Stage` and `HeaderBar`). This is architectually unsound, as the FX layer should not directly reference the Glass implementation.
> 
> The solution here is to introduce another record that is used in the FX layer, and translate between the Glass/FX types in quantum toolkit.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1846#pullrequestreview-3016062562

From quizynox at gmail.com  Mon Jul 14 13:20:26 2025
From: quizynox at gmail.com (mkpaz)
Date: Mon, 14 Jul 2025 17:20:26 +0400
Subject: Pluggable image loading and frame size
Message-ID: <a8645062-941e-4e98-b3b1-4d20303ebfe8@gmail.com>

Hello,

I'm testing the new pluggable image API with SVG and noticed one thing.
Since SVG is a scalable vector format, it can be rendered at an arbitrary size.
For this purpose, we need to know the frame (pane) size and scale the image accordingly while rendering.
As I understand, ImageReadParam is used to pass the frame size to the image reader.

public class ImageReadParam extends IIOParam { /** * Returns {@code 
true} if this reader allows the source image to be rendered at an * 
arbitrary size as part of the decoding process ... */ public boolean 
canSetSourceRenderSize() { return canSetSourceRenderSize; } }

But when I set canSetSourceRenderSize to true to activate this, I don't get the client frame size.
Instead, I get the actual image size, which the reader already knows since it implements the getWidth() and getHeight() methods.

I read the code and came across this:
https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/java2d/J2DImageLoader.java#L122 
Why does the image loader use the reader's width and height in both branches?
Shouldn't the loader provide the frame size when canSetSourceRenderSize returns true?
Maybe I'm looking for something that isn't supported? Yet?

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

From kcr at openjdk.org  Mon Jul 14 14:07:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 14:07:51 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <_yUUQcXL8wBwT0l6pnpHGk2lRfJILYkvqyWW71eKwl0=.eb4dfa62-8498-4d48-94dc-2bf8d4e27fcf@github.com>

On Thu, 10 Jul 2025 15:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

@johanvos can you give maintainer approval for this?

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

PR Comment: https://git.openjdk.org/jfx24u/pull/28#issuecomment-3069742426

From kcr at openjdk.org  Mon Jul 14 14:07:50 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 14:07:50 GMT
Subject: Integrated: 8361713: JavaFX API docs overview is missing an intro
 section
In-Reply-To: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
References: <f89j41J6tEWOnjkjgBWYZ6YqnqV5gBFK2LSwBr4b7Ss=.82f3588d-4ef6-49b2-a91b-bb6a4b0c6e80@github.com>
Message-ID: <Wwrn7S8u-RXuDbJTZGv4Plollg9Bemz7hkLtYq0_azY=.ec94e423-33b5-49ad-8c06-140b190df01d@github.com>

On Fri, 11 Jul 2025 00:17:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds an introductory section to the JavaFX API docs similar to that of the JDK docs.
> 
> Compare the [JavaFX 24 API docs](https://download.java.net/java/GA/javafx24/docs/api/index.html) with the [JDK 24 API docs](https://docs.oracle.com/en/java/javase/24/docs/api/index.html).

This pull request has now been integrated.

Changeset: ff408b1c
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ff408b1c6f449ded20323298d235f4a05dcd71bf
Stats:     42 lines in 2 files changed: 41 ins; 0 del; 1 mod

8361713: JavaFX API docs overview is missing an intro section

Reviewed-by: angorya, jvos, iris, mhanl

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

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

From kcr at openjdk.org  Mon Jul 14 14:23:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 14:23:18 GMT
Subject: RFR: 8362079: Change JavaFX release version to 26
Message-ID: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>

Bump the version number of JavaFX to 26. I will integrate this to master as part of forking the jfx25 stabilization branch, which is scheduled for Thursday, July 17, 2025 at 16:00 UTC.

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

Commit messages:
 - 8362079: Change JavaFX release version to 26

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

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

From angorya at openjdk.org  Mon Jul 14 14:40:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Jul 2025 14:40:51 GMT
Subject: RFR: 8359598: [TestBug] VirtualFlowTestUtils should not create a
 temporary Stage [v2]
In-Reply-To: <-kM6dG6Jkeoc4twiNjOjTR9Vu9lp2qwGJgMC_kWfM4c=.39aaa145-5ea1-4d3c-baeb-c87b1bee5a89@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
 <-kM6dG6Jkeoc4twiNjOjTR9Vu9lp2qwGJgMC_kWfM4c=.39aaa145-5ea1-4d3c-baeb-c87b1bee5a89@github.com>
Message-ID: <b0I-5025fMGQzzLuoxjfYzy66ZSbyHpQSwRty4SdnTQ=.65e6be8a-aad7-400c-b3fd-841d9d3a4c9f@github.com>

On Sat, 12 Jul 2025 10:35:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls.
>> 
>> It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise.
>> 
>> Take the following test code:
>> 
>> VirtualFlowTestUtils.clickOnRow(tableView, 2);
>> VirtualFlowTestUtils.clickOnRow(tableView, 4);
>> 
>> 
>> What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after.
>> 
>> This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic.
>> 
>> So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods.
>> 
>> For the example above, this would result in:
>> 
>> stageLoader = new StageLoader(tableView);
>> VirtualFlowTestUtils.clickOnRow(tableView, 2);
>> VirtualFlowTestUtils.clickOnRow(tableView, 4);
>> 
>> 
>> The stageLoader should be disposed in an @AfterEach.
>> 
>> Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty.
>> Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exception message

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1829#pullrequestreview-3016630279

From angorya at openjdk.org  Mon Jul 14 14:49:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 14 Jul 2025 14:49:42 GMT
Subject: RFR: 8362079: Change JavaFX release version to 26
In-Reply-To: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
References: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
Message-ID: <Pxmqfc14O3tPP7VIRYv8PWGpNpbsiBTtwB4Qhle2cso=.50994d6b-c53f-4d63-bbdd-dbe2678d5fe2@github.com>

On Mon, 14 Jul 2025 14:18:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 26. I will integrate this to master as part of forking the jfx25 stabilization branch, which is scheduled for Thursday, July 17, 2025 at 16:00 UTC.

changes are in the same places as in #1673

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1847#pullrequestreview-3016669246

From mhanl at openjdk.org  Mon Jul 14 15:27:48 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 14 Jul 2025 15:27:48 GMT
Subject: Integrated: 8359598: [TestBug] VirtualFlowTestUtils should not create
 a temporary Stage
In-Reply-To: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
References: <uJDGoJaakwrvDt89rCoqD4WkFE2o7el-16YicA1PzY8=.2b565c6c-173d-45ca-a6de-06266a518782@github.com>
Message-ID: <3WeCD-a35O1QRGH31gGpEf-zu_YuT51ydAL_Xsf3O9o=.bd3b340b-c472-435f-8fd9-f5f3832cdf87@github.com>

On Sun, 15 Jun 2025 13:56:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> Currently, the VirtualFlowTestUtils used ONLY for tests has many utility methods to get and do something with the VirtualFlow of Virtualized Controls.
> 
> It has one flaw: It may creates a temporary Stage with the StageLoader, when the Control was never inside a Scene (and Stage) yet. This is done to get the VirtualFlow, which is not possible otherwise.
> 
> Take the following test code:
> 
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> What it does it to create a Stage for the first method and dispose it after. And create another Stage for the second method and dispose it after.
> 
> This does not test a realistic scenario and the chance is quite high that developers used that methods without even knowing that it contains such logic.
> 
> So the idea is to remove the StageLoader code from VirtualFlowTestUtils and rather use it in the Test code before calling the Util methods.
> 
> For the example above, this would result in:
> 
> stageLoader = new StageLoader(tableView);
> VirtualFlowTestUtils.clickOnRow(tableView, 2);
> VirtualFlowTestUtils.clickOnRow(tableView, 4);
> 
> 
> The stageLoader should be disposed in an @AfterEach.
> 
> Note: Nearly all touched tests are indeed much older test code. New tests are not affected and already use it correcty.
> Sometimes a call to `Toolkit.getToolkit().firePulse();` was needed. Previously, creating a new Stage for every call to the util methods did that implicitly.

This pull request has now been integrated.

Changeset: a574d920
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a574d92053a72fce4d30556160282fc801ad5218
Stats:     363 lines in 12 files changed: 293 ins; 43 del; 27 mod

8359598: [TestBug] VirtualFlowTestUtils should not create a temporary Stage

Reviewed-by: angorya

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

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

From mstrauss at openjdk.org  Mon Jul 14 16:44:52 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Jul 2025 16:44:52 GMT
Subject: Integrated: 8362095: HeaderButtonMetrics should not be used across
 toolkit boundary
In-Reply-To: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
References: <rpBI8hYzB3G-_ZpcHCzPNjngzcjbPWntcDXt4FPq5u8=.c0c823a7-e118-4f94-905f-35d67e96bee7@github.com>
Message-ID: <htRzwympj-VGzoRNQC3IHDmC8673JCX_dhr2DcVxsKs=.991c6b26-a125-4edc-ac89-f832a49012e2@github.com>

On Sun, 13 Jul 2025 21:34:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The record `com.sun.glass.ui.HeaderButtonMetrics` is used by Glass, but also in the FX layer (in `Stage` and `HeaderBar`). This is architectually unsound, as the FX layer should not directly reference the Glass implementation.
> 
> The solution here is to introduce another record that is used in the FX layer, and translate between the Glass/FX types in quantum toolkit.

This pull request has now been integrated.

Changeset: 1a2a50b5
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1a2a50b593a1abcb767a3c6b0287996bdfb26973
Stats:     64 lines in 7 files changed: 56 ins; 7 del; 1 mod

8362095: HeaderButtonMetrics should not be used across toolkit boundary

Reviewed-by: jhendrikx, kcr

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

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

From michaelstrau2 at gmail.com  Mon Jul 14 17:35:47 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 14 Jul 2025 19:35:47 +0200
Subject: Pluggable image loading and frame size
In-Reply-To: <a8645062-941e-4e98-b3b1-4d20303ebfe8@gmail.com>
References: <a8645062-941e-4e98-b3b1-4d20303ebfe8@gmail.com>
Message-ID: <CAJEpuXQ9As0bd6GfAYiCgp_G36oKjH6Eh9gCVt12fiK7eoCDxA@mail.gmail.com>

A JavaFX Image always has a fixed size. Usually, this will be the
intrinsic size of the image, but it can also be any other size if the
image is created with the constructor that takes requestedWidth and
requestedHeight.
Internally, the JavaFX Image is stored with an arbitrary pixel
density. There's exactly two ways how you can end up with a pixel
density > 1:
a) use the @Nx image naming convention
b) use a variable-density image loader on a high-DPI screen

Importantly, you won't get a "dynamic" image if you do that (meaning
an image that can have different render sizes), you simply get a
normal JavaFX Image that is loaded with a higher pixel density.
This means that if you have a variable-density image loader and
canSetSourceRenderSize() is true, J2DImageLoader scales the intrinsic
size of the image (or the requested size) with the screen DPI.

A JavaFX Image is not a scene graph node, it doesn't know about where
it is used and how large it ends up on the screen.

I think what you're asking for is one of two things (or both things at once):

1. Allow multiple versions of an image loaded at the same time, and
defer selection until render time. Then choose the best version
depending on the transformed size of the rendered image. This would
work for discrete versions like you get with the @Nx naming
convention.
2. Allow an image to be dynamically rasterized from source depending
on the transformed size of the rendered image. This would work for
variable-density images.

I think that the first option would be a good enhancement. The second
option seems much harder to achieve.



On Mon, Jul 14, 2025 at 3:20?PM mkpaz <quizynox at gmail.com> wrote:
>
> Hello,
>
> I'm testing the new pluggable image API with SVG and noticed one thing.
> Since SVG is a scalable vector format, it can be rendered at an arbitrary size.
> For this purpose, we need to know the frame (pane) size and scale the image accordingly while rendering.
> As I understand, ImageReadParam is used to pass the frame size to the image reader.
>
> public class ImageReadParam extends IIOParam {
>     /**
>      * Returns {@code true} if this reader allows the source image to be rendered at an
>      * arbitrary size as part of the decoding process ...
>      */
>     public boolean canSetSourceRenderSize() {
>         return canSetSourceRenderSize;
>     }
> }
>
> But when I set canSetSourceRenderSize to true to activate this, I don't get the client frame size.
> Instead, I get the actual image size, which the reader already knows since it implements the getWidth() and getHeight() methods.
>
> I read the code and came across this:
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/java2d/J2DImageLoader.java#L122
>
> Why does the image loader use the reader's width and height in both branches?
> Shouldn't the loader provide the frame size when canSetSourceRenderSize returns true?
> Maybe I'm looking for something that isn't supported? Yet?
>
> Best regards.

From mfox at openjdk.org  Mon Jul 14 17:45:24 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 17:45:24 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts
Message-ID: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>

The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.

In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.

One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.

This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.

In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.

(There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into sysmenuinplatform
 - Merge branch 'sysmenuinplatform' of ssh://github.com/beldenfox/jfx into sysmenuinplatform
 - Cleanup and fixed a popup redirection bug.
 - Validating the system menu key event against the originating NSEvent before sending it to NSApp.mainMenu.
 - Merge remote-tracking branch 'upstream/master' into sysmenuinplatform
 - System menu accelerators triggered in scene graph but resolved in platform code

Changes: https://git.openjdk.org/jfx/pull/1848/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354539
  Stats: 220 lines in 13 files changed: 168 ins; 30 del; 22 mod
  Patch: https://git.openjdk.org/jfx/pull/1848.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1848/head:pull/1848

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

From kizune at openjdk.org  Mon Jul 14 17:57:43 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 14 Jul 2025 17:57:43 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
Message-ID: <U6lfSB38PeA22l_DAEDeAFxyN30bfIFxswUHJ0qQdP0=.e1d63115-5b4a-423e-9246-6a81437d8af9@github.com>

On Wed, 9 Jul 2025 05:01:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove explicit jresult declaration

@arapte Can you please take a look?

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

PR Comment: https://git.openjdk.org/jfx/pull/1840#issuecomment-3070458261

From mstrauss at openjdk.org  Mon Jul 14 17:58:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 14 Jul 2025 17:58:46 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@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>
Message-ID: <wmRgO245_5P3pCuPHjzN1okJG8_7FzH16J6BC-LANZ8=.c491ba31-99cc-47f5-af10-a57e2e5be26d@github.com>

On Mon, 7 Jul 2025 16:59:13 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.
>
> 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.

Looks good.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1837#pullrequestreview-3017264997

From mfox at openjdk.org  Mon Jul 14 18:28:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 18:28:48 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@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>
Message-ID: <AUcNl52Bz-klgqjfVbhBe_3GPgmoPjGIgCWkwyeFiUE=.47a91d23-a10c-491e-b2d3-cfe210c38094@github.com>

On Mon, 7 Jul 2025 16:59:13 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.
>
> 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).

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

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

From mfox at openjdk.org  Mon Jul 14 18:39:45 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 18:39:45 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <APvnZbdYKf76szcxnog4E8d-Ktde-kvUm1T7jJJJzNM=.d60b1919-cbdc-4a78-a201-b754f6d95cee@github.com>

On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Implementation of [focus delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).

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

> 8576:     }
> 8577: 
> 8578:     public final void setHoistFocus(boolean value) {

In this PR setting hoistFocus on a control only updates the flag in the control itself. What if the control?s skin introduces sub-nodes? I would assume that setting hoistFocus on a control would automatically set that flag on the control?s entire skin. Is that correct? If so what are the mechanics of making that happen?

It seems hoistFocus is serving two roles. One is an optimization so that requestFocus knows whether it should walk the scene graph looking for a focus-scope node. For that use the flag should be propagated through descendants in the graph. But it?s also being proposed as a hoisting barrier e.g. when it?s *not* set it prevents focus from hoisting upward even if there's a focus-scope node higher up in the graph. But a barrier applies just to a single node and should not be propagated. So I?m having a difficult time figuring out when and how this flag should be propagated through the tree. But I?m no expert on skins so maybe I?m assuming this is more complicated than it actually is.

(P.S. I like this PR, it's a huge improvement over what we've got. I'm just trying to understand how it all works.)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2205569905

From mfox at openjdk.org  Mon Jul 14 18:49:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 18:49:48 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
 <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
 <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>
Message-ID: <hCRB6G_Pk7-LsGwA9JO8Q8vyHabedAB-8722vThIqEk=.f65aad28-5491-4a75-a64e-d642d1617d2d@github.com>

On Sat, 12 Jul 2025 10:14:55 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> Does `resolveFocusDelegate` do what you need?
>> 
>> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.
>> 
>> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.
>> 
>>> For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?
>> 
>> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.
>> 
>> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.
>> 
>> In any case the question is whether a monolithic control with multiple delegates is expected to roll its own internal traversal mechanism or if we need to extend the existing mechanism to include delegates. Having each control roll its own internal traversal would hide it from the accessibility frameworks. And if we expect the existing traversal keys (like Tab) to work internally we should extend the existing traversal machinery to work with delegates.
>
>> > Does `resolveFocusDelegate` do what you need?
>> 
>> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.
> 
> Alright, so a method to get the current delegate would really help there, and I think that information should be available easily enough.
> 
>> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.
> 
> I think the variant with a parameter has a different intent, and so I think we should not attempt to combine the two.
> 
>> > For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?
>> 
>> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.
>> 
>> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.
> 
> Tab would definitely be the most intuitive model, and that's also what I would expect (and how this has worked for such controls since ages past).  So what I think is missing here is that in order to do correct navigation, Scene must be able to query the delegate of its current focus owner.  I think this could be done transparently:
> 
> - This PR already directs events to the current delegate, including events that are interpreted as navigation events
> - Events targeted at a delegate already bubble up in the usual way, eventually reaching Scene
> - Scene, when it wants to act on such an event for navigation, can ask its current focus owner to find out the actual control that received the event (the delegate).  This could be a parameterless `getFocusDelegate` or some such or a property.
> - Scene then initiates the navigation logic from the delegate node (let's say it is in a field of a composed ...

Yeah, I'm sure traversal is solvable, I just wanted to spend some cycles figuring it out. For example, would you set focusTraversable on the date/time control AND it's delegates? My guess is just the delegates but this is the sort of thing one would want to prototype.

To be clear I'm not trying to solve traversal in this round. I just want to make sure we have mapped out the path forward so the API will accommodate traversal eventually.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2205586668

From jhendrikx at openjdk.org  Mon Jul 14 19:02:45 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Jul 2025 19:02:45 GMT
Subject: RFR: 8343956: Focus delegation API
In-Reply-To: <hCRB6G_Pk7-LsGwA9JO8Q8vyHabedAB-8722vThIqEk=.f65aad28-5491-4a75-a64e-d642d1617d2d@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
 <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
 <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>
 <hCRB6G_Pk7-LsGwA9JO8Q8vyHabedAB-8722vThIqEk=.f65aad28-5491-4a75-a64e-d642d1617d2d@github.com>
Message-ID: <C-K0RQQ251pq4IwwU7iIktqUknS36HnzjzlM_NqEJ3Q=.b78142da-268a-4b7f-a25a-bd0199b54760@github.com>

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

>>> > Does `resolveFocusDelegate` do what you need?
>>> 
>>> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.
>> 
>> Alright, so a method to get the current delegate would really help there, and I think that information should be available easily enough.
>> 
>>> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.
>> 
>> I think the variant with a parameter has a different intent, and so I think we should not attempt to combine the two.
>> 
>>> > For example, for keyboard traversal, I don't see why this wouldn't work with multiple delegates (as its similar to having a Skin that has multiple focusable controls)?
>>> 
>>> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.
>>> 
>>> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.
>> 
>> Tab would definitely be the most intuitive model, and that's also what I would expect (and how this has worked for such controls since ages past).  So what I think is missing here is that in order to do correct navigation, Scene must be able to query the delegate of its current focus owner.  I think this could be done transparently:
>> 
>> - This PR already directs events to the current delegate, including events that are interpreted as navigation events
>> - Events targeted at a delegate already bubble up in the usual way, eventually reaching Scene
>> - Scene, when it wants to act on such an event for navigation, can ask its current focus owner to find out the actual control that received the event (the delegate).  This could be a parameterless `getFocusDelegate` or some such or a property.
>> - Scene then initiates the navigation logic from the delegate node (let's ...
>
> Yeah, I'm sure traversal is solvable, I just wanted to spend some cycles figuring it out. For example, would you set focusTraversable on the date/time control AND it's delegates? My guess is just the delegates but this is the sort of thing one would want to prototype.
> 
> To be clear I'm not trying to solve traversal in this round. I just want to make sure we have mapped out the path forward so the API will accommodate traversal eventually.

When I have a few moments, I'll see if I can create the date entry control, and see how it works with this solution.  I can then override Scene code to see if navigation is a quick fix or a huge issue.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2205607111

From jhendrikx at openjdk.org  Mon Jul 14 19:14:45 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Jul 2025 19:14:45 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts
In-Reply-To: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
Message-ID: <CX1Rd6L9q0OqtaCPbz9awHQAEm0akKkHV2wHlZY6WL4=.0265c150-658b-4d01-abe1-b4355db6da27@github.com>

On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
> 
> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
> 
> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
> 
> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
> 
> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
> 
> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

modules/javafx.graphics/src/main/java/com/sun/glass/ui/delegate/MenuBarDelegate.java line 35:

> 33:     public long getNativeMenu();
> 34:     // Returns true if the key event was processed
> 35:     default public boolean handleKeyEvent(int code, int modifiers) {

This should be `public default` or just `default` as everything is always public in an interface anyway.

modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 904:

> 902:                                          new WindowCloseRequestHandler(this),
> 903:                                          new EventHandlerManager(this));
> 904: 

You should remove this unrelated change.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1848#discussion_r2205626389
PR Review Comment: https://git.openjdk.org/jfx/pull/1848#discussion_r2205622373

From mfox at openjdk.org  Mon Jul 14 19:20:51 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 19:20:51 GMT
Subject: Withdrawn: 8091629: [Mac] Support the automatic hiding of the "java"
 menu bar item when using the system menu bar
In-Reply-To: <s-jTHkFqArugvHW26K7wloPJaR33iB1rtWZOOTxEqLE=.bc5ff723-7151-40ed-a04d-0aa7a9a856e2@github.com>
References: <s-jTHkFqArugvHW26K7wloPJaR33iB1rtWZOOTxEqLE=.bc5ff723-7151-40ed-a04d-0aa7a9a856e2@github.com>
Message-ID: <HjqrQJH9ZwzFySBv9Lv9BsAaiBpi4khGMBzXbzIuZHI=.29f2648d-fbf4-4526-ab48-7dfa82eef0cd@github.com>

On Fri, 14 Mar 2025 18:09:23 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On the Mac the application menu (the one to the right of the Apple logo menu) is created by JavaFX and there is no public API to customize or localize it. This PR allows a client to get rid of it and replace it with an entirely custom JavaFX Menu.
> 
> Prior to OS X 10.6 (Snow Leopard) the application menu required special handling. Nowadays it's just the first item in the NSApp's mainMenu. The only restriction is that the OS ignores the item's title and instead uses the application's name as specified in the CFBundle.
> 
> This PR is a work-in-progress/trial balloon. It provides a new property on the MenuBar that controls whether the system will use the default menus. It also supplies the calls necessary to implement the standard menu items "Hide <application>", "Hide Others", and "Show All" which need to be routed to native calls on the NSApplication object. A manual test app is available in tests/manual/controls/DefaultAppMenu.java.

This pull request has been closed without being integrated.

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

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

From jhendrikx at openjdk.org  Mon Jul 14 19:28:47 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 14 Jul 2025 19:28:47 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts
In-Reply-To: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
Message-ID: <LzwoU9OJm_I_HwjpG47hBCK-Bm_y5V-qe4_Kl8oqUeU=.8ac013f6-eb71-4f7b-b274-f40c3d70f1b6@github.com>

On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
> 
> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
> 
> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
> 
> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
> 
> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
> 
> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

Java part looks like a simple enough change.  I can't comment on the native code.

> One could argue that a ComboBox or Spinner shouldn?t consume all key events

They definitely shouldn't, but I think that's how the poor man's focus/event delegation is currently implemented in these controls.

modules/javafx.graphics/src/main/java/com/sun/javafx/stage/WindowEventDispatcher.java line 67:

> 65:             if (supported == SupportedState.TRUE && event.getEventType() == KeyEvent.KEY_PRESSED && (event instanceof KeyEvent)) {
> 66:                Toolkit.getToolkit().getSystemMenu().handleKeyEvent((KeyEvent)event);
> 67:             }

Suggestion:

            if (supported == SupportedState.TRUE && event.getEventType() == KeyEvent.KEY_PRESSED && event instanceof KeyEvent ke) {
               Toolkit.getToolkit().getSystemMenu().handleKeyEvent(ke);
            }

Or perhaps the instanceof is even superfluous, as you already verify it is a KEY_PRESSED event.

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

PR Review: https://git.openjdk.org/jfx/pull/1848#pullrequestreview-3017481535
PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3070707798
PR Review Comment: https://git.openjdk.org/jfx/pull/1848#discussion_r2205630127

From philip.race at oracle.com  Mon Jul 14 19:47:26 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 14 Jul 2025 12:47:26 -0700
Subject: For fonts with localized names, JavaFX cannot find the font by
 the default name on Windows
In-Reply-To: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
References: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
Message-ID: <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>

Font.font will, on Windows, use IDWriteFontCollection::FindFamilyName(..)
The docs for that appear to be silent on whether the matching process 
will check all localized names,
but it sounds like it must not.? I don't see an alternative look up API, 
such as one that accepts a locale arg.

https://learn.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollection 


It seems like the app (which in this case means the FX implementation) 
will have to do this itself which is going to be tedious.

We would need to compare with every localized name of every font on the 
system looking for a match.

And one annoying aspect of this is that until you've done that 
exhaustive search you don't
know if the name the application supplied is present at all on the system.

How would you know that someone mis-spelled Arial as Ariel and not that 
Ariel is the German localized name for Arial ?

So failed lookups will be slow.

In Java 2D we already do this but I'd have hoped DW used by FX was 
better than this than GDI used by 2D.

Also note that
(1) fixing this for DW wouldn't help Linux or Mac so there'd need to be 
separate implementations if they also don't do it automatically
(2) There isn't any FX API which lets you enumerate or access localized 
names, so as you note, that also is an issue.
Although I'm actually a little surprised FX finds ?? but reports 
YouYuan. I would have thought it would be consistent.

I'm also a little surprised that it has taken this long for anyone to 
even implicitly ask for FX to support localized font names.
Java2D has had this support for a very long time.

-phil.

On 7/12/25 4:18 AM, Glavo wrote:
> Hi,
>
> We recently noticed a problem: For fonts with localized names, 
> Font.font(String) can only find the font based on the localized name 
> in the current locale.
>
> For example, the Chinese version of Windows comes with a font called 
> "YouYuan", and its Chinese name is "??".
> When the system language is Chinese, JavaFX has the following behaviors:
>
>     jshell> Font.font("YouYuan")
>     $2 ==> Font[name=System Regular, family=System, style=Regular,
>     size=13.333333015441895]
>
>     jshell> Font.font("??")
>     $3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
>     size=13.333333015441895]
>
>     jshell> $3.getFamily()
>     $4 ==> "YouYuan"
>
>
> As you can see, we cannot find the font based on the English name, we 
> can only use the Chinese name.
> But Font::getName() returns the English name, so we can't get the 
> Chinese name from the Font.
> This makes it impossible to generate a style sheet based on a 
> Font?object, because
>
>     "-fx-font-family: \"%s\";".formatted(font.getFamily())
>
> will not work with these fonts.
>
> The only workaround I can think of is to generate a mapping table from 
> English names to Chinese names like this:
>
>
>     Font.getFamilies().stream().collect(Collectors.toMap(it ->
>     Font.font(it).getFamily(), Function.identity()))
>
>
> But this seems like a lot of overhead :(
>
> So, I want JavaFX to provide the following features:
>
>  1. Regardless of the current system language, Font.font(String)
>     should be able to find the font by its English name;
>  2. Provide a new method Font::getLocalizedFamily() to get the
>     localized name of the font.
>
> Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250714/631d8a1e/attachment-0001.htm>

From mfox at openjdk.org  Mon Jul 14 19:58:22 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 19:58:22 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
Message-ID: <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>

> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
> 
> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
> 
> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
> 
> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
> 
> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
> 
> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)

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

  Review feedback related to code consistency and clarity.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1848/files
  - new: https://git.openjdk.org/jfx/pull/1848/files/f5b05059..411701c6

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

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

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

From philip.race at oracle.com  Mon Jul 14 19:57:37 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 14 Jul 2025 12:57:37 -0700
Subject: For fonts with localized names, JavaFX cannot find the font by
 the default name on Windows
In-Reply-To: <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
References: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
 <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
Message-ID: <41a2608a-3d81-4224-b30f-ea5f89515092@oracle.com>

https://bugs.openjdk.org/browse/JDK-8362197

-phil

On 7/14/25 12:47 PM, Philip Race wrote:
> Font.font will, on Windows, use IDWriteFontCollection::FindFamilyName(..)
> The docs for that appear to be silent on whether the matching process 
> will check all localized names,
> but it sounds like it must not.? I don't see an alternative look up 
> API, such as one that accepts a locale arg.
>
> https://learn.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollection 
>
>
> It seems like the app (which in this case means the FX implementation) 
> will have to do this itself which is going to be tedious.
>
> We would need to compare with every localized name of every font on 
> the system looking for a match.
>
> And one annoying aspect of this is that until you've done that 
> exhaustive search you don't
> know if the name the application supplied is present at all on the system.
>
> How would you know that someone mis-spelled Arial as Ariel and not 
> that Ariel is the German localized name for Arial ?
>
> So failed lookups will be slow.
>
> In Java 2D we already do this but I'd have hoped DW used by FX was 
> better than this than GDI used by 2D.
>
> Also note that
> (1) fixing this for DW wouldn't help Linux or Mac so there'd need to 
> be separate implementations if they also don't do it automatically
> (2) There isn't any FX API which lets you enumerate or access 
> localized names, so as you note, that also is an issue.
> Although I'm actually a little surprised FX finds ?? but reports 
> YouYuan. I would have thought it would be consistent.
>
> I'm also a little surprised that it has taken this long for anyone to 
> even implicitly ask for FX to support localized font names.
> Java2D has had this support for a very long time.
>
> -phil.
>
> On 7/12/25 4:18 AM, Glavo wrote:
>> Hi,
>>
>> We recently noticed a problem: For fonts with localized names, 
>> Font.font(String) can only find the font based on the localized name 
>> in the current locale.
>>
>> For example, the Chinese version of Windows comes with a font called 
>> "YouYuan", and its Chinese name is "??".
>> When the system language is Chinese, JavaFX has the following behaviors:
>>
>>     jshell> Font.font("YouYuan")
>>     $2 ==> Font[name=System Regular, family=System, style=Regular,
>>     size=13.333333015441895]
>>
>>     jshell> Font.font("??")
>>     $3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
>>     size=13.333333015441895]
>>
>>     jshell> $3.getFamily()
>>     $4 ==> "YouYuan"
>>
>>
>> As you can see, we cannot find the font based on the English name, we 
>> can only use the Chinese name.
>> But Font::getName() returns the English name, so we can't get the 
>> Chinese name from the Font.
>> This makes it impossible to generate a style sheet based on a 
>> Font?object, because
>>
>>     "-fx-font-family: \"%s\";".formatted(font.getFamily())
>>
>> will not work with these fonts.
>>
>> The only workaround I can think of is to generate a mapping table 
>> from English names to Chinese names like this:
>>
>>
>>     Font.getFamilies().stream().collect(Collectors.toMap(it ->
>>     Font.font(it).getFamily(), Function.identity()))
>>
>>
>> But this seems like a lot of overhead :(
>>
>> So, I want JavaFX to provide the following features:
>>
>>  1. Regardless of the current system language, Font.font(String)
>>     should be able to find the font by its English name;
>>  2. Provide a new method Font::getLocalizedFamily() to get the
>>     localized name of the font.
>>
>> Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250714/a3dc538e/attachment-0001.htm>

From michaelstrau2 at gmail.com  Mon Jul 14 20:11:47 2025
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 14 Jul 2025 22:11:47 +0200
Subject: Viewport characteristics media features
In-Reply-To: <86c2b5db-4284-4b00-8ec7-3c0b0bc244b8@xpipe.io>
References: <CAJEpuXTqA7Hm2e7VnFYNKhivozVoaUa8aVW+CVTW_LLYDU6XwQ@mail.gmail.com>
 <1b2908c5-8f41-4c27-9d94-e32ed1f8fb6e@xpipe.io>
 <CAJEpuXT_tLXx5f9K6BdorXFo=aY9A1XQc+emRB6_EjdmcKr17Q@mail.gmail.com>
 <1593302d-2e32-4c1f-b422-8f527597258e@xpipe.io>
 <CAJEpuXRM_ZXdL5rHOZMsg7pEU9Eza=HquUM957=Pzw+1OJWrPg@mail.gmail.com>
 <86c2b5db-4284-4b00-8ec7-3c0b0bc244b8@xpipe.io>
Message-ID: <CAJEpuXTp2fq11iYK0YGmmmjKx0Y7iaC8V1x=UHBASuAv9Li2HA@mail.gmail.com>

I assume that custom media queries would follow the same rules as
custom variables. That means that a custom media query defined in a
Scene stylesheet would be accessible in all Parent stylesheets.


On Sun, Jul 13, 2025 at 3:46?AM Christopher Schnick <crschnick at xpipe.io> wrote:
>
> Yeah that would definitely improve the situation when it comes to repetitiveness. Would I need to define such custom media queries per stylesheet or can they apply globally?
>

From kcr at openjdk.org  Mon Jul 14 21:00:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 21:00:44 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v2]
In-Reply-To: <Ttbp8_xBapxRUT26msB5C9pgJKwpn4G0WDxwgGxN0W0=.8123e709-35fa-46bc-96ad-882feb4432f3@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <Ttbp8_xBapxRUT26msB5C9pgJKwpn4G0WDxwgGxN0W0=.8123e709-35fa-46bc-96ad-882feb4432f3@github.com>
Message-ID: <b530xIvJ7mAb6iha2iTH497nbXxl0-6N0U-Kzbr_yYM=.25e6d4c3-b530-4753-a642-14ef9752dd92@github.com>

On Sun, 13 Jul 2025 08:52:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   module-info

This fix is not correct. The problem is that the test program doesn't handle DragOver and DragDropped events. I suspect that the bug should be closed as "Not an issue".

modules/javafx.swing/src/main/java/module-info.java line 39:

> 37:     requires java.datatransfer;
> 38:     requires javafx.base;
> 39:     requires javafx.controls;

This should be reverted. I can think of no reason for the `javafx.swing` module to depend on `javafx.controls`. Drag and drop is not a Controls action. It is a scene graph action.

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

Changes requested by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1843#pullrequestreview-3017613578
PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2205712977

From kcr at openjdk.org  Mon Jul 14 21:00:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 21:00:45 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v2]
In-Reply-To: <OymUNc1FxbMRFRZW4q4HhelV9KBomqWcoxP_-t-ClDY=.8421a46a-6bba-45ae-a87c-2c2e37cc48c8@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <vxTR5BJDEafLQ12_gOlIFxr2ai9Iu5aX__-3LsQ8CXM=.8060d372-0067-4de9-882b-c1969f59ca4c@github.com>
 <gGyWEvexgYEDarc-oXK7gz_BDvXUh0HRMrZNWR-M_Jc=.7ab4fbea-582e-44a4-8b2b-6dbdb4c7dcb8@github.com>
 <myuhxFCIZWATZyCkbuwEmMfXBYOaXY86L5YC8NGRJPU=.a27d8757-f8c6-4630-825c-9e368a52fcb0@github.com>
 <xOMuX0dbDsnZ-eyBA6EmnTcIbo4y9OKgNMWcQIjvs3A=.ac8efab5-3906-4315-8b40-855aadfcd759@github.com>
 <OymUNc1FxbMRFRZW4q4HhelV9KBomqWcoxP_-t-ClDY=.8421a46a-6bba-45ae-a87c-2c2e37cc48c8@github.com>
Message-ID: <VziM9ialfpJGrGMbJB2Usk1U2x7BTtvTFJDfqU18hS8=.90b0678f-5f80-4a4c-b37b-6b736321d225@github.com>

On Fri, 11 Jul 2025 23:23:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> What code path does it take when pasting from an FX component?  Maybe we can look how it differs and try to redirect to that path, so the content gets pasted correctly.
>
> Am I missing something? I can't find any evidence that a JavaFX text input control processes drag-and-drop in any way or that it ever did (though I could only easily look back to jfx14). Did the manual test referenced here ever work?

@beldenfox No, you aren't missing something. The manual test program as written cannot work. There is no automatic drag-and-drop handling for JavaFX controls like TextField.

If I modify the test program to handle drag events in the target TextField, it works as expected. Here are the added lines needed to make it work. I'll attach the modified test program to the bug report.


                        textField.setOnDragOver(event -> {
                            if (event.getGestureSource() != textField &&
                                    event.getDragboard().hasString()) {
                                event.acceptTransferModes(TransferMode.COPY_OR_MOVE);
                            }

                            event.consume();
                        });

                        textField.setOnDragDropped(event -> {
                            Dragboard db = event.getDragboard();
                            boolean success = false;
                            if (db.hasString()) {
                                textField.setText(db.getString());
                                success = true;
                            }
                            event.setDropCompleted(success);

                            event.consume();
                        });

                    }
                });

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1843#discussion_r2205809359

From kcr at openjdk.org  Mon Jul 14 21:40:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 14 Jul 2025 21:40:46 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v9]
In-Reply-To: <Mv1KQt1JDzxH1OtRRBcZObcl1gbobNPBUnmwT3Enk5s=.8ef19420-0b0d-4512-8139-60d31d9b00e5@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <Mv1KQt1JDzxH1OtRRBcZObcl1gbobNPBUnmwT3Enk5s=.8ef19420-0b0d-4512-8139-60d31d9b00e5@github.com>
Message-ID: <HvzmnwuYijtZw1xySDBYpOaob_ON3LhcKeAEoTXyxGo=.1d37fdd0-b629-4902-a8e9-3f0f51e522ad@github.com>

On Fri, 11 Jul 2025 22:42:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 55 more: https://git.openjdk.org/jfx/compare/04c5e40c...7bdb6ac7

The implementation looks reasonable. I'll do some sanity testing.

Speaking of testing... I don't see any unit tests for this. At the very least you should add tests for the new API methods.

Functional tests are also needed. Those could be done in a follow-up issue, as long as they are targeted to jfx25 (the tests can come in during rampdown).

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

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3017906570

From mfox at openjdk.org  Mon Jul 14 21:50:45 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 14 Jul 2025 21:50:45 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
Message-ID: <c0CLVmt2ZliKLNwuX27Sk_r2Fvmay96Q_MuuX4MM9EM=.80bdea1f-8077-4862-b2a4-6da17227184b@github.com>

On Fri, 4 Jul 2025 06:59:24 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Parameterize StageFocusTest
>    
>    This is to check if Stage showing works also for Stages other than the
>    primary Stage provided by Application.start()
>  - Review fixes; revert using VisualTestBase

Code looks fine. I left a comment about providing a help message when the color sampling test fails.

What does it mean to integrate this? We would be adding a test designed to fail with the default testing environment. After failure a developer would have to re-run with the no daemon flag set. Shouldn't that become the default? If not, can we ensure this test runs early so it truly serves as a canary test? Should folks developing new tests assume that they don't have to add the usual workarounds like sending a mouse click to the window?

FWIW, adding the no daemon flag ensures that this test succeeds consistently with Cygwin. With the Mingw shell turning off the daemon increases the chance that it will succeed but doesn't guarantee it.

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 204:

> 202:         // check if window is on top
> 203:         Util.runAndWait(() -> {
> 204:             WritableImage capture = robot.getScreenCapture(null, STAGE_X, STAGE_Y, STAGE_SIZE, STAGE_SIZE, false);

If the color test fails the developer doesn't see the helpful message telling them to use `--no-deamon` to patch things up.

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

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-3017898964
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2205867287

From kcr at openjdk.org  Tue Jul 15 01:13:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 01:13:48 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
Message-ID: <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>

On Mon, 7 Jul 2025 17:56:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Specify A as a double.

I left one inline comment about the need for copyright headers.

I did a quick first pass, and this looks like a reasonable replacement for the Headless monocle platform to support running headless tests. It has the advantage of not needing to manually add monocle, which is not shipped on desktop platforms.

This is effectively an experimental feature used for testing. Since there is no API, and it is only enabled by setting a (as yet undocumented) system property, it seems OK that it isn't complete and doesn't have an associated CSR.

Longer term, we will want to think about how this might evolve. The first question is: Does this have any use case beyond testing? AWT has a headless mode that developers can use for server-side rendering. We have discussed the possibility of adding a similar feature for JavaFX, although it is less clear how it would be used, since we don't have image APIs that would be expected for such applications.

Even if this remains a testing feature, how should it eventually be configured? Using system properties? Some sort of config file? Something else?

How should this interact with the AWT headless toolkit? Or does it?

This requires the prism SW pipeline. How / where should be document this restriction?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 1:

> 1: package com.sun.glass.ui.headless;

All of the new files need a standard copyright header.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 141:

> 139:             float scaleX = 1.f;
> 140:             float scaleY = 1.f;
> 141:             String scale = System.getProperty("glass.gtk.uiScale");

"gtk" ?

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3017927741
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2205886360
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2205920463

From psadhukhan at openjdk.org  Tue Jul 15 03:38:20 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 15 Jul 2025 03:38:20 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v3]
In-Reply-To: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
Message-ID: <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>

> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
> 
> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
> `
> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
> 
> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
> 
> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Revert module-info change
 - Update test with setOnDragOver and setOnDragDropped

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1843/files
  - new: https://git.openjdk.org/jfx/pull/1843/files/0f1c0491..fb145e9b

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

  Stats: 75 lines in 4 files changed: 28 ins; 38 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1843.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1843/head:pull/1843

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

From psadhukhan at openjdk.org  Tue Jul 15 03:38:21 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 15 Jul 2025 03:38:21 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v2]
In-Reply-To: <Ttbp8_xBapxRUT26msB5C9pgJKwpn4G0WDxwgGxN0W0=.8123e709-35fa-46bc-96ad-882feb4432f3@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <Ttbp8_xBapxRUT26msB5C9pgJKwpn4G0WDxwgGxN0W0=.8123e709-35fa-46bc-96ad-882feb4432f3@github.com>
Message-ID: <9-jEtJ12ogTWyALfGkX8F9fX-iv5yBvAyP2nF8MhbQY=.60c0f427-d453-43a3-a764-085f5936c43d@github.com>

On Sun, 13 Jul 2025 08:52:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   module-info

Ok..This is what was missing as mentioned in the PR description "Scene creates DragEvent with only DragEvent.ANY
so handleDragEnter and handleDragDrop returns null as DragEvent.getAcceptedTransferMode returns null"
wherein acceptedTransferMode was null..
I didn't know we need to set the transfermode on DRAG_OVER (so that DragEvent gets DRAG_OVER eventType instead of DragEvent.ANY) and setDropCompleted from the test itself and I was trying to do in the code along with setText assuming test was correct.
Thanks for the clarification.

I have updated the test

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3071776055

From arapte at openjdk.org  Tue Jul 15 05:05:02 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:05:02 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v7]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <JVmkZ8_FMCa5TNmmJEhIWfA8L_OATfvyrxMm266cC6Q=.643c9941-d1f6-4c5c-8aab-a0da89709cb6@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:

  review-update: jni method refactoring

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/e8ac354a..b8be34a5

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

  Stats: 523 lines in 11 files changed: 227 ins; 233 del; 63 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 Jul 15 05:41:32 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:41:32 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@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:

  changes for running apps in eclipse

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/b8be34a5..fe40d04d

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

  Stats: 4 lines in 2 files changed: 2 ins; 0 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 Jul 15 05:41:34 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:41:34 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v4]
In-Reply-To: <vV30OHb08gx26owOe_1_czcHd680PfVmlC3k-P3ycmQ=.51d079c1-8175-4ef9-8d6e-4d3c00622bbd@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
 <vV30OHb08gx26owOe_1_czcHd680PfVmlC3k-P3ycmQ=.51d079c1-8175-4ef9-8d6e-4d3c00622bbd@github.com>
Message-ID: <S7voer3VIizJVIakknVr_Bq1y89Y5LbBf8kmxa57ZOI=.42e9dab9-0f7e-4dd5-8c64-b785f68c6b2d@github.com>

On Thu, 26 Jun 2025 12:05:14 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use appropriate layer for setting opacity
>
> modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.h line 78:
> 
>> 76:     id<MTLRenderCommandEncoder> phongEncoder;
>> 77:     id<MTLRenderCommandEncoder> lastPhongEncoder;
>> 78:     MetalShader* currentShader;
> 
> Might be my obj-C lack-of-knowledge - why some objects here use pointers, while others use `id<>`?

They are little similar with `*` offering more type safety. But in our case we have used `id<>` for metal library objects and `*` instances of interfaces from our implementation.

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

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

From arapte at openjdk.org  Tue Jul 15 05:41:36 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:41:36 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>
Message-ID: <CyIKxHYMf85PyZtk2RFnpaHQ0k2kBLr3zxWZeR1VZxk=.e36213f8-486c-4ba9-938a-503d490d22e1@github.com>

On Tue, 8 Jul 2025 10:50:32 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add @Override
>
> modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1437:
> 
>> 1435:     [pCtx endCurrentRenderEncoder];
>> 1436: 
>> 1437:     id<MTLCommandBuffer> commandBuffer = [pCtx getCurrentCommandBuffer];
> 
> I think most of this function should become a `MetalContext` method that would be called here. That way we separate the Metal-related implementation from JNI entry points and it follows the pattern of other JNI entry points in this file.

Thanks for noticing this. As you pointed out there were a few more similar methods that needed change.
All such methods are now updated. Along with there are a few minor changes like, removing methods and method parameters that are not used/can be avoided.

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

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

From arapte at openjdk.org  Tue Jul 15 05:45:46 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:45:46 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline
In-Reply-To: <0hfPZORC7trBy8iv9Oa8e8Ks_yIunsvCcQzMnnpGs70=.daab54a6-6ad9-4034-b9bc-985659b77526@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <0hfPZORC7trBy8iv9Oa8e8Ks_yIunsvCcQzMnnpGs70=.daab54a6-6ad9-4034-b9bc-985659b77526@github.com>
Message-ID: <OfqT5E16Mfj2GjRsEX8bZwDtjWlF2sEEzJqYT52IESU=.3d6b87f9-b197-4abd-92c8-232a7da5157b@github.com>

On Thu, 12 Jun 2025 23:30:24 GMT, Kevin Rushforth <kcr 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...
>
> @tiainen Would you be able to look at the build changes and also do a test build?

> Got it running in Eclipse (thank you @kevinrushforth !), please pick up changes from this branch: https://github.com/andy-goryachev-oracle/jfx/tree/ag.metal

Thank you @andy-goryachev-oracle @kevinrushforth , I have included the change from your branch, tested that regular build and lunching apps from terminal works same as before.

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

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

From arapte at openjdk.org  Tue Jul 15 05:45:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 05:45:47 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <_TU9x-AWFu4Yy8IOIWQAXMWCas58ojuTr2v59ssDnq8=.63ca6e27-fedb-41e0-a8e4-c5bd44d526ef@github.com>
Message-ID: <POL1S3MitOb3zXu8OuGZoOE5t0WBN4vD6SPVVBXzt_4=.d4a01dfa-ee47-4d0a-a3b4-1cf6c00cc454@github.com>

On Tue, 8 Jul 2025 11:49:28 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add @Override
>
> modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m line 167:
> 
>> 165:         pipeState = [[context getPipelineManager] getPipeStateWithFragFunc:fragmentFunction
>> 166:                                                              compositeMode:compositeMode];
>> 167:         [psDict setObject:pipeState forKey:keyCompMode];
> 
> I am not 100% sure why there is a need to duplicate PipelineState dictionaries here and to create a Shader-specific cache of States. If you need to get a PipelineState, why not always directly call on `MetalPipelineManager`?

In MetalPipelineManager, we store phong and clear pipeline states and rest all are stored in mtl shader.
The differentiation was needed as clear pipeline state and phong pipeline state are created and used differently in 3D and 2D rendering. so, we have stored them in separate dictionaries.

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

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

From quizynox at gmail.com  Tue Jul 15 05:46:28 2025
From: quizynox at gmail.com (mkpaz)
Date: Tue, 15 Jul 2025 09:46:28 +0400
Subject: Pluggable image loading and frame size
In-Reply-To: <CAJEpuXQ9As0bd6GfAYiCgp_G36oKjH6Eh9gCVt12fiK7eoCDxA@mail.gmail.com>
References: <a8645062-941e-4e98-b3b1-4d20303ebfe8@gmail.com>
 <CAJEpuXQ9As0bd6GfAYiCgp_G36oKjH6Eh9gCVt12fiK7eoCDxA@mail.gmail.com>
Message-ID: <CAASO9vRSpXT6APvywrbJRd5Rm+BMTx06BNU-JoR9u91ONteVqw@mail.gmail.com>

Hello,

Thank you for the clarification.
I thought the width and height in the loader referred to the preferred size.

Since SVG is essentially XML, manipulating it at runtime is straightforward.
We can generate an image at a specific breakpoint and change it using a
data URI.
Additionally, viewport media support will likely provide even more
flexibility.

.pane {
  -fx-background-image: url("/image.svg");
}

@media (812px <= width <= 1024px) {
  .pane {
    -fx-background-image: url("/image-x2.svg");
  }
}

I created a demo repository that demonstrates loading and transforming SVG
using the jsvg library.

https://github.com/mkpaz/jsvgfx

Best regards.

??, 14 ???. 2025??. ? 21:35, Michael Strau? <michaelstrau2 at gmail.com>:

> A JavaFX Image always has a fixed size. Usually, this will be the
> intrinsic size of the image, but it can also be any other size if the
> image is created with the constructor that takes requestedWidth and
> requestedHeight.
> Internally, the JavaFX Image is stored with an arbitrary pixel
> density. There's exactly two ways how you can end up with a pixel
> density > 1:
> a) use the @Nx image naming convention
> b) use a variable-density image loader on a high-DPI screen
>
> Importantly, you won't get a "dynamic" image if you do that (meaning
> an image that can have different render sizes), you simply get a
> normal JavaFX Image that is loaded with a higher pixel density.
> This means that if you have a variable-density image loader and
> canSetSourceRenderSize() is true, J2DImageLoader scales the intrinsic
> size of the image (or the requested size) with the screen DPI.
>
> A JavaFX Image is not a scene graph node, it doesn't know about where
> it is used and how large it ends up on the screen.
>
> I think what you're asking for is one of two things (or both things at
> once):
>
> 1. Allow multiple versions of an image loaded at the same time, and
> defer selection until render time. Then choose the best version
> depending on the transformed size of the rendered image. This would
> work for discrete versions like you get with the @Nx naming
> convention.
> 2. Allow an image to be dynamically rasterized from source depending
> on the transformed size of the rendered image. This would work for
> variable-density images.
>
> I think that the first option would be a good enhancement. The second
> option seems much harder to achieve.
>
>
>
> On Mon, Jul 14, 2025 at 3:20?PM mkpaz <quizynox at gmail.com> wrote:
> >
> > Hello,
> >
> > I'm testing the new pluggable image API with SVG and noticed one thing.
> > Since SVG is a scalable vector format, it can be rendered at an
> arbitrary size.
> > For this purpose, we need to know the frame (pane) size and scale the
> image accordingly while rendering.
> > As I understand, ImageReadParam is used to pass the frame size to the
> image reader.
> >
> > public class ImageReadParam extends IIOParam {
> >     /**
> >      * Returns {@code true} if this reader allows the source image to be
> rendered at an
> >      * arbitrary size as part of the decoding process ...
> >      */
> >     public boolean canSetSourceRenderSize() {
> >         return canSetSourceRenderSize;
> >     }
> > }
> >
> > But when I set canSetSourceRenderSize to true to activate this, I don't
> get the client frame size.
> > Instead, I get the actual image size, which the reader already knows
> since it implements the getWidth() and getHeight() methods.
> >
> > I read the code and came across this:
> >
> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/java2d/J2DImageLoader.java#L122
> >
> > Why does the image loader use the reader's width and height in both
> branches?
> > Shouldn't the loader provide the frame size when canSetSourceRenderSize
> returns true?
> > Maybe I'm looking for something that isn't supported? Yet?
> >
> > Best regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250715/40fae256/attachment.htm>

From lkostyra at openjdk.org  Tue Jul 15 09:16:47 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 15 Jul 2025 09:16:47 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <c0CLVmt2ZliKLNwuX27Sk_r2Fvmay96Q_MuuX4MM9EM=.80bdea1f-8077-4862-b2a4-6da17227184b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
 <c0CLVmt2ZliKLNwuX27Sk_r2Fvmay96Q_MuuX4MM9EM=.80bdea1f-8077-4862-b2a4-6da17227184b@github.com>
Message-ID: <ITZ5M-8pYQFqu5T4jbd75dCw3QkX2Ra3T42SLEYod_k=.063c4e4a-bfb0-4686-b57b-ddd5ce906b7f@github.com>

On Mon, 14 Jul 2025 21:48:03 GMT, Martin Fox <mfox at openjdk.org> wrote:

>What does it mean to integrate this? We would be adding a test designed to fail with the default testing environment. After failure a developer would have to re-run with the no daemon flag set. Shouldn't that become the default?

I agree that this way of running the tests should be the default but there is no way (as far as I know) to do this from the project level. The only path would be to add a `gradle.properties` file in the project root but we don't have one and it is ignored via gitignore. We only have a template which you need to copy-paste and rename to `gradle.properties`. As I understand it, different developers might need different ways of configuring gradle for their own needs, which should not be pushed to the repository or tracked by Git as meaningful changes.

According to [Gradle manual](https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon) other ways to disable the daemon are user-specific (`--no-daemon` flag, user-wide or system-wide property).

>If not, can we ensure this test runs early so it truly serves as a canary test?

I am not sure if that is possible, the only thing coming to my mind is executing that test specifically via `build.gradle` before running the whole suite. I'd be happy to get suggestions if anyone else knows something (ex. from JUnit) that could help it.

>Should folks developing new tests assume that they don't have to add the usual workarounds like sending a mouse click to the window?

Some tests did that, some tests did not. This whole ordeal started because `MenuDoubleShortcutTest` seemingly crashed mid-execution, later I found out the problem is Windows' focus stealing policy when you run the tests - test window was not in focus, the terminal was, so when the test program sent Ctrl+C for test purposes it was delivered to the terminal with obvious results. Before that was the case (and judging by how native calls like `_setVisible` behave) the assumption was that showing the Stage means it gets focus.

I have a patch queued up after this gets introduced which fixes the problem we talked about earlier with `Window.isFocused()` API being incorrect. Ideally I would hope that tests requiring sending some inputs to the Stage will call that function and fail early (like some other tests already do).

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3072831587

From jvos at openjdk.org  Tue Jul 15 11:34:48 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 15 Jul 2025 11:34:48 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
 <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
Message-ID: <6MN7eVg2rBzq_H_AORD1oE1cDI5qNitk7PWwq57kwAE=.fe893750-a6c1-4b92-a0ad-26d01878b4e8@github.com>

On Tue, 15 Jul 2025 01:11:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The first question is: Does this have any use case beyond testing?

Good question, and the answer is "Yes, absolutely". One of the main drivers for this was a project where PDF prints need to be generated server-side, starting from `Node.snapShot(... WritableImage)`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3073251727

From kcr at openjdk.org  Tue Jul 15 13:48:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 13:48:48 GMT
Subject: [jfx24u] RFR: Merge 82638ae10dad52ac9eee4201d7eee74a09277993
Message-ID: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>

Clean merge of July CPU content into `jfx24u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

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

Commit messages:
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8348118: Update JavaFX release version for Jul 2025 CPU

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx24u/pull/29/files
  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/29/head:pull/29

PR: https://git.openjdk.org/jfx24u/pull/29

From kcr at openjdk.org  Tue Jul 15 13:49:28 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 13:49:28 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2 [v2]
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <QkTdRM---rxsdQbC2Pyssc6_GgbxHSgw2Zn8wH4MgzY=.9f844b73-181b-4044-acbd-8993e2a6c1cd@github.com>

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  No security content

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

Changes:
  - all: https://git.openjdk.org/jfx24u/pull/28/files
  - new: https://git.openjdk.org/jfx24u/pull/28/files/2b4e4376..74cf99c1

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

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

PR: https://git.openjdk.org/jfx24u/pull/28

From arapte at openjdk.org  Tue Jul 15 13:55:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 15 Jul 2025 13:55:47 GMT
Subject: [jfx24u] RFR: Merge 82638ae10dad52ac9eee4201d7eee74a09277993
In-Reply-To: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
References: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
Message-ID: <M06hIcOhKRgqKLDMvZbTbhulG0VUR9GO4ybJFpNwp2c=.dd0c5750-e06c-404e-9e19-10db44cedf79@github.com>

On Tue, 15 Jul 2025 13:44:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of July CPU content into `jfx24u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx24u/pull/29#pullrequestreview-3020449177

From kcr at openjdk.org  Tue Jul 15 14:09:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 14:09:43 GMT
Subject: [jfx24u] RFR: Merge 82638ae10dad52ac9eee4201d7eee74a09277993 [v2]
In-Reply-To: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
References: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
Message-ID: <5k0lxTNNF0EkcWtmuSA0T_kxNo9i_eVBrXRJHCuloJU=.5ab8e853-25b4-4642-a17a-e850121d1baa@github.com>

> Clean merge of July CPU content into `jfx24u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

Kevin Rushforth 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.

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

Changes:
  - all: https://git.openjdk.org/jfx24u/pull/29/files
  - new: https://git.openjdk.org/jfx24u/pull/29/files/82638ae1..82638ae1

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

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

PR: https://git.openjdk.org/jfx24u/pull/29

From kcr at openjdk.org  Tue Jul 15 14:09:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 14:09:44 GMT
Subject: [jfx24u] Integrated: Merge 82638ae10dad52ac9eee4201d7eee74a09277993
In-Reply-To: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
References: <Gupcq-ex8_1QJNNxI3atIkSuCZn_hfbe7ResUgiq8PI=.d68b9e63-9a6d-42d6-8d85-e5aa2255206f@github.com>
Message-ID: <38MmHyAp4kg0611OIbLcKSx917QXd0Lm-NtTgPkEsuU=.23bf147f-52c5-494f-abdb-4b20629f0e2d@github.com>

On Tue, 15 Jul 2025 13:44:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of July CPU content into `jfx24u:master`. Note that this is a no-op merge, since the only content is some identity merge commits (so there are no changes to the contents of the repo).

This pull request has now been integrated.

Changeset: c75745bc
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/c75745bc29d639803aa64cf5c83269237c17c4f9
Stats:     0 lines in 0 files changed: 0 ins; 0 del; 0 mod

Merge

Reviewed-by: arapte

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

PR: https://git.openjdk.org/jfx24u/pull/29

From zjx001202 at gmail.com  Tue Jul 15 14:21:57 2025
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 15 Jul 2025 22:21:57 +0800
Subject: For fonts with localized names, JavaFX cannot find the font by
 the default name on Windows
In-Reply-To: <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
References: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
 <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
Message-ID: <CAJL5A3=EC5T=P4d-s1bV8v1q-KbOd-D7C_MO+7FyNUw+ow1N+g@mail.gmail.com>

Hi Philip,

Thanks for your reply.

> (1) fixing this for DW wouldn't help Linux or Mac so there'd need to be
separate implementations if they also don't do it automatically

I also tested on Linux and macOS. I think this problem does not exist on
these two platforms.
JavaFX uses the English font family names everywhere on both platforms,
rather than the localized names, so this problem does not occur.

However, I encountered another annoying behavior on macOS:

jshell> Font.getFamilies().stream().filter(it -> it.contains("JetBrains
Mono")).toList()
$2 ==> [JetBrains Mono, JetBrains Mono NL]

jshell> Font.font("JetBrains Mono")
$3 ==> Font[name=JetBrains Mono Medium, family=JetBrains Mono Medium,
style=Regular, size=13.0]

jshell> $3.getFamily()
$4 ==> "JetBrains Mono Medium"

jshell> Font.font("JetBrains Mono Medium")
$5 ==> Font[name=System Regular, family=System, style=Regular, size=13.0]


As you can see, multiple weights of a font on macOS are unified into the
same font family.
We can find a Font by this font family name, but the family name returned
by Font:getFamily() includes the weight,
and we cannot find the font based on the returned name.
This problem does not occur on Linux and Windows, because those platforms
do not unify fonts into a single family.

Besides these issues, I also get tired of the subtle differences in
behavior between different platforms.
Can we bridge the differences in how JavaFX handles font family names on
different platforms?

Glavo

On Tue, Jul 15, 2025 at 3:50?AM Philip Race <philip.race at oracle.com> wrote:

> Font.font will, on Windows, use IDWriteFontCollection::FindFamilyName(..)
> The docs for that appear to be silent on whether the matching process will
> check all localized names,
> but it sounds like it must not.  I don't see an alternative look up API,
> such as one that accepts a locale arg.
>
>
> https://learn.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollection
>
> It seems like the app (which in this case means the FX implementation)
> will have to do this itself which is going to be tedious.
>
> We would need to compare with every localized name of every font on the
> system looking for a match.
>
> And one annoying aspect of this is that until you've done that exhaustive
> search you don't
> know if the name the application supplied is present at all on the system.
>
> How would you know that someone mis-spelled Arial as Ariel and not that
> Ariel is the German localized name for Arial ?
>
> So failed lookups will be slow.
>
> In Java 2D we already do this but I'd have hoped DW used by FX was better
> than this than GDI used by 2D.
> Also note that
> (1) fixing this for DW wouldn't help Linux or Mac so there'd need to be
> separate implementations if they also don't do it automatically
> (2) There isn't any FX API which lets you enumerate or access localized
> names, so as you note, that also is an issue.
> Although I'm actually a little surprised FX finds ?? but reports YouYuan.
> I would have thought it would be consistent.
>
> I'm also a little surprised that it has taken this long for anyone to even
> implicitly ask for FX to support localized font names.
> Java2D has had this support for a very long time.
>
> -phil.
>
> On 7/12/25 4:18 AM, Glavo wrote:
>
> Hi,
>
> We recently noticed a problem: For fonts with localized names,
> Font.font(String) can only find the font based on the localized name in
> the current locale.
>
> For example, the Chinese version of Windows comes with a font called
> "YouYuan", and its Chinese name is "??".
> When the system language is Chinese, JavaFX has the following behaviors:
>
> jshell> Font.font("YouYuan")
> $2 ==> Font[name=System Regular, family=System, style=Regular,
> size=13.333333015441895]
>
> jshell> Font.font("??")
> $3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
> size=13.333333015441895]
>
> jshell> $3.getFamily()
> $4 ==> "YouYuan"
>
>
> As you can see, we cannot find the font based on the English name, we can
> only use the Chinese name.
> But Font::getName() returns the English name, so we can't get the Chinese
> name from the Font.
> This makes it impossible to generate a style sheet based on a Font
>  object, because
>
> "-fx-font-family: \"%s\";".formatted(font.getFamily())
>
> will not work with these fonts.
>
> The only workaround I can think of is to generate a mapping table from
> English names to Chinese names like this:
>
>
> Font.getFamilies().stream().collect(Collectors.toMap(it ->
> Font.font(it).getFamily(), Function.identity()))
>
>
> But this seems like a lot of overhead :(
>
> So, I want JavaFX to provide the following features:
>
>    1. Regardless of the current system language, Font.font(String) should
>    be able to find the font by its English name;
>    2. Provide a new method Font::getLocalizedFamily() to get the
>    localized name of the font.
>
> Glavo
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250715/7c1d63bb/attachment.htm>

From angorya at openjdk.org  Tue Jul 15 14:32:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 14:32:54 GMT
Subject: [jfx24u] RFR: 8361887: Create release notes for JavaFX 24.0.2 [v2]
In-Reply-To: <QkTdRM---rxsdQbC2Pyssc6_GgbxHSgw2Zn8wH4MgzY=.9f844b73-181b-4044-acbd-8993e2a6c1cd@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
 <QkTdRM---rxsdQbC2Pyssc6_GgbxHSgw2Zn8wH4MgzY=.9f844b73-181b-4044-acbd-8993e2a6c1cd@github.com>
Message-ID: <rheuTlW-W6EuLe1pmGVc8NlCSC4l5-2Gj8XH4oVZGUI=.f7ec77ea-c204-4a3e-b11d-1255d0199bbf@github.com>

On Tue, 15 Jul 2025 13:49:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 24.0.2.
>> 
>> Notes to reviewers:
>> 
>> I used the following filter to pick the issues:
>> 
>> https://bugs.openjdk.org/issues/?filter=47734
>> 
>> The original filter, with the backport IDs, is here:
>> 
>> https://bugs.openjdk.org/issues/?filter=47733
>> 
>> As usual, I excluded test bugs, cleanup bugs, etc.
>> 
>> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No security content

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx24u/pull/28#pullrequestreview-3020688184

From kcr at openjdk.org  Tue Jul 15 14:32:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 14:32:55 GMT
Subject: [jfx24u] Integrated: 8361887: Create release notes for JavaFX 24.0.2
In-Reply-To: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
References: <-Bqt_WBEuHHX5YM4jrg7HJaMtIrGDQfNwVp5v2KPV4E=.2c6ab34e-2bce-4893-ba32-ecb98782608c@github.com>
Message-ID: <Z372eM4uJ2Qc5wmlUui1QYZiM6m6RvOWaNPXOWl_xjk=.2cc075bd-c2bd-4ceb-bd0e-b79e61ec31a7@github.com>

On Thu, 10 Jul 2025 15:27:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 24.0.2.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=47734
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=47733
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2025-07-15, I will add any security bugs and ask for a re-review.

This pull request has now been integrated.

Changeset: a306794f
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/a306794fa239dae0c1d9048d3fa5fbf8574f3c7b
Stats:     24 lines in 1 file changed: 24 ins; 0 del; 0 mod

8361887: Create release notes for JavaFX 24.0.2

Reviewed-by: angorya

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

PR: https://git.openjdk.org/jfx24u/pull/28

From angorya at openjdk.org  Tue Jul 15 17:32:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 17:32:31 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v10]
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - test
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - link
 - oops
 - since 25
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
 - final tab stop
 - ... and 57 more: https://git.openjdk.org/jfx/compare/1a2a50b5...5252633b

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

Changes: https://git.openjdk.org/jfx/pull/1744/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1744&range=09
  Stats: 701 lines in 13 files changed: 671 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/jfx/pull/1744.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1744/head:pull/1744

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

From angorya at openjdk.org  Tue Jul 15 17:34:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 17:34:50 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v9]
In-Reply-To: <Mv1KQt1JDzxH1OtRRBcZObcl1gbobNPBUnmwT3Enk5s=.8ef19420-0b0d-4512-8139-60d31d9b00e5@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <Mv1KQt1JDzxH1OtRRBcZObcl1gbobNPBUnmwT3Enk5s=.8ef19420-0b0d-4512-8139-60d31d9b00e5@github.com>
Message-ID: <dgX14bI_Tmgaec1HxvBEtEr_jjyv29qe0FnnWP5vAAQ=.b60895f7-6466-488f-a76c-45bb327d8117@github.com>

On Fri, 11 Jul 2025 22:42:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - ... and 55 more: https://git.openjdk.org/jfx/compare/04c5e40c...7bdb6ac7

Good point!

Added comprehensive test, thanks to the latest changes that made the StubTextLayout work essentially like the real one, and the new LayoutInfo API.

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

PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-3074571468

From kcr at openjdk.org  Tue Jul 15 17:38:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 17:38:44 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v3]
In-Reply-To: <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
Message-ID: <Kgnun7tMkVWC9ixyC7LnAlvm8uOnyiYbupoHt2Oalak=.76167ad7-09b0-402b-a502-407375f5d3b2@github.com>

On Tue, 15 Jul 2025 03:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert module-info change
>  - Update test with setOnDragOver and setOnDragDropped

Looks good. I changed the title of the JBS issue to reflect that this is a problem with the test. You will need to change this PR title to match before you integrate.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1843#pullrequestreview-3021493625

From angorya at openjdk.org  Tue Jul 15 17:43:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 17:43:47 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v3]
In-Reply-To: <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
Message-ID: <Pz7i1zW4pzMW3XCE23DrapX8bXwMm-UEiQAe7i8tiuE=.2f124b75-523c-420d-b7b6-ba26261d89c9@github.com>

On Tue, 15 Jul 2025 03:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert module-info change
>  - Update test with setOnDragOver and setOnDragDropped

Maybe also update the description in this PR and the ticket?

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3074623646

From mfox at openjdk.org  Tue Jul 15 17:45:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 15 Jul 2025 17:45:48 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <ITZ5M-8pYQFqu5T4jbd75dCw3QkX2Ra3T42SLEYod_k=.063c4e4a-bfb0-4686-b57b-ddd5ce906b7f@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
 <c0CLVmt2ZliKLNwuX27Sk_r2Fvmay96Q_MuuX4MM9EM=.80bdea1f-8077-4862-b2a4-6da17227184b@github.com>
 <ITZ5M-8pYQFqu5T4jbd75dCw3QkX2Ra3T42SLEYod_k=.063c4e4a-bfb0-4686-b57b-ddd5ce906b7f@github.com>
Message-ID: <6D8i7Bge2K4-tc9bhaxMos4bmTE3JzGocdvLfsfagE4=.dfa9ad7a-7b90-4c1f-897f-724620bbf0ad@github.com>

On Tue, 15 Jul 2025 09:13:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Some tests did that, some tests did not. This whole ordeal started because `MenuDoubleShortcutTest` seemingly crashed mid-execution [?]

Ack! I wrote that test! And I should know better. I'll make sure it gets focus and stops using Ctrl+C as a test case.

I'm sure I ran MenuDoubleShortcutTest on Windows before submitting it. I just tried it again and it worked fine. Once. The second time it failed. I wish we could find a formula which guarantees these tests always work OR that they always fail.

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3074639117

From kcr at openjdk.org  Tue Jul 15 17:55:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 17:55:46 GMT
Subject: RFR: 8141391: DnD doesn't work for JFXPanel [v3]
In-Reply-To: <Pz7i1zW4pzMW3XCE23DrapX8bXwMm-UEiQAe7i8tiuE=.2f124b75-523c-420d-b7b6-ba26261d89c9@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
 <Pz7i1zW4pzMW3XCE23DrapX8bXwMm-UEiQAe7i8tiuE=.2f124b75-523c-420d-b7b6-ba26261d89c9@github.com>
Message-ID: <Ue9CVRUrNN_zeJ8GY2Jx_ddOoJzH1VH0iDbHAu5F0VE=.5defbfdc-a33c-4c77-8f8f-0cd8975bcb98@github.com>

On Tue, 15 Jul 2025 17:41:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Maybe also update the description in this PR and the ticket?

I added a note to the JBS Description.

@prsadhuk Can you update the PR description when you fix the title?

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3074693759

From angorya at openjdk.org  Tue Jul 15 18:01:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 18:01:56 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
Message-ID: <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>

On Mon, 14 Jul 2025 19:58:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
>> 
>> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
>> 
>> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
>> 
>> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
>> 
>> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
>> 
>> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback related to code consistency and clarity.

On a surface, this looks like a rather intrusive change (I can't comment on the merits of this PR yet).

Would it make sense to attempt fixing event consumption bugs in the ComboBox and Spinner first?
And perhaps also look at fixing the dispatching of consumed events such as JDK-8303209 or JDK-8229467 (the latter has been by @mstr2 , I think prematurely)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3074723995

From mfox at openjdk.org  Tue Jul 15 19:13:48 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 15 Jul 2025 19:13:48 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v4]
In-Reply-To: <S7voer3VIizJVIakknVr_Bq1y89Y5LbBf8kmxa57ZOI=.42e9dab9-0f7e-4dd5-8c64-b785f68c6b2d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <YQEk6iIiEkKRuuHHd2faHrd9fytscEPk8wkToItAfGo=.84a87f26-2df5-4399-8a5c-627932c15617@github.com>
 <vV30OHb08gx26owOe_1_czcHd680PfVmlC3k-P3ycmQ=.51d079c1-8175-4ef9-8d6e-4d3c00622bbd@github.com>
 <S7voer3VIizJVIakknVr_Bq1y89Y5LbBf8kmxa57ZOI=.42e9dab9-0f7e-4dd5-8c64-b785f68c6b2d@github.com>
Message-ID: <1_q_L27-Hysib7Tn96flA3OpO0bGYTwDOiRaKOqzSWw=.255e8e3d-edf3-4cba-8d1f-9ecc6c202bc8@github.com>

On Tue, 15 Jul 2025 05:35:44 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.h line 78:
>> 
>>> 76:     id<MTLRenderCommandEncoder> phongEncoder;
>>> 77:     id<MTLRenderCommandEncoder> lastPhongEncoder;
>>> 78:     MetalShader* currentShader;
>> 
>> Might be my obj-C lack-of-knowledge - why some objects here use pointers, while others use `id<>`?
>
> They are little similar with `*` offering more type safety. But in our case we have used `id<>` for metal library objects and `*` instances of interfaces from our implementation.

Also for most Metal objects you only get a protocol name, not a class name. id<protocol\> is the way to specify a pointer to such an object. I'm not sure why Apple used this idiom throughout the Metal API.

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

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

From philip.race at oracle.com  Tue Jul 15 19:15:10 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 15 Jul 2025 12:15:10 -0700
Subject: For fonts with localized names, JavaFX cannot find the font by
 the default name on Windows
In-Reply-To: <CAJL5A3=EC5T=P4d-s1bV8v1q-KbOd-D7C_MO+7FyNUw+ow1N+g@mail.gmail.com>
References: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
 <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
 <CAJL5A3=EC5T=P4d-s1bV8v1q-KbOd-D7C_MO+7FyNUw+ow1N+g@mail.gmail.com>
Message-ID: <0a323fcb-493c-453a-b8fc-f3cf2f6a86a3@oracle.com>

I can't be sure - without inspecting the font and debugging the code - 
but this looks
like in the first case you get the ID=16 typographic font family 
("JetBrains Mono") and
in the other case you get the ID=1 font family ("JetBrains Mono Medium").
Without debugging I can't explain why there's this apparent inconsistency.

ID=1 is the traditional 4 member font family with 
regular/bold/italic/bold italic

The typographic (some times called extended) family supports weight and 
sometimes width
and these days they may even be combined into a single font via font 
variations.

There may be a bug here (can't be sure without investigating) and there 
also may be a need
for API which works with the typographic family.


 >Besides these issues, I also get tired of the subtle differences in 
behavior between different platforms.
 >Can we bridge the differences in how JavaFX handles font family names 
on different platforms?

Some of it may come from the platform APIs being different.
Can you give me additional examples ?

-phil.

On 7/15/25 7:21 AM, Glavo wrote:
> Hi Philip,
>
> Thanks for your reply.
>
> > (1) fixing this for DW wouldn't help Linux or Mac so there'd need to 
> be separate implementations if they also don't do it automatically
>
> I also tested on Linux and macOS. I think this problem does not exist 
> on these two platforms.
> JavaFX uses the English font family names everywhere on both 
> platforms, rather than the localized names, so this problem does not 
> occur.
>
> However, I encountered another annoying behavior on macOS:
>
>     jshell> Font.getFamilies().stream().filter(it ->
>     it.contains("JetBrains Mono")).toList()
>     $2 ==> [JetBrains Mono, JetBrains Mono NL]
>
>     jshell> Font.font("JetBrains Mono")
>     $3 ==> Font[name=JetBrains Mono Medium, family=JetBrains Mono
>     Medium, style=Regular, size=13.0]
>
>     jshell> $3.getFamily()
>     $4 ==> "JetBrains Mono Medium"
>
>     jshell> Font.font("JetBrains Mono Medium")
>     $5 ==> Font[name=System Regular, family=System, style=Regular,
>     size=13.0]
>
>
> As you can see, multiple weights of a font on macOS are unified into 
> the same font family.
> We can find a Font by this font family name, but the family name 
> returned by Font:getFamily() includes the weight,
> and we cannot find the font based on the returned name.
> This problem does not occur on Linux and Windows, because those 
> platforms do not unify fonts into a single family.
>
> Besides these issues, I also get tired of the subtle differences in 
> behavior between different platforms.
> Can we bridge the differences in how JavaFX handles font family names 
> on different platforms?
>
> Glavo
>
> On Tue, Jul 15, 2025 at 3:50?AM Philip Race <philip.race at oracle.com> 
> wrote:
>
>     Font.font will, on Windows, use
>     IDWriteFontCollection::FindFamilyName(..)
>     The docs for that appear to be silent on whether the matching
>     process will check all localized names,
>     but it sounds like it must not.? I don't see an alternative look
>     up API, such as one that accepts a locale arg.
>
>     https://learn.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollection
>
>
>     It seems like the app (which in this case means the FX
>     implementation) will have to do this itself which is going to be
>     tedious.
>
>     We would need to compare with every localized name of every font
>     on the system looking for a match.
>
>     And one annoying aspect of this is that until you've done that
>     exhaustive search you don't
>     know if the name the application supplied is present at all on the
>     system.
>
>     How would you know that someone mis-spelled Arial as Ariel and not
>     that Ariel is the German localized name for Arial ?
>
>     So failed lookups will be slow.
>
>     In Java 2D we already do this but I'd have hoped DW used by FX was
>     better than this than GDI used by 2D.
>
>     Also note that
>     (1) fixing this for DW wouldn't help Linux or Mac so there'd need
>     to be separate implementations if they also don't do it automatically
>     (2) There isn't any FX API which lets you enumerate or access
>     localized names, so as you note, that also is an issue.
>     Although I'm actually a little surprised FX finds ?? but reports
>     YouYuan. I would have thought it would be consistent.
>
>     I'm also a little surprised that it has taken this long for anyone
>     to even implicitly ask for FX to support localized font names.
>     Java2D has had this support for a very long time.
>
>     -phil.
>
>     On 7/12/25 4:18 AM, Glavo wrote:
>>     Hi,
>>
>>     We recently noticed a problem: For fonts with localized names,
>>     Font.font(String) can only find the font based on the localized
>>     name in the current locale.
>>
>>     For example, the Chinese version of Windows comes with a font
>>     called "YouYuan", and its Chinese name is "??".
>>     When the system language is Chinese, JavaFX has the following
>>     behaviors:
>>
>>         jshell> Font.font("YouYuan")
>>         $2 ==> Font[name=System Regular, family=System,
>>         style=Regular, size=13.333333015441895]
>>
>>         jshell> Font.font("??")
>>         $3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
>>         size=13.333333015441895]
>>
>>         jshell> $3.getFamily()
>>         $4 ==> "YouYuan"
>>
>>
>>     As you can see, we cannot find the font based on the English
>>     name, we can only use the Chinese name.
>>     But Font::getName() returns the English name, so we can't get the
>>     Chinese name from the Font.
>>     This makes it impossible to generate a style sheet based on a
>>     Font?object, because
>>
>>         "-fx-font-family: \"%s\";".formatted(font.getFamily())
>>
>>     will not work with these fonts.
>>
>>     The only workaround I can think of is to generate a mapping table
>>     from English names to Chinese names like this:
>>
>>
>>         Font.getFamilies().stream().collect(Collectors.toMap(it ->
>>         Font.font(it).getFamily(), Function.identity()))
>>
>>
>>     But this seems like a lot of overhead :(
>>
>>     So, I want JavaFX to provide the following features:
>>
>>      1. Regardless of the current system language, Font.font(String)
>>         should be able to find the font by its English name;
>>      2. Provide a new method Font::getLocalizedFamily() to get the
>>         localized name of the font.
>>
>>     Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250715/0bfddbba/attachment-0001.htm>

From mfox at openjdk.org  Tue Jul 15 20:23:47 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 15 Jul 2025 20:23:47 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
 <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>
Message-ID: <iGqtzAcIqDdkPLkPRzf0T2FJjglzI8sbrdpxI8tkzKg=.5cb01bc5-fa07-4174-92e1-6dffa51e26d2@github.com>

On Tue, 15 Jul 2025 17:59:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Would it make sense to attempt fixing event consumption bugs in the ComboBox and Spinner first?

When a Spinner is the focus owner it receives all KeyEvents but KeyEvents still need to be delivered to its editor. There's no good way of doing that now short of consuming the original event and firing a copy. To fix this we would have to introduce new API's (like some form of PR #1632).

> And perhaps also look at fixing the dispatching of consumed events such as JDK-8303209 or JDK-8229467 (the latter has been by @mstr2 , I think prematurely)?

Those bugs have to do with how consumption is signaled which isn't relevant. All that's relevant is that the original event is being consumed, not how we find out about it.

JavaFX handles events using dispatch chains and currently the system menu doesn't participate in that machinery. This causes it to work very differently from a standard MenuBar (which places its accelerators in the Scene which is in the chain). One could argue that it's a bug that the system menu doesn't respond to KeyEvents the way a standard MenuBar would.

Another way to look at it: do we want to outlaw what ComboBox and Spinner are doing? It's not illegal to create a KeyEvent and fire it at a control. It's not illegal to consume a KeyEvent that originated in Glass. Things only fail when the system menu is in effect and, again, only because it doesn't participate in dispatch.

Because I agree with you, this PR is intrusive. I'm not fan and I wrote it. I think the system menu needs to participate in event dispatch and I haven't found any clean, tidy way of doing that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3075427863

From angorya at openjdk.org  Tue Jul 15 21:16:46 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 21:16:46 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
Message-ID: <DeG77SVK3MyKwou8_aYI4GJx47xIp9OXaXm_gNqH-ps=.a12cb398-0d6a-4cc8-86d6-894f0e25f3af@github.com>

On Mon, 14 Jul 2025 19:58:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
>> 
>> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
>> 
>> One could argue that a ComboBox or Spinner shouldn?t consume all key events but one could also argue that the system menu shouldn?t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
>> 
>> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it?s the last dispatcher encountered while bubbling.
>> 
>> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn?t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
>> 
>> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple?s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it?s done.)
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback related to code consistency and clarity.

> To fix this we would have to introduce new API's (like some form of PR https://github.com/openjdk/jfx/pull/1632).

I am not a fan of #1632, I think it's an attempt to band-aid over a fundamental design issue, but this is a different topic altogether.

Why would a Spinner or ComboBox consume the key events that it is not supposed to?  Ok, let's assume the outer control (Spinner or ComboBox) gets the event and fires a copy to the inner control (TextField).  This is perfectly legal, but now it must either consume the event if the secondary event is consumed.  More importantly, it **should not consume** the event if the secondary event is not consumed, isn't that the issue?

So it it a responsibility of the entity that creates the secondary event to either consume the original event or let it go, or am I mistaken?

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3075683925

From kcr at openjdk.org  Tue Jul 15 22:24:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 15 Jul 2025 22:24:47 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v10]
In-Reply-To: <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
Message-ID: <SER5WVIqIc4tVayjR9roR6VJPGc_4x5o05TFe2bvOMI=.7bae2e00-51f5-472c-b6f1-bc22d1f3f8a0@github.com>

On Tue, 15 Jul 2025 17:32:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - ... and 57 more: https://git.openjdk.org/jfx/compare/1a2a50b5...5252633b

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3022516626

From angorya at openjdk.org  Tue Jul 15 23:51:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 15 Jul 2025 23:51:47 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v10]
In-Reply-To: <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
Message-ID: <t7Ht4iexN0_zBuT8j0WIyLUOi_5Ugdj3QWMuv6ofPw8=.b76b73bf-7246-485f-b94f-c82dfc0048ec@github.com>

On Tue, 15 Jul 2025 17:32:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - ... and 57 more: https://git.openjdk.org/jfx/compare/1a2a50b5...5252633b

@arapte could you please take a look at this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-3076093968

From zjx001202 at gmail.com  Wed Jul 16 01:08:24 2025
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 16 Jul 2025 09:08:24 +0800
Subject: For fonts with localized names, JavaFX cannot find the font by
 the default name on Windows
In-Reply-To: <0a323fcb-493c-453a-b8fc-f3cf2f6a86a3@oracle.com>
References: <CAJL5A3mpGTi02Oppab3ZjbHx4Feuq8kjuNgJNeYWD-TyiamUFA@mail.gmail.com>
 <84dfd2ee-52f2-4bf2-adec-1d4f45850a1f@oracle.com>
 <CAJL5A3=EC5T=P4d-s1bV8v1q-KbOd-D7C_MO+7FyNUw+ow1N+g@mail.gmail.com>
 <0a323fcb-493c-453a-b8fc-f3cf2f6a86a3@oracle.com>
Message-ID: <CAJL5A3=Zw_xx5ijM9vD5_0tjpuB6NnbccUY5_Mawg+NnPkKzCw@mail.gmail.com>

Hi Philip,

I did some more testing and noticed an even more serious problem on macOS:
I couldn?t seem to select the font weight.

jshell> Font.getFontNames("JetBrains Mono").forEach(System.out::println)
JetBrains Mono ExtraLight Italic
JetBrains Mono ExtraBold Italic
JetBrains Mono Medium
JetBrains Mono Thin Italic
JetBrains Mono ExtraBold
JetBrains Mono Light
JetBrains Mono SemiBold
JetBrains Mono Medium Italic
JetBrains Mono Bold Italic
JetBrains Mono SemiBold Italic
JetBrains Mono Bold
JetBrains Mono Regular
JetBrains Mono Light Italic
JetBrains Mono Italic
JetBrains Mono ExtraLight
JetBrains Mono Thin

jshell> Font.font("JetBrains Mono Thin")
$3 ==> Font[name=System Regular, family=System, style=Regular, size=13.0]

jshell> Font.font("JetBrains Mono", FontWeight.THIN, 13)
$4 ==> Font[name=JetBrains Mono Medium, family=JetBrains Mono Medium,
style=Regular, size=13.0]

jshell> Font.font("JetBrains Mono", FontWeight.THIN, FontPosture.REGULAR,
13)
$5 ==> Font[name=JetBrains Mono Medium, family=JetBrains Mono Medium,
style=Regular, size=13.0]

jshell> Font.font("JetBrains Mono", FontWeight.THIN, FontPosture.ITALIC, 13)
$6 ==> Font[name=JetBrains Mono ExtraLight Italic, family=JetBrains Mono
ExtraLight, style=Italic, size=13.0]


Font.font(...) is working in a way that is hard for me to understand :(

Some of it may come from the platform APIs being different.
> Can you give me additional examples ?


 I think the most serious inconsistency is: what do we mean when we talk
about "the family of the font"?

   - On Windows, it usually means the localized name of the font family
   name (nameID=1);
   - On Linux,  it usually means the non-localized font family name
   (nameID=1);
   - On macOS,  it usually means the non-localized typographical family
   name (nameID=16).


I think the behavior on macOS is relatively correct - provided that the
problems I mentioned earlier are resolved.
Using font family names (nameID=1) means it is difficult to select variants.
If we want to get JetBrains Mono Bold on Windows, we need to use
Font.font("JetBrains
Mono", FontWeight.BOLD, 13),
but to get JetBrains Mono ExtraBold, we need to use Font.font("JetBrains
Mono ExtraBold", FontWeight.NORMAL, 13).

Honestly, I feel like the entire Font API is poorly documented, extremely
confusing, and lacks useful methods.
If I don't test it on every platform, I have no idea how it will work. I
think it really needs a huge refactor.

Glavo

On Wed, Jul 16, 2025 at 3:20?AM Philip Race <philip.race at oracle.com> wrote:

> I can't be sure - without inspecting the font and debugging the code - but
> this looks
> like in the first case you get the ID=16 typographic font family
> ("JetBrains Mono") and
> in the other case you get the ID=1 font family ("JetBrains Mono Medium").
> Without debugging I can't explain why there's this apparent inconsistency.
>
> ID=1 is the traditional 4 member font family with regular/bold/italic/bold
> italic
>
> The typographic (some times called extended) family supports weight and
> sometimes width
> and these days they may even be combined into a single font via font
> variations.
>
> There may be a bug here (can't be sure without investigating) and there
> also may be a need
> for API which works with the typographic family.
>
>
> >Besides these issues, I also get tired of the subtle differences in
> behavior between different platforms.
> >Can we bridge the differences in how JavaFX handles font family names on
> different platforms?
>
> Some of it may come from the platform APIs being different.
> Can you give me additional examples ?
>
> -phil.
>
> On 7/15/25 7:21 AM, Glavo wrote:
>
> Hi Philip,
>
> Thanks for your reply.
>
> > (1) fixing this for DW wouldn't help Linux or Mac so there'd need to be
> separate implementations if they also don't do it automatically
>
> I also tested on Linux and macOS. I think this problem does not exist on
> these two platforms.
> JavaFX uses the English font family names everywhere on both platforms,
> rather than the localized names, so this problem does not occur.
>
> However, I encountered another annoying behavior on macOS:
>
> jshell> Font.getFamilies().stream().filter(it -> it.contains("JetBrains
> Mono")).toList()
> $2 ==> [JetBrains Mono, JetBrains Mono NL]
>
> jshell> Font.font("JetBrains Mono")
> $3 ==> Font[name=JetBrains Mono Medium, family=JetBrains Mono Medium,
> style=Regular, size=13.0]
>
> jshell> $3.getFamily()
> $4 ==> "JetBrains Mono Medium"
>
> jshell> Font.font("JetBrains Mono Medium")
> $5 ==> Font[name=System Regular, family=System, style=Regular, size=13.0]
>
>
> As you can see, multiple weights of a font on macOS are unified into the
> same font family.
> We can find a Font by this font family name, but the family name returned
> by Font:getFamily() includes the weight,
> and we cannot find the font based on the returned name.
> This problem does not occur on Linux and Windows, because those platforms
> do not unify fonts into a single family.
>
> Besides these issues, I also get tired of the subtle differences in
> behavior between different platforms.
> Can we bridge the differences in how JavaFX handles font family names on
> different platforms?
>
> Glavo
>
> On Tue, Jul 15, 2025 at 3:50?AM Philip Race <philip.race at oracle.com>
> wrote:
>
>> Font.font will, on Windows, use IDWriteFontCollection::FindFamilyName(..)
>> The docs for that appear to be silent on whether the matching process
>> will check all localized names,
>> but it sounds like it must not.  I don't see an alternative look up API,
>> such as one that accepts a locale arg.
>>
>>
>> https://learn.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollection
>>
>> It seems like the app (which in this case means the FX implementation)
>> will have to do this itself which is going to be tedious.
>>
>> We would need to compare with every localized name of every font on the
>> system looking for a match.
>>
>> And one annoying aspect of this is that until you've done that exhaustive
>> search you don't
>> know if the name the application supplied is present at all on the system.
>>
>> How would you know that someone mis-spelled Arial as Ariel and not that
>> Ariel is the German localized name for Arial ?
>>
>> So failed lookups will be slow.
>>
>> In Java 2D we already do this but I'd have hoped DW used by FX was better
>> than this than GDI used by 2D.
>> Also note that
>> (1) fixing this for DW wouldn't help Linux or Mac so there'd need to be
>> separate implementations if they also don't do it automatically
>> (2) There isn't any FX API which lets you enumerate or access localized
>> names, so as you note, that also is an issue.
>> Although I'm actually a little surprised FX finds ?? but reports YouYuan.
>> I would have thought it would be consistent.
>>
>> I'm also a little surprised that it has taken this long for anyone to
>> even implicitly ask for FX to support localized font names.
>> Java2D has had this support for a very long time.
>>
>> -phil.
>>
>> On 7/12/25 4:18 AM, Glavo wrote:
>>
>> Hi,
>>
>> We recently noticed a problem: For fonts with localized names,
>> Font.font(String) can only find the font based on the localized name in
>> the current locale.
>>
>> For example, the Chinese version of Windows comes with a font called
>> "YouYuan", and its Chinese name is "??".
>> When the system language is Chinese, JavaFX has the following behaviors:
>>
>> jshell> Font.font("YouYuan")
>> $2 ==> Font[name=System Regular, family=System, style=Regular,
>> size=13.333333015441895]
>>
>> jshell> Font.font("??")
>> $3 ==> Font[name=YouYuan, family=YouYuan, style=Regular,
>> size=13.333333015441895]
>>
>> jshell> $3.getFamily()
>> $4 ==> "YouYuan"
>>
>>
>> As you can see, we cannot find the font based on the English name, we can
>> only use the Chinese name.
>> But Font::getName() returns the English name, so we can't get the
>> Chinese name from the Font.
>> This makes it impossible to generate a style sheet based on a Font
>>  object, because
>>
>> "-fx-font-family: \"%s\";".formatted(font.getFamily())
>>
>> will not work with these fonts.
>>
>> The only workaround I can think of is to generate a mapping table from
>> English names to Chinese names like this:
>>
>>
>> Font.getFamilies().stream().collect(Collectors.toMap(it ->
>> Font.font(it).getFamily(), Function.identity()))
>>
>>
>> But this seems like a lot of overhead :(
>>
>> So, I want JavaFX to provide the following features:
>>
>>    1. Regardless of the current system language, Font.font(String)
>>    should be able to find the font by its English name;
>>    2. Provide a new method Font::getLocalizedFamily() to get the
>>    localized name of the font.
>>
>> Glavo
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250716/f797cb4b/attachment-0001.htm>

From jhendrikx at openjdk.org  Wed Jul 16 01:43:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Jul 2025 01:43:48 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <iGqtzAcIqDdkPLkPRzf0T2FJjglzI8sbrdpxI8tkzKg=.5cb01bc5-fa07-4174-92e1-6dffa51e26d2@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
 <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>
 <iGqtzAcIqDdkPLkPRzf0T2FJjglzI8sbrdpxI8tkzKg=.5cb01bc5-fa07-4174-92e1-6dffa51e26d2@github.com>
Message-ID: <JYFo_ilHpkdtkYOBAjiwpes_uFdZRu7QRDrb0w-n34U=.dd1ce684-8af8-4b7f-a6ea-93a03f069fb5@github.com>

On Tue, 15 Jul 2025 20:21:15 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Another way to look at it: do we want to outlaw what ComboBox and Spinner are doing? It's not illegal to create a KeyEvent and fire it at a control. It's not illegal to consume a KeyEvent that originated in Glass. Things only fail when the system menu is in effect and, again, only because it doesn't participate in dispatch.

Good point, it's not and shouldn't be strictly illegal.  I only commented earlier that I think they shouldn't be doing it but currently have little recourse.

It should be perfectly fine to create your own KeyEvent or MouseEvent, and IMHO such events should be able to do anything that system created events can do, including firing system menus.  That ship may have sailed though as I think there's already data in these events that users can't create or replicate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3076443962

From jhendrikx at openjdk.org  Wed Jul 16 01:58:48 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Jul 2025 01:58:48 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <6MN7eVg2rBzq_H_AORD1oE1cDI5qNitk7PWwq57kwAE=.fe893750-a6c1-4b92-a0ad-26d01878b4e8@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
 <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
 <6MN7eVg2rBzq_H_AORD1oE1cDI5qNitk7PWwq57kwAE=.fe893750-a6c1-4b92-a0ad-26d01878b4e8@github.com>
Message-ID: <HkNPrzTAkDxJJJ8eeCzeBbg0IGgu1OPbcyhZnutve9w=.df118d6e-567e-4e59-8393-060f3641d835@github.com>

On Tue, 15 Jul 2025 11:32:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> > The first question is: Does this have any use case beyond testing?
> 
> Good question, and the answer is "Yes, absolutely". One of the main drivers for this was a project where PDF prints need to be generated server-side, starting from `Node.snapShot(... WritableImage)`.

@johanvos 

Did you happen to see my proposal to use the software renderer to provide a Canvas#GraphicsContext like API for writable images?  Snapshot is a nice feature, but it feels like a rather roundabout way to first use the GPU to draw things, then copy it back to main memory for pixel manipulation or say PDF creation...

See here: https://www.mail-archive.com/openjfx-dev at openjdk.org/msg20618.html

I'm curious what you think of the proposal (and I'm curious if the headless platform would need to support it or interfere with it :))

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3076464229

From jhendrikx at openjdk.org  Wed Jul 16 02:36:55 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 16 Jul 2025 02:36:55 GMT
Subject: RFR: 8354795: DialogPane show details button wipes out base style
 class "hyperlink"
In-Reply-To: <UsxXrr7L4kLiOOjucydtLCk7HX2U3HcYeAR5SL9oWJc=.042cb4ee-4c32-45f8-b3bc-5eb91f42ac29@github.com>
References: <yjxk937tqyc1rNc3yOrWRC5WuVZ02z7UJD1lVGmvrF0=.97609a1d-2e38-49fb-8278-9995482fa020@github.com>
 <UsxXrr7L4kLiOOjucydtLCk7HX2U3HcYeAR5SL9oWJc=.042cb4ee-4c32-45f8-b3bc-5eb91f42ac29@github.com>
Message-ID: <q_-TS3EutJBE7YJk69RuQAfzlzLqefmAlP5VubFC05w=.072d9b69-21d2-4442-b4be-2bfded065967@github.com>

On Sat, 14 Jun 2025 11:52:36 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> I think wiping default style classes should not be done.
> 
> Maybe somewhat related and only my understanding: There are quite some places in JavaFX Controls where e.g. a `StackPane` is used to somewhat mimic a `Control` (often a `Button`).

I think that when you use an inheritance based system for controls, that you should always pick a starting point that does not yet have any unwanted behaviors or styles, instead of going for a move evolved starting point and then removing what you don't want.  The latter is harder as future changes may add new behaviors that make sense for the control you branched off from but not for your use case.

So if you don't want a Button that's clearly delineated for the user, that can have short cuts, can be hovered over, can be armed, disabled, highlighted, and participate as default or cancel action, then Button is not for you.  So using Button to create a clickable Tab is not a good idea.  The safest choice will be one of the container types as these don't have behaviors, nor do they have styles and skins.
 
> Example: The `TitleRegion` is a `StackPane`, but behaves like a `Button`. This may was done to avoid focus issues, but I can also imagine that this was done to not wipe default style classes / break styling. In the example the `title` style class is set there (If it would be a `Button`, it would be wiped as well there, which might be expected or not for some developers).

I think it was done to not have to de-evolve Button to make it into a Tab.  Tab could be its own control, with its own styles and skins, but I think it is so integrated that it would rarely serve a purpose if it was available separately from TabPane.
 
> So to come back, this looks to be the only place where this is done, right? I agree that is should keep the `hyperlink` style class and not wipe them. Or something else must be used, which is probably not feasable.

I didn't find any other instances where this is done.  If a Hyperlink is not what is desired here, then I think it is a bad idea to use Hyperlink and try to second guess what its skin is doing in combination with the default style.  Removing the hyperlink style means you'd need to style it yourself, which requires knowledge of the skin.  So either:

- It should not be a Hyperlink but something new, then create a new Control, or start from a Container type or any other type where you don't need to "remove" functionality or styling
- It should be a Hyperlink, but just look a bit different, then add additional styles or replace its skin

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

PR Comment: https://git.openjdk.org/jfx/pull/1779#issuecomment-3076515117

From mstrauss at openjdk.org  Wed Jul 16 02:49:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Jul 2025 02:49:46 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <JYFo_ilHpkdtkYOBAjiwpes_uFdZRu7QRDrb0w-n34U=.dd1ce684-8af8-4b7f-a6ea-93a03f069fb5@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
 <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>
 <iGqtzAcIqDdkPLkPRzf0T2FJjglzI8sbrdpxI8tkzKg=.5cb01bc5-fa07-4174-92e1-6dffa51e26d2@github.com>
 <JYFo_ilHpkdtkYOBAjiwpes_uFdZRu7QRDrb0w-n34U=.dd1ce684-8af8-4b7f-a6ea-93a03f069fb5@github.com>
Message-ID: <ea8uqtRR0BbecQ9UjYWemKVpq4XAqU3Q68-Lx3jFmqI=.7e5ce14c-ae1b-4afa-956c-d4b32c477a81@github.com>

On Wed, 16 Jul 2025 01:40:54 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Another way to look at it: do we want to outlaw what ComboBox and Spinner are doing? It's not illegal to create a KeyEvent and fire it at a control. It's not illegal to consume a KeyEvent that originated in Glass. Things only fail when the system menu is in effect and, again, only because it doesn't participate in dispatch.

A control can't just fire an event "to the inner control" using the usual `Event.fireEvent()`. These events are routed through the scene graph starting from the root, so an outside observer will see two key events, not one. There's no way of knowing that the two events are not actually two separate user inputs.

I don't know what "outlaw" means in this case. Throw an exception when user code tries to fire input events? No, probably not. But in my view we should consider it as a control bug, not as a legitimate use of the event system.

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3076532022

From psadhukhan at openjdk.org  Wed Jul 16 03:33:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 16 Jul 2025 03:33:46 GMT
Subject: RFR: 8141391: Manual JFXPanel DnD test doesn't work [v3]
In-Reply-To: <Ue9CVRUrNN_zeJ8GY2Jx_ddOoJzH1VH0iDbHAu5F0VE=.5defbfdc-a33c-4c77-8f8f-0cd8975bcb98@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
 <Pz7i1zW4pzMW3XCE23DrapX8bXwMm-UEiQAe7i8tiuE=.2f124b75-523c-420d-b7b6-ba26261d89c9@github.com>
 <Ue9CVRUrNN_zeJ8GY2Jx_ddOoJzH1VH0iDbHAu5F0VE=.5defbfdc-a33c-4c77-8f8f-0cd8975bcb98@github.com>
Message-ID: <PmTxLbDDWA_Ko6csiEWt3up3CzOhTu2vVeaNqDXpM9s=.f2a7f2fb-b747-4221-bfee-45e3d34cf9d1@github.com>

On Tue, 15 Jul 2025 17:53:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > Maybe also update the description in this PR and the ticket?
> 
> I added a note to the JBS Description.
> 
> @prsadhuk Can you update the PR description when you fix the title?

@kevinrushforth  Do you want me to overwrite the entire description and write it's a problem with the test?
I guess when I wrote that description I believed it was a product issue and subsequent discussion revealed it was a test issue....I thought so because when I added those tests in 2019 in [JDK-8211248](https://bugs.openjdk.org/browse/JDK-8211248) it was reviewed and no such case was highlighted that test was wrong at that time..
If I overwrite the entire description, it will suggest it was known from start it was a test issue..so I added as an endnote that it was found to be a test issue...is it ok?

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3076592702

From arapte at openjdk.org  Wed Jul 16 05:39:44 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 16 Jul 2025 05:39:44 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <RmUFUPBQzyb-KMDkWshP8KVVCjle6BWbisXDb9eT2yw=.69a53fd0-692b-4f7c-918f-aafbcd8046c7@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <RmUFUPBQzyb-KMDkWshP8KVVCjle6BWbisXDb9eT2yw=.69a53fd0-692b-4f7c-918f-aafbcd8046c7@github.com>
Message-ID: <A5LHJIbSmKL-dGCLPxOFLAgz7UVKtMhgIOwZmjFXZu8=.69116e72-cef3-47f2-8b3d-fdcc55bc8b26@github.com>

On Thu, 10 Jul 2025 22:51:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Encountered a weird issue with the WebView - not sure if related. Had to go off VPN to load https://yahoo.com, then logged back into VPN

I am unable to reproduce this issue, neither with stand alone HelloWebView nor with monkey tester.

WebView does require the proxy to be set when using VPN. Following command would load the when using VPN.

`java -Dhttps.proxyHost=<proxy-url> -Dhttps.proxyPort=<XX> -Dhttp.proxyHost=<proxy-url> -Dhttp.proxyPort=<XX> -jar MonkeyTester.jar`

Metal change should not cause such issue, this seems WebView specific, I shall try to reproduce and may be file a WebView issue.

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

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

From mstrauss at openjdk.org  Wed Jul 16 05:56:38 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 16 Jul 2025 05:56:38 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v3]
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: <vT73wXf7AmG2-p8tio90-BUHIbwcH9s9GbZOYZA0aS8=.a007b2ab-e044-47e6-afb6-d5262f537707@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 incrementally with one additional commit since the last revision:

  documentation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1844/files
  - new: https://git.openjdk.org/jfx/pull/1844/files/cc0d44c1..8c93b359

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

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 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 lkostyra at openjdk.org  Wed Jul 16 08:55:58 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 16 Jul 2025 08:55:58 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <6D8i7Bge2K4-tc9bhaxMos4bmTE3JzGocdvLfsfagE4=.dfa9ad7a-7b90-4c1f-897f-724620bbf0ad@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
 <c0CLVmt2ZliKLNwuX27Sk_r2Fvmay96Q_MuuX4MM9EM=.80bdea1f-8077-4862-b2a4-6da17227184b@github.com>
 <ITZ5M-8pYQFqu5T4jbd75dCw3QkX2Ra3T42SLEYod_k=.063c4e4a-bfb0-4686-b57b-ddd5ce906b7f@github.com>
 <6D8i7Bge2K4-tc9bhaxMos4bmTE3JzGocdvLfsfagE4=.dfa9ad7a-7b90-4c1f-897f-724620bbf0ad@github.com>
Message-ID: <kesgeUOW3KXTBvgkNkVcgL1UileD5VA3zzracDCLYQA=.aad0da25-226a-4ba9-804b-fc13b81ab4aa@github.com>

On Tue, 15 Jul 2025 17:43:33 GMT, Martin Fox <mfox at openjdk.org> wrote:

> I'm sure I ran MenuDoubleShortcutTest on Windows before submitting it.

This also started being a problem at some later point in time; on my machine tests used to do a full run with no failures with the Gradle daemon being enabled. I can't unfortunately pinpoint when the problems started happening, I only found out after the fact that `SetForegroundWindow()` enforces conditions mentioned in the PR description.

AFAIK `--no-daemon` consistently helps (I use MinGW on my Windows box). @kevinrushforth also mentioned offline that he disables the Gradle daemon in his machine-wide `gradle.properties` so he never encountered these problems.

I also submitted a (for now draft) PR for the `isFocused()` API fix - https://github.com/openjdk/jfx/pull/1849. It is independent from this test but the test was helpful with checking the behavior while writing the test. Feedback is welcome!

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3077604344

From kcr at openjdk.org  Wed Jul 16 13:03:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Jul 2025 13:03:44 GMT
Subject: RFR: 8141391: Manual JFXPanel DnD test doesn't work [v3]
In-Reply-To: <PmTxLbDDWA_Ko6csiEWt3up3CzOhTu2vVeaNqDXpM9s=.f2a7f2fb-b747-4221-bfee-45e3d34cf9d1@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
 <Pz7i1zW4pzMW3XCE23DrapX8bXwMm-UEiQAe7i8tiuE=.2f124b75-523c-420d-b7b6-ba26261d89c9@github.com>
 <Ue9CVRUrNN_zeJ8GY2Jx_ddOoJzH1VH0iDbHAu5F0VE=.5defbfdc-a33c-4c77-8f8f-0cd8975bcb98@github.com>
 <PmTxLbDDWA_Ko6csiEWt3up3CzOhTu2vVeaNqDXpM9s=.f2a7f2fb-b747-4221-bfee-45e3d34cf9d1@github.com>
Message-ID: <CA3u5p1QVlTbmC1bhHudjp09vkJY8tOBKKxrM_BLe-I=.881a86e3-b7aa-46aa-8129-6d0b491e457a@github.com>

On Wed, 16 Jul 2025 03:31:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Maybe also update the description in this PR and the ticket?
>> 
>> I added a note to the JBS Description.
>> 
>> @prsadhuk Can you update the PR description when you fix the title?
>
>> > Maybe also update the description in this PR and the ticket?
>> 
>> I added a note to the JBS Description.
>> 
>> @prsadhuk Can you update the PR description when you fix the title?
> 
> @kevinrushforth  Do you want me to overwrite the entire description and write it's a problem with the test?
> I guess when I wrote that description I believed it was a product issue and subsequent discussion revealed it was a test issue....I thought so because when I added those tests in 2019 in [JDK-8211248](https://bugs.openjdk.org/browse/JDK-8211248) it was reviewed and no such case was highlighted that test was wrong at that time..
> If I overwrite the entire description, it will suggest it was known from start it was a test issue which is not correct..so I added as an endnote that it was found to be a test issue...is it ok?

@prsadhuk What you did with the description seems OK.

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

PR Comment: https://git.openjdk.org/jfx/pull/1843#issuecomment-3078478435

From kcr at openjdk.org  Wed Jul 16 13:46:48 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Jul 2025 13:46:48 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v6]
In-Reply-To: <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <UdPgG9O_ZpQYN3qVszFd-HpJlmfOHoVZeB_wij_N8zU=.103663ee-0bdd-4f05-a2f0-3cb7372f5ad3@github.com>
Message-ID: <wgTaTjQZintmdJ8wVNS3u7RFRnAdPC-G8ZJMZ6Jb4dE=.b22e18c2-bb8e-4749-be2d-4807a0b99ab6@github.com>

On Fri, 4 Jul 2025 06:59:24 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Parameterize StageFocusTest
>    
>    This is to check if Stage showing works also for Stages other than the
>    primary Stage provided by Application.start()
>  - Review fixes; revert using VisualTestBase

Yes, I always disable the gradle daemon in my `$HOME/.gradle/gradle.properties`. Our CI builds and test runs also do this (our Jenkins scripts pass `--no-daemon` to all invocations of gradle). We've had way too many problems over the years, and this is just another example.

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3078701227

From angorya at openjdk.org  Wed Jul 16 14:25:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Jul 2025 14:25:47 GMT
Subject: RFR: 8141391: Manual JFXPanel DnD test doesn't work [v3]
In-Reply-To: <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
 <I7pbkA7FPhVrEXRYkIc1Wao1bB0gtOaIFT4sbHAPSNY=.ec07a77c-4981-4c81-89a7-e928ac490911@github.com>
Message-ID: <wi-7WNHGHeKkvpHKFdtJ2NHnyIpTgOW2JteyM2o9C5Y=.f159e2b3-e419-478d-93a4-976f8aeb5849@github.com>

On Tue, 15 Jul 2025 03:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
>> 
>> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
>> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
>> `
>> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
>> 
>> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
>> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
>> 
>> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
>> 
>> It is later found to be an error in the test whereby setOnDragOver and setOnDragDropped event was not being handled in the test
>> Fixed the test now..
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert module-info change
>  - Update test with setOnDragOver and setOnDragDropped

lgtm

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1843#pullrequestreview-3025279979

From kevin.rushforth at oracle.com  Wed Jul 16 14:53:48 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 16 Jul 2025 07:53:48 -0700
Subject: FINAL REMINDER: JavaFX 25 RDP1 starts tomorrow [was: Proposed
 schedule for JavaFX 25]
In-Reply-To: <2de91cd1-655a-4f62-b525-4a5fd65dec0b@oracle.com>
References: <ef475162-14e9-47fd-b686-313640935f61@oracle.com>
 <2de91cd1-655a-4f62-b525-4a5fd65dec0b@oracle.com>
Message-ID: <78baad6f-7103-4b08-a46a-e963c2216457@oracle.com>

JavaFX 25 RDP1 starts tomorrow, July 17th. I will fork the 'jfx25' 
branch at 16:00 UTC.

-- Kevin


On 7/7/2025 11:57 AM, Kevin Rushforth wrote:
> As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 25 starts on 
> Thursday, July 17, 2025 at 16:00 UTC (09:00 US/Pacific time), ten days 
> from now.
>
> During rampdown of JavaFX 25, the "master" branch of the jfx repo will 
> be open for JavaFX 26 fixes.
>
> Please allow sufficient time for any feature that needs a CSR. New 
> features should be far enough along in the review process that you can 
> finalize the CSR no later than Thursday, July 10, or it is likely to 
> miss the window for this release, in which case it can be targeted for 
> JavaFX 26.
>
> We will follow the same process as in previous releases for getting 
> fixes into JavaFX 25 during rampdown. I'll send a message with 
> detailed information when we fork, but candidates for fixing during 
> RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc 
> bugs of any priority. Some small enhancements might be considered 
> during RDP1, but they require explicit approval; the bar will be high 
> for such requests.
>
> -- Kevin
>
> On 5/10/2025 9:16 AM, Kevin Rushforth wrote:
>
>> Here is the proposed schedule for JavaFX 25:
>>
>> RDP1: Jul 17, 2025 (aka ?feature freeze?)
>> RDP2: Aug 7, 2025
>> RC: Aug 28, 2025 (aka ?code freeze?)
>> GA: Sep 16, 2025
>>
>> We plan to fork a jfx25 stabilization branch at RDP1.
>>
>> The start of RDP1, the start of RDP2, and the code freeze will be 
>> 16:00 UTC on the respective dates.
>>
>> Please let Johan or me know if you have any questions.
>>
>> -- Kevin
>


From angorya at openjdk.org  Wed Jul 16 15:01:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Jul 2025 15:01:47 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
Message-ID: <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>

On Tue, 15 Jul 2025 05:41:32 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:
> 
>   changes for running apps in eclipse

you might want to sync up with the latest master.

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

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

From psadhukhan at openjdk.org  Wed Jul 16 15:36:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 16 Jul 2025 15:36:53 GMT
Subject: Integrated: 8141391: Manual JFXPanel DnD test doesn't work
In-Reply-To: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
References: <CAELPsldk0Aez6sS0Il6a34BYdsDJX-vo5pqpGgMB_Q=.dec983c4-0756-46a0-8b46-821d4235b8e5@github.com>
Message-ID: <-YWKfoCEEKJ_KarmCXbcdsOxgfL1m6IDpRmNgPH2BDk=.7ecfdbcd-93f7-4459-b523-43ada66c10f9@github.com>

On Fri, 11 Jul 2025 04:17:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when `JFXPanel `is used to embed some JavaFX components and when we drag something from swing or an external application and try to drop on a JavaFX component inside the JFXPanel, it doesn't accept the drop showing "block" sign suggesting DnD is blocked. 
> 
> The problem is in both drag and drop side of operations where `acceptDrag `and `acceptDrop `on `DropTargetDragEvent `is not called because `DragEvent constructor` called from `Scene `
> [which is called from `SwingDnD `via `EmbeddedSceneDTInterface.handleDragEnter` and `handleDragDrop] 
> `
> is not storing `state.acceptedTransferMode` when eventType is not `DragEvent.DRAG_DROPPED` or `DragEvent.DRAG_DONE` but Scene creates DragEvent with only `DragEvent.ANY`
>  so `handleDragEnter `and `handleDragDrop `returns null as `DragEvent.getAcceptedTransferMode` returns null
> 
> Fix is made so that instead of relying on return value of handleDragEnter/handleDragDrop  which seems to be always null for reason mentioned above, we rely on `isDataFlavorSupported `check for the drag and drop as is being done in JDK side of DnD scheme.
> Also, to have a proper drop of the data, we get the focus owner from the JFXPanel scene and insert the text in the location pointed to by the mouse cursor.
> 
> Regression test is already present in tests/manual/swing/DragDropOntoJavaFXControlInJFXPanelTest.java
> 
> It is later found to be an error in the test whereby setOnDragOver and setOnDragDropped event was not being handled in the test
> Fixed the test now..

This pull request has now been integrated.

Changeset: 99866ae1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/99866ae1f197ae5593b728bedceb00121fe4baca
Stats:     24 lines in 1 file changed: 24 ins; 0 del; 0 mod

8141391: Manual JFXPanel DnD test doesn't work

Reviewed-by: kcr, angorya

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

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

From mfox at openjdk.org  Wed Jul 16 16:39:46 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 16 Jul 2025 16:39:46 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <ea8uqtRR0BbecQ9UjYWemKVpq4XAqU3Q68-Lx3jFmqI=.7e5ce14c-ae1b-4afa-956c-d4b32c477a81@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
 <R6KMmgz9Cxidr1YhvAl2sRGhQ5Ab4fZuv3aysRQ9VVY=.2eccd5e5-5c50-4983-8a6a-84aed08974d5@github.com>
 <iGqtzAcIqDdkPLkPRzf0T2FJjglzI8sbrdpxI8tkzKg=.5cb01bc5-fa07-4174-92e1-6dffa51e26d2@github.com>
 <JYFo_ilHpkdtkYOBAjiwpes_uFdZRu7QRDrb0w-n34U=.dd1ce684-8af8-4b7f-a6ea-93a03f069fb5@github.com>
 <ea8uqtRR0BbecQ9UjYWemKVpq4XAqU3Q68-Lx3jFmqI=.7e5ce14c-ae1b-4afa-956c-d4b32c477a81@github.com>
Message-ID: <mmZzaxDV3Bfvhwg3A_tnNz2mqvkAYZzErdlakr2wEx8=.2cc7d0df-5c9f-42ed-8b5f-26767885318c@github.com>

On Wed, 16 Jul 2025 02:47:21 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> But in my view we should consider it as a control bug, not as a legitimate use of the event system.

If we decided to fix this in controls and discard this PR as unnecessary I would not shed any tears. I knew this would be clunky but felt we at least needed to get a look at a fix like this. I also wanted this in hand since the timeline for fixing this in controls is uncertain.

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3079401685

From arapte at openjdk.org  Wed Jul 16 16:44:47 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 16 Jul 2025 16:44:47 GMT
Subject: RFR: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name [v3]
In-Reply-To: <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
 <XAWCUWkRbN9CVcpW0yvfh06KvUI4JAnkNl5__2xryeQ=.82c24488-0139-49dd-9e7f-8709249d6330@github.com>
Message-ID: <dw_kZKaE_QbhvoM9RY7exiAfQFoXhvn3eOgDKUKtg6E=.a897c25d-14ee-4210-9e1b-8fc197e71c01@github.com>

On Wed, 9 Jul 2025 05:01:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> - Copyright year update;
>> - Introduce new function requestNodeAttribute and refactor code to use it;
>> - Fix some typos;
>> - Enable new code to handle TabPages since TabGroup was implemented;
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove explicit jresult declaration

LGTM

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1840#pullrequestreview-3025865584

From mfox at openjdk.org  Wed Jul 16 16:44:47 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 16 Jul 2025 16:44:47 GMT
Subject: RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar
 shortcuts [v2]
In-Reply-To: <DeG77SVK3MyKwou8_aYI4GJx47xIp9OXaXm_gNqH-ps=.a12cb398-0d6a-4cc8-86d6-894f0e25f3af@github.com>
References: <JNiiqMDs5CqmHy6E6hv4A7XPtzMh3cw-mjpOZIh7ygs=.3c741c56-8850-4efb-965f-5c37d799e922@github.com>
 <6XH-vSIEe0QSDDdo8hXA6JdKGAlhU2gBlJyrae2qOB4=.e3301fc7-f1b8-402a-90eb-5079ad266dc7@github.com>
 <DeG77SVK3MyKwou8_aYI4GJx47xIp9OXaXm_gNqH-ps=.a12cb398-0d6a-4cc8-86d6-894f0e25f3af@github.com>
Message-ID: <QFSZU0ChBsLr7IvBE1wyPIppSVhQDs7ZLaveU6lt_wM=.699c78fb-9910-4ae5-9a1a-5ad5e5e969ae@github.com>

On Tue, 15 Jul 2025 21:13:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> So it it a responsibility of the entity that creates the secondary event to either consume the original event or let it go, or am I mistaken?

This would mean two unconsumed KeyEvents would bubble all the way up to the scene. This could trigger the same MenuItem twice even though the user only pressed the accelerator once.

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3079416642

From angorya at openjdk.org  Wed Jul 16 19:06:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Jul 2025 19:06:56 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
Message-ID: <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@github.com>

On Tue, 15 Jul 2025 05:41:32 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:
> 
>   changes for running apps in eclipse

first batch of comments (java), mostly questions and minor suggestions.  will review the native code next.

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

> 332: 
> 333:             try {
> 334:                 FileWriter fragmentShaderHeaderFile = new FileWriter(headerFilesDir + FRAGMENT_SHADER_HEADER_FILE_NAME);

This writer is not buffered, meaning it will be too slow.
I'd say either to wrap it into `BufferedWriter`, or better yet - use `StringBuilder`s everywhere and write the single generated string in one operation.

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

> 334:                 FileWriter fragmentShaderHeaderFile = new FileWriter(headerFilesDir + FRAGMENT_SHADER_HEADER_FILE_NAME);
> 335:                 fragmentShaderHeaderFile.write(fragmentShaderHeader.toString());
> 336:                 fragmentShaderHeaderFile.write("#endif\n");

this line is weird - why is it here and not after L331?

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

> 335:                 fragmentShaderHeaderFile.write(fragmentShaderHeader.toString());
> 336:                 fragmentShaderHeaderFile.write("#endif\n");
> 337:                 fragmentShaderHeaderFile.close();

an exception on lines 335-336 will cause the writer not being closed. 
can we use try-with-resources?

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

> 344: 
> 345:         try {
> 346:             FileWriter objCHeaderFile = new FileWriter(headerFilesDir + objCHeaderFileName);

same issue here, need to close the writer properly.

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

> 421: 
> 422:             objCHeaderFile.write("    return nil;\n");
> 423:             objCHeaderFile.write("};\n\n");

Not sure if it's worth doing, but perhaps this code can use a single StringBuilder to build the code, then use `Files.writeString()` to write it (this might require a bit of refactoring).

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

> 442:         }
> 443: 
> 444:         uniformsForShaderFile = uniformsForShaderFile.replace(" float2", " vector_float2");

feels like this code was written in 1997.  Use a StringBuilder perhaps?

modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 53:

> 51:     // a value of zero corresponds to the windowing system-provided
> 52:     // framebuffer object
> 53:     long nativeDestHandle = 0;

`= 0` is not strictly necessary.

modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 240:

> 238:     @Override
> 239:     public int getFboID() {
> 240:         return (int)nativeDestHandle;

this results in loss of information.  any possibility that it may backfire somehow, by mapping two different `nativeDestHandle`s to the same `int`?

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

> 157:     @Override
> 158:     protected State updateRenderTarget(RenderTarget target, NGCamera camera, boolean depthTest) {
> 159:         MTLLog.Debug("MTLContext.updateRenderTarget() :target = " + target + ", camera = " + camera + ", depthTest = " + depthTest);

general question: is this temporary?  can we use maybe a better logging mechanism, one that does not concatenate strings when disabled?  works case, surround this by `if(debug)` ?

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

> 170: 
> 171:         // Validate the camera before getting its computed data
> 172:         if (camera instanceof NGDefaultCamera) {

suggestion: `if (camera instanceof NGDefaultCamera nc)` to avoid explicit cast in L173

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

> 178:             double vw = camera.getViewWidth();
> 179:             double vh = camera.getViewHeight();
> 180:             if (targetWidth != vw || targetHeight != vh) {

would it make sense to detect the case when target(w/h) is very close to (w/h) and skip scaling?  or is this scenario unlikely?

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

> 337: 
> 338:     public long getMetalCommandQueue()
> 339:     {

I like this style, but the rest of the file uses K&R braces...

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

> 348:         // if (checkDisposed()) return;
> 349:         // nSetDeviceParametersFor2D(pContext);
> 350:     }

remove the commented out code LL348-349, leave the comment?

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

> 355:         // result of this call, hence the method is no-op.
> 356:         // But overriding the method here for any future reference.
> 357:         // if (checkDisposed()) return;

same here?

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

> 487:     }
> 488: 
> 489:     private void printRawMatrix(String mesg) {

unused method?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLLog.java line 31:

> 29: 
> 30: public class MTLLog {
> 31:     public static void Debug(String str) {

Since `MTTLLog` is a home-grown facility:

perhaps we should consider allowing `Supplier<String>` lambdas (or `Supplier<Object>`), or allow for `MessageFormat`'ted strings, to avoid concatenations.

Lambdas may be faster, but they do require effectively final parameters.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 60:

> 58:     @Override
> 59:     public void dispose() {
> 60:         disposerRecord.dispose();

two questions here:
1. why is `disposerRecord.dispose()`; here (and in `D3DMesh`, `ES2Mesh`) and not in the `BaseGraphicResource` ?
2. any danger in the `dispose()` being called twice?  (could it happen at all?)

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 93:

> 91:         }
> 92: 
> 93:         void traceDispose() {}

what's the purpose of this method?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 104:

> 102:                 String logname = PhongMaterial.class.getName();
> 103:                 PlatformLogger.getLogger(logname).warning(
> 104:                         "Warning: Low on texture resources. Cannot create texture.");

I suppose this message is the same as elsewhere.  Is it clear enough for the user?  Does the user have a clear idea of how to correct the issue?

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:             HashMap devDetails = (HashMap) MTLPipeline.getInstance().getDeviceDetails();

cast is unnecessary.  suggestion: 
`Map devDetails = MTLPipeline.getInstance().getDeviceDetails();`

I guess we've inherited the API based on the raw object here?

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

> 33:     @Override
> 34:     public void dispose() {
> 35:         if (pTexture != 0L) {

this code is weird: why doesn't call super.dispose()?

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

> 73:             i *= 2;
> 74:         }
> 75:         return i;

interesting...  would `1 << val` be simpler (barring overflow)?

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

> 126:             return (Shader) m.invoke(null, new Object[]{this, shaderName, nameStream});
> 127:         } catch (Throwable e) {
> 128:             e.printStackTrace();

do we want to use a logger or the `stderr` is the best decision in this case?

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

> 181: 
> 182:         long pResource = nCreateTexture(context.getContextHandle() ,
> 183:                 (int) formatHint.ordinal(), (int) usageHint.ordinal(),

unnecessary casts to (int) x2

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

> 272:         Texture tex = createTexture(texFormat, Usage.DEFAULT, WrapMode.CLAMP_TO_EDGE, texWidth, texHeight);
> 273: 
> 274:         frame.releaseFrame();

could all these `frame.releaseFrame()` be moved to a `finally` block?

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

> 303:     @Override
> 304:     public int getRTTWidth(int w, Texture.WrapMode wrapMode) {
> 305:         // Below debugging logic replicates D3DResoureFactory

is this code still needed?  also L314

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()?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 57:

> 55:             shaderMap.put(fragmentFunctionName, this);
> 56:         } else {
> 57:             throw new AssertionError("Failed to create Shader");

is `AssertionError` the right type here?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 128:

> 126: 
> 127:         if (pState.getNativeFrameBuffer() == 0) {
> 128:             System.err.println("Native backbuffer texture from Glass is nil.");

is `stderr` ok here?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 143:

> 141:                 stableBackbuffer = null;
> 142:             } /*else {
> 143:                 // RT-27554

is this still relevant?

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

> 95:                         int srcscan, boolean skipFlush) {
> 96: 
> 97:         if (format.getDataType() == PixelFormat.DataType.INT) {

would a `switch` be better here?

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

> 120:             byte[] arr = buf.hasArray() ? buf.array() : null;
> 121: 
> 122:             if (format == PixelFormat.BYTE_BGRA_PRE || format == PixelFormat.BYTE_ALPHA) {

also here, `switch` ?

modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/hw/mtl/MTLShaderSource.java line 36:

> 34:     @Override
> 35:     public InputStream loadSource(String name) {
> 36:         // MSL shaders are compilend and linked into a MTLLibrary at build time.

-> compiled

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3025473708
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210708247
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210709590
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210695663
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210697664
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210751940
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210757844
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210763281
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210767379
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210942089
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210945178
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210961660
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210974725
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210977355
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210977769
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2210983716
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211116140
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211133718
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211139193
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211147969
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211163123
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211170894
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211174999
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211177828
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211182961
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211193965
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211197823
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211205783
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211211057
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211305810
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211306463
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211310013
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211311714
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211315024

From angorya at openjdk.org  Wed Jul 16 19:06:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Jul 2025 19:06:56 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v6]
In-Reply-To: <A5LHJIbSmKL-dGCLPxOFLAgz7UVKtMhgIOwZmjFXZu8=.69116e72-cef3-47f2-8b3d-fdcc55bc8b26@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <Y2V1VWzUFbP1kdAAVk9iy_tFkA2Rc7hvsFrPsEcXt3g=.1a13beff-ae41-4ab5-8073-6130ae6ad275@github.com>
 <RmUFUPBQzyb-KMDkWshP8KVVCjle6BWbisXDb9eT2yw=.69a53fd0-692b-4f7c-918f-aafbcd8046c7@github.com>
 <A5LHJIbSmKL-dGCLPxOFLAgz7UVKtMhgIOwZmjFXZu8=.69116e72-cef3-47f2-8b3d-fdcc55bc8b26@github.com>
Message-ID: <Y1z0FGJwMWZfQzYjbw9CdEFIUwrU0BJyXDoXwTCdpAE=.6075c3a7-3f2b-46eb-a542-a910d7b2044d@github.com>

On Wed, 16 Jul 2025 05:37:27 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> this seems WebView specific

I agree.

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

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

From angorya at openjdk.org  Wed Jul 16 19:59:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 16 Jul 2025 19:59:50 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
Message-ID: <3y63cx6fjvyVFGQg4Qjbn7F72urOjMSnVauLg-eFIEQ=.05ad6216-41f5-4f54-b8c8-48ed569697f3@github.com>

On Tue, 15 Jul 2025 05:41:32 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:
> 
>   changes for running apps in eclipse

modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.h line 45:

> 43:     GLuint              _textureWidth;
> 44:     GLuint              _textureHeight;
> 45:     NSView* glassView;

minor: we probably should not try to align, but simply use a single space char, as in java code.

modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.m line 48:

> 46:             {
> 47:                 // TODO: implement PBuffer if needed
> 48:                 // self->_fbo = [[GlassPBuffer alloc] init];

commented out - is it going to crash of the value is `nil`?

modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.m line 143:

> 141:                                                                             withObject:nil
> 142:                                                                          waitUntilDone:NO
> 143:                                                                                  modes:allModes];

minor: this indentation is hard to look at

modules/javafx.graphics/src/main/native-glass/mac/GlassMTLOffscreen.m line 68:

> 66:     [(NSObject*)self->_fbo release];
> 67:     self->_fbo = nil;
> 68:     [super dealloc];

here and elsewhere: should we protect against repeated calls to dealloc?  like `if(self->_fbo != nil)`

modules/javafx.graphics/src/main/native-prism-mtl/MetalPipelineManager.m line 32:

> 30: // ---------------------------- Debug helper for Developers -------------------------
> 31: //
> 32: // This implementation is to utilize "Metal Debuger" present in Xcode.

is the debugger available in production code?

modules/javafx.graphics/src/main/native-prism-mtl/MetalRingBuffer.m line 34:

> 32: static unsigned int currentBufferIndex;
> 33: 
> 34: - (MetalRingBuffer*) init:(MetalContext*)ctx

ring buffers are a frequent source of off-by-one bugs.
is it possible to have a unit test for it?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211378208
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211379651
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211381704
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211390403
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211415829
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211426199

From kizune at openjdk.org  Wed Jul 16 21:11:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 16 Jul 2025 21:11:53 GMT
Subject: Integrated: 8361379: [macos] Refactor accessibility code to retrieve
 attribute by name
In-Reply-To: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
References: <yLtxa-wHbsfU5EtQlhAoBHuJ503z234wJh4_at2_aGg=.90c25029-67e7-4f19-9ced-1e53055002b4@github.com>
Message-ID: <BehXKtDTI9LIcUKX3BakGJrFYvhcuGD7LrtnTQ1msFw=.0fb6a2a9-7665-4a75-8254-b626fb2b297b@github.com>

On Thu, 3 Jul 2025 22:17:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Copyright year update;
> - Introduce new function requestNodeAttribute and refactor code to use it;
> - Fix some typos;
> - Enable new code to handle TabPages since TabGroup was implemented;

This pull request has now been integrated.

Changeset: 2dd90265
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2dd90265637dc1c17fa4f5ab36500564b19ce082
Stats:     93 lines in 3 files changed: 12 ins; 54 del; 27 mod

8361379: [macos] Refactor accessibility code to retrieve attribute by name

Reviewed-by: angorya, arapte

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

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

From kcr at openjdk.org  Wed Jul 16 22:59:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 16 Jul 2025 22:59:56 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
Message-ID: <AHweO5hXWcMzLw40VhVnEs6DM9fTco9yFg54pEkebBQ=.ec323849-468b-40f4-b485-fe93751120c1@github.com>

On Thu, 3 Jul 2025 19:30:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding missing APIs related to styling the highlights with CSS:
>> 
>> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
>> 
>> 
>> 
>> Adds methods to the `RichParagraph.Builder`:
>> 
>> 
>>         /**
>>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addWavyUnderline(int start, int length, String ... css) {
>> 
>> 
>> 
>>         /**
>>          * Adds a highlight with the specified style name(s).
>>          * Use translucent colors to enable multiple highlights in the same region of text.
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addHighlight(int start, int length, String ... css) {
>> 
>> 
>> 
>> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
>> 
>> 
>>     /**
>>      * Adds a highlight of the given color to the specified range within the last paragraph,
>>      * with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
>> 
>> 
>>     /**
>>      * Adds a wavy underline (typically used as a spell checker indicator)
>>      * to the specified range within the last paragraph, with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8355774.css
>  - Merge remote-tracking branch 'origin/master' into 8355774.css
>  - tab
>  - css

@lukostyra will be the second reviewer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1802#issuecomment-3081640577

From mstrauss at openjdk.org  Thu Jul 17 05:11:36 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Jul 2025 05:11:36 GMT
Subject: RFR: 8343956: Focus delegation API [v2]
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <CEXgmpJBaVr-j_EwdD2JcLnEToP0WzoTN71FRHPR8qU=.d0d67f74-6433-41cf-8bc8-476d4fef059c@github.com>

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

  Handling of several edge cases

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1632/files
  - new: https://git.openjdk.org/jfx/pull/1632/files/a9e6b8f8..6e00f8e5

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

  Stats: 556 lines in 3 files changed: 463 ins; 40 del; 53 mod
  Patch: https://git.openjdk.org/jfx/pull/1632.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1632/head:pull/1632

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

From mstrauss at openjdk.org  Thu Jul 17 05:18:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Jul 2025 05:18:28 GMT
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
Message-ID: <0z7rV1mYpy3Ee1jWu-qySJIdVn8-oKUasLg3vT6cuZQ=.29367184-cc6f-498b-b0dc-ed59a686dbc0@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1632/files
  - new: https://git.openjdk.org/jfx/pull/1632/files/6e00f8e5..132e496d

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

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

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

From mstrauss at openjdk.org  Thu Jul 17 05:58:54 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Jul 2025 05:58:54 GMT
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <C-K0RQQ251pq4IwwU7iIktqUknS36HnzjzlM_NqEJ3Q=.b78142da-268a-4b7f-a25a-bd0199b54760@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
 <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
 <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>
 <hCRB6G_Pk7-LsGwA9JO8Q8vyHabedAB-8722vThIqEk=.f65aad28-5491-4a75-a64e-d642d1617d2d@github.com>
 <C-K0RQQ251pq4IwwU7iIktqUknS36HnzjzlM_NqEJ3Q=.b78142da-268a-4b7f-a25a-bd0199b54760@github.com>
Message-ID: <mUN7cphJhicNNMbknjkhqSziRZkKXnZejKn6yi_5OAk=.38f2ed03-a629-4f04-baf5-967dbaa9f537@github.com>

On Mon, 14 Jul 2025 18:59:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Yeah, I'm sure traversal is solvable, I just wanted to spend some cycles figuring it out. For example, would you set focusTraversable on the date/time control AND it's delegates? My guess is just the delegates but this is the sort of thing one would want to prototype.
>> 
>> To be clear I'm not trying to solve traversal in this round. I just want to make sure we have mapped out the path forward so the API will accommodate traversal eventually.
>
> When I have a few moments, I'll see if I can create the date entry control, and see how it works with this solution.  I can then override Scene code to see if navigation is a quick fix or a huge issue.

> Currently we turn on input method processing at the platform level if and only if there's any control in the focus chain that is set up to receive input method events and respond to input method requests. That could be any focusOwner in any focused Scene or any one of the focusOwners' delegates. So I need to see the entire delegate chain.
> 
> If we don't expect the focus delegate to change while a focus scope node has focus then all I need is getFocusDelegate with no parameters. If we expect the focus delegate to change dynamically it should become a property.

The focus delegate can change while a focus scope has focus, but only due to a focus request (i.e. navigation or calling `Node.requestFocus()`). I'm reasonably certain that we don't need or want the delegate to be a property. As of now, the delegate chain is simply re-evaluated in response to a focus request.

However, there's currently no easy way for `Scene` to know when the delegate chain has changed.

> The existing traversal machinery is designed to update a Scene's focusOwner not which delegate is active within the current focusOwner.

Focus traversal is not aware of what a delegate is, nor should it be. This means that focus traversal _will_ update the delegate chain if you traverse into a node that hoists focus.

I think it's important to point out that the primary use case of focus delegation is the creation of black-box controls, but focus delegation is not the same level of abstraction as black-box controls. It's better to think of focus delegation as a basic building block, and black-box controls as a higher-level abstraction.

At the `Node` level (where controls are not a thing yet), it is more approriate to picture focus delegation as a kind of openly visible multi-level focus. In this model, focus traversal doesn't differentiate between nodes based on how they came into being (e.g. as part of a skin), it simply applies the traversal algorithm on the scene graph as it is, being completely unaware of the logical grouping that is established by controls.

> In the Date/Time control you give as an example how would the user move focus between the various delegates? What would be the most intuitive model for the user? Personally I prefer the one used in macOS Calendar where Tab is used to move between the month, day, and year (or hour and minute). But that creates a conflict with using Tab to move focus into and out of the Date/Time control as a whole.

I don't know what it would mean to move focus into and out of a control as a whole. You can only meaningfully move focus into a composite control if it has at least one sub-node that can be focused. If there is no such node, then you trivially can't use focus delegation. If, on the other hand, you have a focusable sub-node, then "moving into" the composite control just means focusing the sub-node. And "moving out" of the composite control means focusing the next logically focusable node in the scene graph. I don't see any conflict here.

> In any case the question is whether a monolithic control with multiple delegates is expected to roll its own internal traversal mechanism or if we need to extend the existing mechanism to include delegates. Having each control roll its own internal traversal would hide it from the accessibility frameworks. And if we expect the existing traversal keys (like Tab) to work internally we should extend the existing traversal machinery to work with delegates.

I haven't extensively tested this yet with custom composite controls, but I think the existing traversal logic will just work as it is.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2212343939

From mstrauss at openjdk.org  Thu Jul 17 06:32:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 17 Jul 2025 06:32:55 GMT
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <APvnZbdYKf76szcxnog4E8d-Ktde-kvUm1T7jJJJzNM=.d60b1919-cbdc-4a78-a201-b754f6d95cee@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <APvnZbdYKf76szcxnog4E8d-Ktde-kvUm1T7jJJJzNM=.d60b1919-cbdc-4a78-a201-b754f6d95cee@github.com>
Message-ID: <MDPBYj5kDYqu8d7g23inVVx8a50D8k-sgbydk-YZ3YY=.50bcab5d-2687-4477-8124-1105bf105f3c@github.com>

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

> In this PR setting hoistFocus on a control only updates the flag in the control itself. What if the control?s skin introduces sub-nodes? I would assume that setting hoistFocus on a control would automatically set that flag on the control?s entire skin. Is that correct? If so what are the mechanics of making that happen?

The `hoistFocus` flag only applies to the node on which it is set, and not to its descendants. Consider a control that uses a sub-control in its skin. If the sub-control also delegates focus to one of its own descendants, then those descendants individually get to decide whether to hoist focus to the sub-control; and if so, the sub-control will further hoist focus to the outer control.

Automatically setting this flag precludes the option to have sub-nodes that _don't_ hoist focus. Consider a Button: it has an optional sub-node (`graphic`) that is independently focusable and doesn't hoist focus. A custom button could conceivably have both: a delegate (maybe a text field), as well as an independently focusable sub-node.

> It seems hoistFocus is serving two roles. One is an optimization so that requestFocus knows whether it should walk the scene graph looking for a focus-scope node. For that use the flag should be propagated through descendants in the graph. But it?s also being proposed as a hoisting barrier e.g. when it?s _not_ set it prevents focus from hoisting upward even if there's a focus-scope node higher up in the graph. But a barrier applies just to a single node and should not be propagated. So I?m having a difficult time figuring out when and how this flag should be propagated through the tree. But I?m no expert on skins so maybe I?m assuming this is more complicated than it actually is.

`hoistFocus` is not an optimization, it's semantically relevant in the way I described.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2212398078

From lkostyra at openjdk.org  Thu Jul 17 08:49:59 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 17 Jul 2025 08:49:59 GMT
Subject: RFR: 8355774: RichTextArea: provide mechanism for CSS styling of
 highlights [v3]
In-Reply-To: <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
 <TsPEvUOQoORFGD7HG3QKJUczjCC2ahfsOOrqeuyAAHE=.f3ef35d8-1f4a-4623-a15b-e3bd9f55031f@github.com>
Message-ID: <FsXlqvKhk8Qmj8xuP6SJGWrAJ-OEffqozUuyePxZ35Y=.c8a6d9c8-ccb6-42a7-b112-bb3b09376442@github.com>

On Thu, 3 Jul 2025 19:30:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding missing APIs related to styling the highlights with CSS:
>> 
>> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
>> 
>> 
>> 
>> Adds methods to the `RichParagraph.Builder`:
>> 
>> 
>>         /**
>>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addWavyUnderline(int start, int length, String ... css) {
>> 
>> 
>> 
>>         /**
>>          * Adds a highlight with the specified style name(s).
>>          * Use translucent colors to enable multiple highlights in the same region of text.
>>          * <p>
>>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>>          *
>>          * @param start the start offset
>>          * @param length the end offset
>>          * @param css the style name(s)
>>          * @return this {@code Builder} instance
>>          * @since 25
>>          */
>>         public Builder addHighlight(int start, int length, String ... css) {
>> 
>> 
>> 
>> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
>> 
>> 
>>     /**
>>      * Adds a highlight of the given color to the specified range within the last paragraph,
>>      * with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
>> 
>> 
>>     /**
>>      * Adds a wavy underline (typically used as a spell checker indicator)
>>      * to the specified range within the last paragraph, with the specified style name(s).
>>      *
>>      * @param start the start offset
>>      * @param length the length of the highlight
>>      * @param css the highlight style name(s)
>>      * @return this model instance
>>      * @since 25
>>      */
>>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8355774.css
>  - Merge remote-tracking branch 'origin/master' into 8355774.css
>  - tab
>  - css

Looks good, changes work well on Windows

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

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1802#pullrequestreview-3028557979

From arapte at openjdk.org  Thu Jul 17 09:14:04 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 17 Jul 2025 09:14:04 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v10]
In-Reply-To: <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
Message-ID: <0hfoVDUPwJSL5Wp5biFiSAyo_ToC2Od84Fy4xxkXoOc=.64971d34-9273-40d8-a710-c4b84369fa61@github.com>

On Tue, 15 Jul 2025 17:32:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - ... and 57 more: https://git.openjdk.org/jfx/compare/1a2a50b5...5252633b

LGTM+

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

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1744#pullrequestreview-3028649704

From lkostyra at openjdk.org  Thu Jul 17 09:18:42 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 17 Jul 2025 09:18:42 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Adjust error message for window-on-top check

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/56cdcf4b..90be8123

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

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

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

From kcr at openjdk.org  Thu Jul 17 12:34:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Jul 2025 12:34:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
Message-ID: <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>

On Wed, 16 Jul 2025 14:59:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> you might want to sync up with the latest master.

Agreed, although you might wait until after the jfx25 fork at this point.

> modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 53:
> 
>> 51:     // a value of zero corresponds to the windowing system-provided
>> 52:     // framebuffer object
>> 53:     long nativeDestHandle = 0;
> 
> `= 0` is not strictly necessary.

But it isn't harmful. More to the point, this PR tries to minimize changes to existing code, and removing the `= 0` would be an unrelated change.

> modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 240:
> 
>> 238:     @Override
>> 239:     public int getFboID() {
>> 240:         return (int)nativeDestHandle;
> 
> this results in loss of information.  any possibility that it may backfire somehow, by mapping two different `nativeDestHandle`s to the same `int`?

Good question. Given that the ES2 pipeline only ever uses an int value, it's _probably_ fine. But it's hard to prove without looking at the native code. At the very least, a comment explaining this would be good.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 57:
> 
>> 55:             shaderMap.put(fragmentFunctionName, this);
>> 56:         } else {
>> 57:             throw new AssertionError("Failed to create Shader");
> 
> is `AssertionError` the right type here?

Good catch. I think this should throw a `RuntimeException` of some sort.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3083891955
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211384171
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211407796
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2211394358

From angorya at openjdk.org  Thu Jul 17 14:43:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Jul 2025 14:43:08 GMT
Subject: RFR: 8314482: TextFlow: TabStopPolicy [v10]
In-Reply-To: <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
 <XgSKu2pDesUk-VToclNuzYo_xUltC02oCxjGRx_7DLQ=.ab891e20-0def-4abb-87b8-282ffbde76e8@github.com>
Message-ID: <_2HNeQUWu_Ki4zNIN0rL8Wy8LxgqaTcYDWxv4sWZxWk=.54248a04-6754-4894-9fc6-81e2d5c36006@github.com>

On Tue, 15 Jul 2025 17:32:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> # Tab Stop Policy
>> 
>> Andy Goryachev
>> 
>> <andy.goryachev at oracle.com>
>> 
>> 
>> ## Summary
>> 
>> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
>> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
>> segments font [0].
>> 
>> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
>> 
>> 
>> ## Goals
>> 
>> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
>> 
>> 
>> 
>> ## Non-Goals
>> 
>> The following are not the goals of this proposal:
>> 
>> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
>> - support the `leader` property (symbols to fill the empty space before the tab stop)
>> - support for `firstLineIndent` property
>> - deprecate the `TextFlow::tabsize` property
>> 
>> 
>> 
>> ## Motivation
>> 
>> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
>> contains text with different font sizes.
>> 
>> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
>> in RTF or MS Word documents.
>> 
>> 
>> 
>> 
>> ## Description
>> 
>> ### TextFlow
>> 
>> 
>>     /**
>>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>>      * <p>
>>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>>      * this {@code TextFlow}.
>>      *
>>      * @defaultValue null
>>      *
>>      * @since 999 TODO
>>      */
>>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
>> 
>>     public final TabStopPolicy getTabStopPolicy() {
>> 
>>     public final void setTabStopPolicy(TabStopPolicy policy) {
>> 
>>     /**
>>      * The size of a tab stop in spaces.
>>      * Values less than 1 are treated as 1. This value overrides the
>>      * {@code tabSize} of contained {@link Text} nodes.
>>      * <p>
>> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
>> +     * with different fonts are contained within this {@code TextFlow}.
>> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>>      *
>>      * @defaultValue 8
>>      *...
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - link
>  - oops
>  - since 25
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - Merge remote-tracking branch 'origin/master' into 8314482.tab.stops
>  - final tab stop
>  - ... and 57 more: https://git.openjdk.org/jfx/compare/1a2a50b5...5252633b

thank you all

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

PR Comment: https://git.openjdk.org/jfx/pull/1744#issuecomment-3084334387

From angorya at openjdk.org  Thu Jul 17 14:43:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Jul 2025 14:43:10 GMT
Subject: Integrated: 8314482: TextFlow: TabStopPolicy
In-Reply-To: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
References: <HeWMGNTXraZMb37avJYKaQR-b-JUbu7j2JK-ILqYQFs=.5456276f-1127-4e5d-9f50-a81c11203e03@github.com>
Message-ID: <XzkGYRzk-yNBNRGXzllq8VZCMDGEGNl6qik1rOcNF0E=.132dcecd-6b82-4034-a06e-d1025c536380@github.com>

On Wed, 26 Mar 2025 14:41:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> # Tab Stop Policy
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `tabStopPolicy` property in the `TextFlow` class which, when set, overrides the existing `tabSize`
> value and provides consistent way of setting tab stops at the paragraph level, regardless of the individual text
> segments font [0].
> 
> ![Screenshot 2025-05-19 at 15 03 26](https://github.com/user-attachments/assets/32f2474d-7d2b-47b0-a22c-410d485f4e40)
> 
> 
> ## Goals
> 
> The goal of this proposal is to provide a better way for controlling tab stops in the `TextFlow` containing rich text.
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - support for tab stop types (BAR, or DECIMAL), or attributes like `alignment`
> - support the `leader` property (symbols to fill the empty space before the tab stop)
> - support for `firstLineIndent` property
> - deprecate the `TextFlow::tabsize` property
> 
> 
> 
> ## Motivation
> 
> The existing `tabSize` property in the `TextFlow` is inadequate for representing tab stops when the content
> contains text with different font sizes.
> 
> In addition to that, a rich text editor might require support for user-customizable tab stops, similar to that provided
> in RTF or MS Word documents.
> 
> 
> 
> 
> ## Description
> 
> ### TextFlow
> 
> 
>     /**
>      * {@code TabAdvancePolicy} determines the tab stop positions within this {@code TextFlow}.
>      * <p>
>      * A non-null {@code TabAdvancePolicy} overrides values set by {@link #setTabSize(int)},
>      * as well as any values set by {@link Text#setTabSize(int)} in individual {@code Text} instances within
>      * this {@code TextFlow}.
>      *
>      * @defaultValue null
>      *
>      * @since 999 TODO
>      */
>     public final ObjectProperty<TabStopPolicy> tabStopPolicyProperty() {
> 
>     public final TabStopPolicy getTabStopPolicy() {
> 
>     public final void setTabStopPolicy(TabStopPolicy policy) {
> 
>     /**
>      * The size of a tab stop in spaces.
>      * Values less than 1 are treated as 1. This value overrides the
>      * {@code tabSize} of contained {@link Text} nodes.
>      * <p>
> +     * Note that this method should not be used to control the tab placement when multiple {@code Text} nodes
> +     * with different fonts are contained within this {@code TextFlow}.
> +     * In this case, the {@link #setTabStopPolicy(TabStopPolicy)} should be used instead.
>      *
>      * @defaultValue 8
>      *
>      * @since 14
>      */
>     public final IntegerProperty tabSizeProperty() {
> 
> 
> 
> ### TabStopPolicy
> 
> 
> /**
>  * The TabStopPolicy determines the tab stop pos...

This pull request has now been integrated.

Changeset: 22e43c58
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/22e43c58af8ca293052b54d86c78818fc32f09d9
Stats:     701 lines in 13 files changed: 671 ins; 5 del; 25 mod

8314482: TextFlow: TabStopPolicy

Reviewed-by: kcr, arapte

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

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

From angorya at openjdk.org  Thu Jul 17 14:44:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Jul 2025 14:44:59 GMT
Subject: Integrated: 8355774: RichTextArea: provide mechanism for CSS styling
 of highlights
In-Reply-To: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
References: <8av8h9w_MLkAWTwsbKdfMPeOWyZEQm0ZPMHRa9zFMnA=.6d774050-7258-449f-98db-b130f6ea9785@github.com>
Message-ID: <RYtY-9uFDMf-u47m2EI77rIN02v7YyGvX6kRpIjsvYQ=.bdfe123d-0826-4161-a58e-7b092b13421f@github.com>

On Wed, 7 May 2025 22:57:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding missing APIs related to styling the highlights with CSS:
> 
> ![Screenshot 2025-05-07 at 15 08 53](https://github.com/user-attachments/assets/e37062b4-9804-40a7-872d-830fe0f584c1)
> 
> 
> 
> Adds methods to the `RichParagraph.Builder`:
> 
> 
>         /**
>          * Adds a wavy underline (typically used as a spell checker indicator) with the specified style name(s).
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addWavyUnderline(int start, int length, String ... css) {
> 
> 
> 
>         /**
>          * Adds a highlight with the specified style name(s).
>          * Use translucent colors to enable multiple highlights in the same region of text.
>          * <p>
>          * The corresponding styles should define CSS properties applicable to {@link javafx.scene.shape.Path}.
>          *
>          * @param start the start offset
>          * @param length the end offset
>          * @param css the style name(s)
>          * @return this {@code Builder} instance
>          * @since 25
>          */
>         public Builder addHighlight(int start, int length, String ... css) {
> 
> 
> 
> Also adding similar methods to the `SimpleViewOnlyStyledModel` class:
> 
> 
>     /**
>      * Adds a highlight of the given color to the specified range within the last paragraph,
>      * with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel highlight(int start, int length, String ... css) {
> 
> 
>     /**
>      * Adds a wavy underline (typically used as a spell checker indicator)
>      * to the specified range within the last paragraph, with the specified style name(s).
>      *
>      * @param start the start offset
>      * @param length the length of the highlight
>      * @param css the highlight style name(s)
>      * @return this model instance
>      * @since 25
>      */
>     public SimpleViewOnlyStyledModel addWavyUnderline(int start, int length, String ... css) {

This pull request has now been integrated.

Changeset: c9159193
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c915919369efd10662d1c71b7454f33237054dfb
Stats:     128 lines in 4 files changed: 110 ins; 8 del; 10 mod

8355774: RichTextArea: provide mechanism for CSS styling of highlights

Reviewed-by: kcr, lkostyra

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

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

From kcr at openjdk.org  Thu Jul 17 15:06:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Jul 2025 15:06:59 GMT
Subject: RFR: 8362079: Change JavaFX release version to 26
In-Reply-To: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
References: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
Message-ID: <etlVBCd7wemET6W6NQgx7sJRzH0dXbbs9J_oOgPlbsE=.b6d97de9-b7f3-4d90-a608-e5241d02d187@github.com>

On Mon, 14 Jul 2025 14:18:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 26. I will integrate this to master as part of forking the jfx25 stabilization branch, which is scheduled for Thursday, July 17, 2025 at 16:00 UTC.

I was off by an hour and entered the `/integrate` command too early (about 3 minutes ago). I immediately deleted it, and I hope I was fast enough so that Skara didn't see it. I don't expect anything to be integrated in the next hour, but plan to wait until the announced time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1847#issuecomment-3084423814

From mfox at openjdk.org  Thu Jul 17 15:41:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 17 Jul 2025 15:41:58 GMT
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <mUN7cphJhicNNMbknjkhqSziRZkKXnZejKn6yi_5OAk=.38f2ed03-a629-4f04-baf5-967dbaa9f537@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <taYtn-oD4JdwbL5bzxYmLLe6vQDYD2ha_z4rhRFyckA=.61f30f15-52a1-4e77-ab6c-1c6f5b7238a0@github.com>
 <V_sSiIc79vd4GJvDvslfznLpPO-VRsafL7OcMu8rfMk=.b548a56a-ba3c-4434-80df-cb93f4922b0e@github.com>
 <eTGpIdyXhag9boLDBdkfbIBOKs1-ffR4r3oNe6t1_50=.6384be2f-1dab-439c-afc6-cc2f31c29c89@github.com>
 <LKKEkPpQ_KV_tgXsNsx-DLAeKrfsp54xPZLOiYmMLE4=.ad387449-bcf1-4487-ab98-1b0bd81b083e@github.com>
 <hCRB6G_Pk7-LsGwA9JO8Q8vyHabedAB-8722vThIqEk=.f65aad28-5491-4a75-a64e-d642d1617d2d@github.com>
 <C-K0RQQ251pq4IwwU7iIktqUknS36HnzjzlM_NqEJ3Q=.b78142da-268a-4b7f-a25a-bd0199b54760@github.com>
 <mUN7cphJhicNNMbknjkhqSziRZkKXnZejKn6yi_5OAk=.38f2ed03-a629-4f04-baf5-967dbaa9f537@github.com>
Message-ID: <g7tQw3cdK6iz4WMOYPbNcdtAW4L4Paqqc9llwjsbrOo=.52f03d48-492a-4390-a8dc-14af6e7be879@github.com>

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

> Focus traversal is not aware of what a delegate is, nor should it be. This means that focus traversal _will_ update the delegate chain if you traverse into a node that hoists focus.

If a key event invokes the traversal machinery it will start at the focusOwner, not one of the focusOwner's delegates. There's no way for the existing traversal machinery to tab between the sub-fields of a date/time control that is the focus owner.

I've seen two methods for traversing a date/time control. In one method you use Tab to traverse to the control, through the month/day/year fields, and then beyond the control. That doesn't work well in grid-based layouts where the user expects three presses of Tab to reliably move them three columns to the right. In those designs it's not uncommon for traversal between month/day/year to move to other keys.

> At the `Node` level (where controls are not a thing yet), it is more approriate to picture focus delegation as a kind of openly visible multi-level focus.

Traversal needs to pick one node as a starting point.

The Scene needs to pick one node for processing input method requests (the IM window needs to track the caret and there can only be one).

I'm sure accessibility also has issues with multi-level focus but don't understand the platform API's well enough to go into any detail on that. I can see how JavaFX currently sets this up for ComboBoxes and am assuming it's correct. If it is I'm not sure the existing accessibility attributes are sufficient to convey focus beyond two levels. (We really need an accessibility guru to weigh in on this).

I don't think any of these issues are necessarily deep, just that they need to be hashed out.

> I'm reasonably certain that we don't need or want the delegate to be a property.

Currently you're tracking the hoisting node as an internal reference and then using it to constantly re-compute the delegate whenever you need it (going through a loop to validate the hoisting node each time). It seems you could use the hoisting node to determine the delegate while processing requestFocus and just track the delegate directly. Do you expect the delegate associated with a particular hoisting node to change over time? If not, why not just compute it once?

In any case the input method state manager needs to know if the delegate chain changes. That's still a problem that needs to be solved.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2213693019

From kcr at openjdk.org  Thu Jul 17 16:07:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Jul 2025 16:07:52 GMT
Subject: Integrated: 8362079: Change JavaFX release version to 26
In-Reply-To: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
References: <NY9GHBu_vL_dpalk9qfdbG8aywMYUpm8dvxmsl9WyMg=.7e5e4382-852b-45de-a3d5-af981171edd8@github.com>
Message-ID: <mxYQ8H_flNMVFo2lGQYsgBtBCRW4aGHtInXO_HyFkJE=.a5fab370-0f26-45e4-9b79-ad3e1161a1f7@github.com>

On Mon, 14 Jul 2025 14:18:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump the version number of JavaFX to 26. I will integrate this to master as part of forking the jfx25 stabilization branch, which is scheduled for Thursday, July 17, 2025 at 16:00 UTC.

This pull request has now been integrated.

Changeset: da6965be
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/da6965bea005bbaf0bcfd05e295bbab4ea4f5eaa
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8362079: Change JavaFX release version to 26

Reviewed-by: angorya

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

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

From kevin.rushforth at oracle.com  Thu Jul 17 16:34:37 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 17 Jul 2025 09:34:37 -0700
Subject: JavaFX 25 is in Rampdown Phase One (RDP1)
Message-ID: <e38df3a9-6004-418f-988e-4d641a914fe8@oracle.com>

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

Here is the short summary of what this means:

- The master branch of the jfx repo is available for integrating bug 
fixes or enhancements for jfx26. Almost all fixes will be integrated to 
master for 26, even those intended to be fixed in 25.

- The jfx25 branch of the jfx repo is now open for integrating fixes for 
jfx25 that meet the RDP1 criteria as outlined below. As with the 
previous release, in this release we will integrate almost all 
stabilization changes via backports from the master branch [3].

 ? * 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 [4].)

 ? * 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.

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


DETAILS:

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

As a reminder, we use a single openjdk/jfx GitHub repo with 
stabilization branches [5] rather than a separate stabilization repo. 
The jfx25 branch is used to stabilize the upcoming jfx25 release. Please 
be aware of this, especially if you are a Reviewer or Committer in the 
Project. This allows all pull requests to be in the same place, but care 
needs to be taken for any PR that is targeted to jfx25 to ensure that it 
doesn't contain any commits from master after the jfx25 fork date. What 
that means is that if you intend a PR to be for jfx25, don't merge 
master into your local source branch!

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (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 RDP1 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. 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.

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

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

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

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

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] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements

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

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

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


From angorya at openjdk.org  Thu Jul 17 16:37:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 17 Jul 2025 16:37:36 GMT
Subject: RFR: 8353599: TabPaneSkin: add 'menuGraphicFactory' property [v5]
In-Reply-To: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
References: <h5Mgvqf60lqGwjWF3jeAkpT_-PU8LYHWnHH2tjIx11I=.a4bb0835-502d-4bd1-a67c-3f31c2d010ce@github.com>
Message-ID: <QwH6ZdmOwXfXZFlpsps5HwaeaEaxlec9Vl9NYu4St9w=.f00526a5-b538-4494-9503-82c8a51a0e19@github.com>

> Tries to address the mystery of missing graphic in the TabPane overflow menu.
> 
> ### Summary of Changes
> 
> - minor `TabPaneSkin` constructor javadoc clarification
> - added the property
> - changed popup menu to be created on demand
> - removing adding the popup reference to the `TabHeaderSkin` properties (I think it was done for testing purposes, I could not find any references to it in the code)
>  
> For a quick tester, use https://bugs.openjdk.org/secure/attachment/114240/TabPaneGraphicFactoryExample.java
> 
> # Overflow Menu Graphic Property in the TabPaneSkin
> 
> Andy Goryachev
> 
> <andy.goryachev at oracle.com>
> 
> 
> ## Summary
> 
> Introduce a `menuGraphicFactory` property in the `TabPaneSkin` class eliminates the current limitation of this skin
> in supporting menu item graphics other than an `ImageView` or `Label` with an `ImageView` graphic.
> 
> 
> 
> ## Goals
> 
> The goals of this proposal are:
> 
> - to allow the application developers to customize the overflow menu items' graphic
> - retain the backward compatibility with the existing application code
> - clarify the behavior of the skin when the property is null (i.e. the current behavior)
> 
> 
> 
> ## Non-Goals
> 
> The following are not the goals of this proposal:
> 
> - disable the overflow menu
> - configure overflow menu graphic property via CSS
> - add this property to the `TabPane` control itself
> 
> 
> 
> ## Motivation
> 
> The existing `TabPaneSkin` does not allow the overflow menu to show graphic other than
> an `ImageView` or `Label` with an `ImageView`.
> 
> This limitation makes it impossible for the application developer to use other graphic Nodes,
> such as `Path` or `Canvas`, or in fact any other types.  The situation becomes even more egregious
> when the tabs in the `TabPane` have no text.
> 
> Example:
> 
> 
> public class TabPaneGraphicFactoryExample {
>     public void example() {
>         Tab tab1 = new Tab("Tab1");
>         tab1.setGraphic(createGraphic(tab1));
> 
>         Tab tab2 = new Tab("Tab2");
>         tab2.setGraphic(createGraphic(tab2));
> 
>         TabPane tabPane = new TabPane();
>         tabPane.getTabs().addAll(tab1, tab2);
> 
>         TabPaneSkin skin = new TabPaneSkin(tabPane);
>         // set overflow menu factory with the same method as was used to create the tabs
>         skin.setMenuGraphicFactory(this::createGraphic);
>         tabPane.setSkin(skin);
>     }
> 
>     // creates graphic Nodes for tabs as well as the overflow menu
>     private Node createGraphic(Tab tab) {
>         switch (tab.getText()) {
>         case "Tab1":
>             return new Circle(10);
>         case "Tab2"...

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge branch 'master' into 8353599.menu.factory
 - Merge branch 'master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - popup menu on demand
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - javadoc
 - Merge remote-tracking branch 'origin/master' into 8353599.menu.factory
 - graphic factory

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1773/files
  - new: https://git.openjdk.org/jfx/pull/1773/files/0630a575..28ec83ba

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

  Stats: 8715 lines in 108 files changed: 7051 ins; 1337 del; 327 mod
  Patch: https://git.openjdk.org/jfx/pull/1773.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1773/head:pull/1773

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

From jvos at openjdk.org  Fri Jul 18 07:26:59 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 07:26:59 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <pqemdELzvi1gs1D7rHzH5MWQTUuKgIPghah7GHVrVrs=.7db581a9-5f15-4efd-aaa6-7cfd6b0854fb@github.com>

On Fri, 27 Jun 2025 19:08:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 109:
> 
>> 107:         }
>> 108:         int modifiers = 0;
>> 109:         view.notifyMouse(mouseEvent, buttonEvent, (int)mouseX-wx, (int)mouseY-wy, (int)mouseX, (int)mouseY, modifiers, false, false);
> 
> should the coordinates be rounded instead of floor'ed (cast to int)?
> (also in other places below)

>From a logical point, I would say yes. However, if you look at the Robot implementations for e.g. GTK, there are casts to int as well. So in order to be consistent, I think we should cast to int (and floor, indeed).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2215229975

From jvos at openjdk.org  Fri Jul 18 07:32:03 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 07:32:03 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <GMLM1K5E53tSgblZtTXaOFBgb0SoNn05DMx6F4C5KgU=.2de45a19-7394-49cb-bea9-d9d8bfb2f80c@github.com>

On Fri, 27 Jun 2025 19:12:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Process reviewer comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 161:
> 
>> 159:         int repeat = Math.abs(wheelAmt);
>> 160:         for (int i = 0; i < repeat; i++) {
>> 161:             view.notifyScroll((int) mouseX, (int) mouseY, wx, wy, 0, dff, 0, 0, 0, 0, 0, multiplierX, multiplierY);
> 
> are all parameters correct?  `modifiers` and `lines`, specifically?

It is a bit complex to easily determine if those parameters have relevance at all. There are no failing tests due to this, so I see this as a good opportunity to add tests in case issues (unexpected behavior) is detected.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2215241105

From jvos at openjdk.org  Fri Jul 18 07:37:02 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 07:37:02 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
Message-ID: <3NIKtGgMH1-blsQkSIss2g6XqQC7JJDKDNgaNhgy9dI=.3226151e-5e43-46c4-8fb6-f3b755d6ed86@github.com>

On Fri, 27 Jun 2025 20:38:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Question: While the screen size is limited in this version to 1000x1000, the size of the snapshot exceeds that. Is that expected?

Good question.
Do you refer to the Node.snapshot()?
The definition of "screen size" is a bit vague on headless, also in relation to window size and view size. I think that a snapshot can in theory be bigger than the screen size, in case multiple screens are used (something we currently don't do).
I believe we can use more input from concrete use cases before we nail down constraints and boundary conditions like this.

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3087837303

From jvos at openjdk.org  Fri Jul 18 07:46:00 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 07:46:00 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v10]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <EKmS9W9k_jdimgFep1CIOYTwqjqYUBeKZTFG3lwPM-0=.389953a8-f12f-47ca-af0d-75957cc184d5@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Do not use System.getProperty() for getting configuration options for now.
  Especially, don't use properties prefixed for GTK.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/2925f42c..b3d69a17

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

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

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

From jvos at openjdk.org  Fri Jul 18 07:46:02 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 07:46:02 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
 <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
Message-ID: <wqQxw1l4EQLpGBu6XG8UhsxSwLlLwFH2Kqs9R1aNnHE=.bf4ac308-9196-45eb-b6b7-2c131d580caf@github.com>

On Mon, 14 Jul 2025 22:17:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Specify A as a double.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessApplication.java line 141:
> 
>> 139:             float scaleX = 1.f;
>> 140:             float scaleY = 1.f;
>> 141:             String scale = System.getProperty("glass.gtk.uiScale");
> 
> "gtk" ?

whoops. I took a similar approach here as the one used in GtkApplication, but it is not in line with my own suggestion to keep configuration out of this PR.
I removed this property check, as I believe configurations (via properties or not) should be discussed globally, and having one property already being used in the code, would make that discussion harder.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2215271585

From jvos at openjdk.org  Fri Jul 18 08:12:58 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 08:12:58 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <HkNPrzTAkDxJJJ8eeCzeBbg0IGgu1OPbcyhZnutve9w=.df118d6e-567e-4e59-8393-060f3641d835@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
 <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
 <6MN7eVg2rBzq_H_AORD1oE1cDI5qNitk7PWwq57kwAE=.fe893750-a6c1-4b92-a0ad-26d01878b4e8@github.com>
 <HkNPrzTAkDxJJJ8eeCzeBbg0IGgu1OPbcyhZnutve9w=.df118d6e-567e-4e59-8393-060f3641d835@github.com>
Message-ID: <75u61tu9HvD80PLV6yHcJtsclzh3SvrKO-eWvbasX9Q=.22bedbcc-03fb-4cf6-bf51-725f7761a928@github.com>

On Wed, 16 Jul 2025 01:56:21 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > > The first question is: Does this have any use case beyond testing?
> > 
> > 
> > Good question, and the answer is "Yes, absolutely". One of the main drivers for this was a project where PDF prints need to be generated server-side, starting from `Node.snapShot(... WritableImage)`.
> 
> @johanvos
> 
> Did you happen to see my proposal to use the software renderer to provide a Canvas#GraphicsContext like API for writable images? Snapshot is a nice feature, but it feels like a rather roundabout way to first use the GPU to draw things, then copy it back to main memory for pixel manipulation or say PDF creation...
> 
> See here: https://www.mail-archive.com/openjfx-dev at openjdk.org/msg20618.html
> 
> I'm curious what you think of the proposal (and I'm curious if the headless platform would need to support it or interfere with it :))

I see the benefits from your proposal, and I believe it makes sense. I don't think it interferes with the headless platform, since it is more in the prism-side of things, but there is always some overlap. The Robot.getScreenCapture() is one of those methods where the implementation would depend on it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3088260398

From jvos at openjdk.org  Fri Jul 18 08:31:55 2025
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Jul 2025 08:31:55 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v9]
In-Reply-To: <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <-WVj1n0fOrCsc9sZ4fEH95aBojAQbILG_NUW8Gn191w=.ba8145ee-61e6-4dde-a440-f05a2fb41411@github.com>
 <QK1XDIgUiHVmrPhMqKVk0dwFZp_1qz4VU0nbtNyNaWA=.6964e1ce-b0a5-478e-a19f-6d5b317a8709@github.com>
Message-ID: <Bcfsng-hNJCcQ7Qi5RP5VMBnchlSU-cgRsl64FTQCLo=.5117a4dc-6379-4293-95bf-775ba4cd1991@github.com>

On Tue, 15 Jul 2025 01:11:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Even if this remains a testing feature, how should it eventually be configured? Using system properties? Some sort of config file? Something else?

This was discussed in a number of comments as well, and the suggested approach is to leave configuration for follow-up PR's. There are a number of options (e.g. system properties, but also an API), and some of them would require a CSR and/or more formal work. Getting more input from usecases would be helpful here.

> How should this interact with the AWT headless toolkit? Or does it?

There is no interaction yet. I believe there might be value in more direct interactions with AWT though, e.g. with the AWT Print API.
 
> This requires the prism SW pipeline. How / where should be document this restriction?

Surprisingly (or not), most of the tests I've ran (e.g. the OpenJFX system tests) do not require the prism SW pipeline. But tests where one wants to check what pixels are rendered on screen require prism SW indeed. 
It's a good question where this needs to be documented. Since there is no new API, it can't be in the new API docs. One of the options is to add it in a property overview document, e.g. like the one from Abhinay at https://github.com/abhinayagarwal/abhinayagarwal.github.io/blob/master/_posts/2022-10-03-OpenJFX%20flags.markdown . Since the headless platform is enabled by setting a System Property, it could be useful to add the associated options along that system property.

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3088443171

From arapte at openjdk.org  Fri Jul 18 18:05:33 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 18 Jul 2025 18:05:33 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v9]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <i6aHENPe7G8VOkAzfPg5LLfo97jkPzQG6JZ2WyDZ_Q0=.dcc81349-fdba-4456-bc77-9c25eec79195@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:

  andy review comments 1

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/fe40d04d..b9b35608

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

  Stats: 283 lines in 11 files changed: 89 ins; 88 del; 106 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 Jul 18 18:05:48 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 18 Jul 2025 18:05:48 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@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>
Message-ID: <Vs7Rv060zAP3P_-CDEhUvlwq6DpaMP2lExevyJu3WvA=.f2bdfd8b-665c-4122-814e-fea591b4d22d@github.com>

On Wed, 16 Jul 2025 19:02:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> first batch of comments (java), mostly questions and minor suggestions. will review the native code next.

Thanks for the review Andy...
I addressed most of the comments, but a few which are existing code for es2 pipeline and metal code that is kept similar to es2,d3d pipeline for similarity, even though the code may not be no-op
A few comments needs to be addressed, I shall update soon.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 334:
> 
>> 332: 
>> 333:             try {
>> 334:                 FileWriter fragmentShaderHeaderFile = new FileWriter(headerFilesDir + FRAGMENT_SHADER_HEADER_FILE_NAME);
> 
> This writer is not buffered, meaning it will be too slow.
> I'd say either to wrap it into `BufferedWriter`, or better yet - use `StringBuilder`s everywhere and write the single generated string in one operation.

After a change for addressing a review comment, now it mostly uses StringBuilders except a few String objects.
MSLBackend overall consumes just a few seconds when clean/new build is done.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 336:
> 
>> 334:                 FileWriter fragmentShaderHeaderFile = new FileWriter(headerFilesDir + FRAGMENT_SHADER_HEADER_FILE_NAME);
>> 335:                 fragmentShaderHeaderFile.write(fragmentShaderHeader.toString());
>> 336:                 fragmentShaderHeaderFile.write("#endif\n");
> 
> this line is weird - why is it here and not after L331?

Yes, it should have been after L331,  It is now moved.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 337:
> 
>> 335:                 fragmentShaderHeaderFile.write(fragmentShaderHeader.toString());
>> 336:                 fragmentShaderHeaderFile.write("#endif\n");
>> 337:                 fragmentShaderHeaderFile.close();
> 
> an exception on lines 335-336 will cause the writer not being closed. 
> can we use try-with-resources?

Changed to use try-with-resources.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 346:
> 
>> 344: 
>> 345:         try {
>> 346:             FileWriter objCHeaderFile = new FileWriter(headerFilesDir + objCHeaderFileName);
> 
> same issue here, need to close the writer properly.

Changed to use try-with-resources.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 423:
> 
>> 421: 
>> 422:             objCHeaderFile.write("    return nil;\n");
>> 423:             objCHeaderFile.write("};\n\n");
> 
> Not sure if it's worth doing, but perhaps this code can use a single StringBuilder to build the code, then use `Files.writeString()` to write it (this might require a bit of refactoring).

Changed this particular block to use StringBuilder.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 444:
> 
>> 442:         }
>> 443: 
>> 444:         uniformsForShaderFile = uniformsForShaderFile.replace(" float2", " vector_float2");
> 
> feels like this code was written in 1997.  Use a StringBuilder perhaps?

StringBuilder does not offer a method to replace all occurrences of a particular string. We will have to use combination of indexOf() and replace() to replace each occurrence individually. It seems like an overkill, given the MSLBackend is run at build time to generate shaders that consumes a few seconds when clean/new build is done.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 159:
> 
>> 157:     @Override
>> 158:     protected State updateRenderTarget(RenderTarget target, NGCamera camera, boolean depthTest) {
>> 159:         MTLLog.Debug("MTLContext.updateRenderTarget() :target = " + target + ", camera = " + camera + ", depthTest = " + depthTest);
> 
> general question: is this temporary?  can we use maybe a better logging mechanism, one that does not concatenate strings when disabled?  works case, surround this by `if(debug)` ?

Yes, this is temporary, Kept these for easy analysis if any issues are observed. Eventually in follow ons we shall remove it.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 172:
> 
>> 170: 
>> 171:         // Validate the camera before getting its computed data
>> 172:         if (camera instanceof NGDefaultCamera) {
> 
> suggestion: `if (camera instanceof NGDefaultCamera nc)` to avoid explicit cast in L173

Changed as suggested.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 180:
> 
>> 178:             double vw = camera.getViewWidth();
>> 179:             double vh = camera.getViewHeight();
>> 180:             if (targetWidth != vw || targetHeight != vh) {
> 
> would it make sense to detect the case when target(w/h) is very close to (w/h) and skip scaling?  or is this scenario unlikely?

This is similar to other pipelines, and a different behavior here may cause visual differences. It would be safe to follow existing impl.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 339:
> 
>> 337: 
>> 338:     public long getMetalCommandQueue()
>> 339:     {
> 
> I like this style, but the rest of the file uses K&R braces...

Corrected the formatting.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 350:
> 
>> 348:         // if (checkDisposed()) return;
>> 349:         // nSetDeviceParametersFor2D(pContext);
>> 350:     }
> 
> remove the commented out code LL348-349, leave the comment?

Removed the two lines keeping comment.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 357:
> 
>> 355:         // result of this call, hence the method is no-op.
>> 356:         // But overriding the method here for any future reference.
>> 357:         // if (checkDisposed()) return;
> 
> same here?

Removed the two lines keeping comment.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 489:
> 
>> 487:     }
>> 488: 
>> 489:     private void printRawMatrix(String mesg) {
> 
> unused method?

The calls to this method are commented out. It would be handy to have the matrix printing mechanism handy in case of debugging, similarly it is present in other pipelines.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 60:
> 
>> 58:     @Override
>> 59:     public void dispose() {
>> 60:         disposerRecord.dispose();
> 
> two questions here:
> 1. why is `disposerRecord.dispose()`; here (and in `D3DMesh`, `ES2Mesh`) and not in the `BaseGraphicResource` ?
> 2. any danger in the `dispose()` being called twice?  (could it happen at all?)

1. BaseGraphicResource is inherited by other resource classes like Shader and Texture too. It seems good idea to implement dispose() all in child classes as needed.
2. Calling twice is never observed in renderperf tests with large number of objects, and seems not possible, but deep analysis for these things can be done only with stress based scenarios. 

As these are similar to other pipelines, It can be common analysis for future keeping it out of scope for this PR.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 93:
> 
>> 91:         }
>> 92: 
>> 93:         void traceDispose() {}
> 
> what's the purpose of this method?

It seems it's purpose was to track allocation and deallocation of resources. But the method is empty in most classes except ES2TextureData.java. Instead of removing this needs better handling by improving PrismTrace class and giving a definition to these empty traceDispose() methods.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 104:
> 
>> 102:                 String logname = PhongMaterial.class.getName();
>> 103:                 PlatformLogger.getLogger(logname).warning(
>> 104:                         "Warning: Low on texture resources. Cannot create texture.");
> 
> I suppose this message is the same as elsewhere.  Is it clear enough for the user?  Does the user have a clear idea of how to correct the issue?

Yes, it is same for other pipelines too. It looks more developer friendly, but it does offer basic insight.

> 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:             HashMap devDetails = (HashMap) MTLPipeline.getInstance().getDeviceDetails();
> 
> cast is unnecessary.  suggestion: 
> `Map devDetails = MTLPipeline.getInstance().getDeviceDetails();`
> 
> I guess we've inherited the API based on the raw object here?

Removed the cast by using above suggestion.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTextureData.java line 35:
> 
>> 33:     @Override
>> 34:     public void dispose() {
>> 35:         if (pTexture != 0L) {
> 
> this code is weird: why doesn't call super.dispose()?

Changed to call super.dispose()

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 75:
> 
>> 73:             i *= 2;
>> 74:         }
>> 75:         return i;
> 
> interesting...  would `1 << val` be simpler (barring overflow)?

Changed accordingly and included another check to verify if the `val` is already a power of two.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 128:
> 
>> 126:             return (Shader) m.invoke(null, new Object[]{this, shaderName, nameStream});
>> 127:         } catch (Throwable e) {
>> 128:             e.printStackTrace();
> 
> do we want to use a logger or the `stderr` is the best decision in this case?

There is no use of Logger in the prism rendering pipeline implementation. Perhaps we should change all stderr to Logger but outside of this PR.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 183:
> 
>> 181: 
>> 182:         long pResource = nCreateTexture(context.getContextHandle() ,
>> 183:                 (int) formatHint.ordinal(), (int) usageHint.ordinal(),
> 
> unnecessary casts to (int) x2

Removed the cast

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 274:
> 
>> 272:         Texture tex = createTexture(texFormat, Usage.DEFAULT, WrapMode.CLAMP_TO_EDGE, texWidth, texHeight);
>> 273: 
>> 274:         frame.releaseFrame();
> 
> could all these `frame.releaseFrame()` be moved to a `finally` block?

Added a finally block.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 305:
> 
>> 303:     @Override
>> 304:     public int getRTTWidth(int w, Texture.WrapMode wrapMode) {
>> 305:         // Below debugging logic replicates D3DResoureFactory
> 
> is this code still needed?  also L314

There is more detailed description in D3DResouceFactory. This comment here would serve as good redirection if one is looking into it. Let's keep it.

> 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.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 128:
> 
>> 126: 
>> 127:         if (pState.getNativeFrameBuffer() == 0) {
>> 128:             System.err.println("Native backbuffer texture from Glass is nil.");
> 
> is `stderr` ok here?

There is no use of Logger in the prism rendering pipeline implementation. Perhaps we should change all stderr to Logger but outside of this PR.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 143:
> 
>> 141:                 stableBackbuffer = null;
>> 142:             } /*else {
>> 143:                 // RT-27554
> 
> is this still relevant?

It is not relevant to metal, removed.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 97:
> 
>> 95:                         int srcscan, boolean skipFlush) {
>> 96: 
>> 97:         if (format.getDataType() == PixelFormat.DataType.INT) {
> 
> would a `switch` be better here?

Agreed, changed to switch.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTexture.java line 122:
> 
>> 120:             byte[] arr = buf.hasArray() ? buf.array() : null;
>> 121: 
>> 122:             if (format == PixelFormat.BYTE_BGRA_PRE || format == PixelFormat.BYTE_ALPHA) {
> 
> also here, `switch` ?

Agreed, changed to switch.

> modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.h line 45:
> 
>> 43:     GLuint              _textureWidth;
>> 44:     GLuint              _textureHeight;
>> 45:     NSView* glassView;
> 
> minor: we probably should not try to align, but simply use a single space char, as in java code.

I prefer a few spaces if they make code look easy on eyes, here the spaces are a little more, but this is a pre-existing code for es2 pipeline, In this PR it is only moved to a new file. GlassOffscreen.m to Glass**CGL**Offscreen.m

> modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.m line 48:
> 
>> 46:             {
>> 47:                 // TODO: implement PBuffer if needed
>> 48:                 // self->_fbo = [[GlassPBuffer alloc] init];
> 
> commented out - is it going to crash of the value is `nil`?

This is a pre-existing code for es2 pipeline, In this PR it is only moved to a new file. GlassOffscreen.m to Glass**CGL**Offscreen.m

> modules/javafx.graphics/src/main/native-glass/mac/GlassCGLOffscreen.m line 143:
> 
>> 141:                                                                             withObject:nil
>> 142:                                                                          waitUntilDone:NO
>> 143:                                                                                  modes:allModes];
> 
> minor: this indentation is hard to look at

Changed the indentation.

> modules/javafx.graphics/src/main/native-glass/mac/GlassMTLOffscreen.m line 68:
> 
>> 66:     [(NSObject*)self->_fbo release];
>> 67:     self->_fbo = nil;
>> 68:     [super dealloc];
> 
> here and elsewhere: should we protect against repeated calls to dealloc?  like `if(self->_fbo != nil)`

Updated the code with null check.

> modules/javafx.graphics/src/main/native-prism-mtl/MetalPipelineManager.m line 32:
> 
>> 30: // ---------------------------- Debug helper for Developers -------------------------
>> 31: //
>> 32: // This implementation is to utilize "Metal Debuger" present in Xcode.
> 
> is the debugger available in production code?

It is available to developers only. It requires two things
Un-comment line 51: //#define JFX_MTL_DEBUG_CAPTURE
and enable metal debug trace capturing, on terminal, export MTL_CAPTURE_ENABLED=1

> modules/javafx.graphics/src/main/native-prism-mtl/MetalRingBuffer.m line 34:
> 
>> 32: static unsigned int currentBufferIndex;
>> 33: 
>> 34: - (MetalRingBuffer*) init:(MetalContext*)ctx
> 
> ring buffers are a frequent source of off-by-one bugs.
> is it possible to have a unit test for it?

It would require test specific helper methods to add the tests. I think it should be out of this PR as a followup.

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

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3090250301
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602426
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602524
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602217
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602288
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602618
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602696
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216602902
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603131
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603253
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603339
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603454
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603564
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216603729
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216604023
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216604132
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216604269
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216604415
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216604868
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605130
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605310
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605420
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605635
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605806
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216605941
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216606136
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216606220
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216606435
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216606559
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216606903
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216607159
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216607254
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216607473
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216607630
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2216611680

From arapte at openjdk.org  Fri Jul 18 18:05:49 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 18 Jul 2025 18:05:49 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
 <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
Message-ID: <yCikDFdVda_pUpvVFSp5hP1ZZ04Z0_97XdbVjl7A2sE=.20295f6a-b2d4-4db0-b0eb-a2679e005cc7@github.com>

On Wed, 16 Jul 2025 19:44:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 57:
>> 
>>> 55:             shaderMap.put(fragmentFunctionName, this);
>>> 56:         } else {
>>> 57:             throw new AssertionError("Failed to create Shader");
>> 
>> is `AssertionError` the right type here?
>
> Good catch. I think this should throw a `RuntimeException` of some sort.

We throw an InternalError from MTLResourceFactory.createStockShader() if shader creation fails. For matching changed here to use InternalError. If not Ok, then I shall change it. please check.

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

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

From angorya at openjdk.org  Fri Jul 18 18:10:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Jul 2025 18:10:53 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: <LOkjJIF5Knh_-cVRkVnUoCtcRz7XGBF7yCjXrEQWeHI=.115f62cc-44ff-4ed4-b259-2c969ad164d6@github.com>

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

>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 75:
>> 
>>> 73:             i *= 2;
>>> 74:         }
>>> 75:         return i;
>> 
>> interesting...  would `1 << val` be simpler (barring overflow)?
>
> Changed accordingly and included another check to verify if the `val` is already a power of two.

This code (in my experience) is easy to get wrong.
Could we add some tests, to verify that
- values within the allowed range (small and large) work as expected
- values outside of the allowed range fail as expected
- power of 2 values are returned unchanged

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

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

From angorya at openjdk.org  Fri Jul 18 18:18:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Jul 2025 18:18:52 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <LOkjJIF5Knh_-cVRkVnUoCtcRz7XGBF7yCjXrEQWeHI=.115f62cc-44ff-4ed4-b259-2c969ad164d6@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>
 <LOkjJIF5Knh_-cVRkVnUoCtcRz7XGBF7yCjXrEQWeHI=.115f62cc-44ff-4ed4-b259-2c969ad164d6@github.com>
Message-ID: <LdHU-KGCAzorIohfgxyIBZzDJYB1VfNusPt9_9NRkWQ=.b21361d0-32f8-4a71-a955-b418bd567c69@github.com>

On Fri, 18 Jul 2025 18:08:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed accordingly and included another check to verify if the `val` is already a power of two.
>
> This code (in my experience) is easy to get wrong.
> Could we add some tests, to verify that
> - values within the allowed range (small and large) work as expected
> - values outside of the allowed range fail as expected
> - power of 2 values are returned unchanged

also, there might be an alternative without a loop:

int v = Integer.highestOneBit(value);
if(v == value) {
  return value;
}
return v << 1;

I don't know how frequent this operation is, but the loop makes me sad.

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

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

From angorya at openjdk.org  Fri Jul 18 19:29:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 18 Jul 2025 19:29:47 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <3NIKtGgMH1-blsQkSIss2g6XqQC7JJDKDNgaNhgy9dI=.3226151e-5e43-46c4-8fb6-f3b755d6ed86@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
 <3NIKtGgMH1-blsQkSIss2g6XqQC7JJDKDNgaNhgy9dI=.3226151e-5e43-46c4-8fb6-f3b755d6ed86@github.com>
Message-ID: <bxUibGGkV0OhkDI02ByzEvdwzEdFnyG6V4I3AFVdukc=.df8dead3-34c6-4bb7-8e43-97b4267480b8@github.com>

On Fri, 18 Jul 2025 07:34:01 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Do you refer to the Node.snapshot()?

In my case, it was Scene::snapshot(), but basically the question is where the screen size has any effect?  Robot?  

It does not seem to impact Scene::snapshot.

(I've used the standalone Monkey Tester with an auto snapshot added, see https://github.com/andy-goryachev-oracle/MonkeyTest/tree/headless )

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3090503734

From kcr at openjdk.org  Fri Jul 18 20:06:51 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Jul 2025 20:06:51 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <yCikDFdVda_pUpvVFSp5hP1ZZ04Z0_97XdbVjl7A2sE=.20295f6a-b2d4-4db0-b0eb-a2679e005cc7@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
 <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
 <yCikDFdVda_pUpvVFSp5hP1ZZ04Z0_97XdbVjl7A2sE=.20295f6a-b2d4-4db0-b0eb-a2679e005cc7@github.com>
Message-ID: <dsJ5ykI3de6czpoKEau9PnXu8g6YAhqaASwSMqiybyA=.8ba14a4b-bf9f-4cac-81b4-7f65124eb959@github.com>

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

>> Good catch. I think this should throw a `RuntimeException` of some sort.
>
> We throw an InternalError from MTLResourceFactory.createStockShader() if shader creation fails. For matching changed here to use InternalError. If not Ok, then I shall change it. please check.

`InternalError` is fine. I was going to suggest that as another alternative (we often use that for errors that should never happen and aren't a result of something the app did).

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

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

From duke at openjdk.org  Sat Jul 19 00:46:50 2025
From: duke at openjdk.org (Xavier Pedraza)
Date: Sat, 19 Jul 2025 00:46:50 GMT
Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for
 texture [v2]
In-Reply-To: <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
References: <Z1gOM7AKvXnI3HkLMv1PaR-meTg7P2o0dm3GHlj7U2Q=.b69acc8e-acee-406b-8537-5c1eeadaf7c5@github.com>
 <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
Message-ID: <T_drpv9OYSkAmaAnBFRwlnHE5QoqrqH2nTSq1XxnjuU=.6f3581ba-cacc-4299-b132-27847f687fda@github.com>

On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API.
>> 
>> Summary of the changes:
>> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later.
>> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty<TextureData>` properties.
>> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily.
>> 
>> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

Paying a visit here after writing [this SO answer](https://stackoverflow.com/a/79706844/10808904), any reason this PR died? Appreciate any and all responses.

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

PR Comment: https://git.openjdk.org/jfx/pull/1281#issuecomment-3091310577

From nlisker at openjdk.org  Sat Jul 19 01:10:49 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 19 Jul 2025 01:10:49 GMT
Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for
 texture [v2]
In-Reply-To: <T_drpv9OYSkAmaAnBFRwlnHE5QoqrqH2nTSq1XxnjuU=.6f3581ba-cacc-4299-b132-27847f687fda@github.com>
References: <Z1gOM7AKvXnI3HkLMv1PaR-meTg7P2o0dm3GHlj7U2Q=.b69acc8e-acee-406b-8537-5c1eeadaf7c5@github.com>
 <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
 <T_drpv9OYSkAmaAnBFRwlnHE5QoqrqH2nTSq1XxnjuU=.6f3581ba-cacc-4299-b132-27847f687fda@github.com>
Message-ID: <tyV0Hzl6AGx2B5S1LnLdvQSx44yPAg8q_CRBHX8xqjc=.cb1278b4-f416-4b5f-9e5f-d248bd4f55e1@github.com>

On Sat, 19 Jul 2025 00:34:46 GMT, Xavier Pedraza <duke at openjdk.org> wrote:

> Paying a visit here after writing [this SO answer](https://stackoverflow.com/a/79706844/10808904), any reason this PR died? Appreciate any and all responses.

The PR is not really dead, it's hibernating :) The reason is that there's more research that needs to go into this. Initially, the texture data was only for the sampler state, but then it expanded to the render state, and it's not clear if this is correct and how inclusive this interface should be.

Add to it that Metal and D3D12 are in the works and we need to make sure JavaFX's abstraction fits those as well (and it's not clear now that it needs to fit D3D9). Writing an abstraction API over 4 or 5 different pipelines is something that takes a lot of consideration.

Note also that this PR is just for the implementation, and doesn't include exposing the API, which is planned for a followup PR.

If you'd like to help, you can research the sampler states and render states (and whatever else might fit) that the pipelines support and see if it makes sense to bundle all of them into a "texture parameters" type.

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

PR Comment: https://git.openjdk.org/jfx/pull/1281#issuecomment-3091342446

From credmond at certak.com  Sat Jul 19 10:11:33 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 19 Jul 2025 11:11:33 +0100
Subject: Bug: ToolBar always using overflow menu whenever a scaled resolution
 set
Message-ID: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>

Hi,

There's a bug whenever using a ToolBar on Windows if you set your
resolution scale > 100% (which is quite common). E.g., 125%:

[image: image.png]

E.g., this is what a ToolBar always renders if scale is 125%:

[image: image.png]

As compared to what you'd expect (scale set to normal/100%):

[image: image.png]

Very easy to reproduce the above, set your scale to 125% and run this:

public class ToolbarBugApp extends Application {

    @Override
    public void start(Stage primaryStage) {
        BorderPane bp = new BorderPane();
        // Wrapping in HBox and using button with 13+ chars causes bug
        bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); //
BUG
        // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
(no HBox)
        // bp.setTop(new HBox(new ToolBar(new Button("Create Schem")))); //
NO BUG (12 chars)
        primaryStage.setScene(new Scene(bp, 600, 400));
        primaryStage.show();
    }

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

As per the comments, this bug appears to happen when your ToolBar is
wrapped in a HBox and contains a Button that has 13+ characters, for
example. This is quite a serious bug, in my opinion.

I believe this is present in JFX 24 and the JFX 25 master branch.


Kind Regards,

*Cormac Redmond*
Software Engineer, Certak Ltd.

e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/bb916437/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/bb916437/image-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/bb916437/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/bb916437/image-0005.png>

From duke at openjdk.org  Sat Jul 19 14:27:53 2025
From: duke at openjdk.org (Glavo)
Date: Sat, 19 Jul 2025 14:27:53 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <bhPggl-nwR1WtsVLTEGlx-Nln7Y-kqY4itbWjS2UMj0=.96b454fd-d002-476b-8e4f-5b0e24616d87@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

Do you plan to fix this issue before the release of OpenJFX25? I'm wondering if I need to use a workaround to get around it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3092378414

From credmond at certak.com  Sat Jul 19 17:33:14 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 19 Jul 2025 18:33:14 +0100
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
Message-ID: <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>

Confusingly, make the string longer, such as "Create Schema 123 123 123":

        bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123
123"))));

...and the overflow doesn't appear (but still, anything between and
including 13-24, it does):

[image: image.png]




Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com> wrote:

> Hi,
>
> There's a bug whenever using a ToolBar on Windows if you set your
> resolution scale > 100% (which is quite common). E.g., 125%:
>
> [image: image.png]
>
> E.g., this is what a ToolBar always renders if scale is 125%:
>
> [image: image.png]
>
> As compared to what you'd expect (scale set to normal/100%):
>
> [image: image.png]
>
> Very easy to reproduce the above, set your scale to 125% and run this:
>
> public class ToolbarBugApp extends Application {
>
>     @Override
>     public void start(Stage primaryStage) {
>         BorderPane bp = new BorderPane();
>         // Wrapping in HBox and using button with 13+ chars causes bug
>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); //
> BUG
>         // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
> (no HBox)
>         // bp.setTop(new HBox(new ToolBar(new Button("Create Schem"))));
> // NO BUG (12 chars)
>         primaryStage.setScene(new Scene(bp, 600, 400));
>         primaryStage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(args);
>     }
> }
>
> As per the comments, this bug appears to happen when your ToolBar is
> wrapped in a HBox and contains a Button that has 13+ characters, for
> example. This is quite a serious bug, in my opinion.
>
> I believe this is present in JFX 24 and the JFX 25 master branch.
>
>
> Kind Regards,
>
> *Cormac Redmond*
> Software Engineer, Certak Ltd.
>
> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/ab5c6a4e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/ab5c6a4e/image-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/ab5c6a4e/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/ab5c6a4e/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/ab5c6a4e/image-0007.png>

From credmond at certak.com  Sat Jul 19 18:01:19 2025
From: credmond at certak.com (Cormac Redmond)
Date: Sat, 19 Jul 2025 19:01:19 +0100
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
Message-ID: <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>

Hi,

I've traced the bug down to a rounding error. See the below screenshot in
ToolBarSkin's getOverflowNodeIndex(double length).

These two numbers are not equal, but should be. snapSizeX() ultimately ends
up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1 (i.e., no
scaling), we don't see this issue. If it's 1.25, we see this
rounding difference between the two numbers in this instance. If these two
numbers are not equal, the calling code mistakenly assumes the overflow box
is necessary.

[image: image.png]

Can someone fix this?



Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com> wrote:

> Confusingly, make the string longer, such as "Create Schema 123 123 123":
>
>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123
> 123"))));
>
> ...and the overflow doesn't appear (but still, anything between and
> including 13-24, it does):
>
> [image: image.png]
>
>
>
>
> Kind Regards,
> Cormac
>
> On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com> wrote:
>
>> Hi,
>>
>> There's a bug whenever using a ToolBar on Windows if you set your
>> resolution scale > 100% (which is quite common). E.g., 125%:
>>
>> [image: image.png]
>>
>> E.g., this is what a ToolBar always renders if scale is 125%:
>>
>> [image: image.png]
>>
>> As compared to what you'd expect (scale set to normal/100%):
>>
>> [image: image.png]
>>
>> Very easy to reproduce the above, set your scale to 125% and run this:
>>
>> public class ToolbarBugApp extends Application {
>>
>>     @Override
>>     public void start(Stage primaryStage) {
>>         BorderPane bp = new BorderPane();
>>         // Wrapping in HBox and using button with 13+ chars causes bug
>>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); //
>> BUG
>>         // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
>> (no HBox)
>>         // bp.setTop(new HBox(new ToolBar(new Button("Create Schem"))));
>> // NO BUG (12 chars)
>>         primaryStage.setScene(new Scene(bp, 600, 400));
>>         primaryStage.show();
>>     }
>>
>>     public static void main(String[] args) {
>>         launch(args);
>>     }
>> }
>>
>> As per the comments, this bug appears to happen when your ToolBar is
>> wrapped in a HBox and contains a Button that has 13+ characters, for
>> example. This is quite a serious bug, in my opinion.
>>
>> I believe this is present in JFX 24 and the JFX 25 master branch.
>>
>>
>> Kind Regards,
>>
>> *Cormac Redmond*
>> Software Engineer, Certak Ltd.
>>
>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250719/4343592e/image-0009.png>

From duke at openjdk.org  Sat Jul 19 18:43:49 2025
From: duke at openjdk.org (Xavier Pedraza)
Date: Sat, 19 Jul 2025 18:43:49 GMT
Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for
 texture [v2]
In-Reply-To: <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
References: <Z1gOM7AKvXnI3HkLMv1PaR-meTg7P2o0dm3GHlj7U2Q=.b69acc8e-acee-406b-8537-5c1eeadaf7c5@github.com>
 <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
Message-ID: <CAXjIvuNKwTvTBDEpLRmaMVkxlufBU6cnRHZsRaHf7I=.29354dce-5df6-4d51-997a-cc75ee57a502@github.com>

On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API.
>> 
>> Summary of the changes:
>> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later.
>> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty<TextureData>` properties.
>> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily.
>> 
>> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

The sampler option structures for [OpenGL](https://www.khronos.org/opengl/wiki/Sampler_Object#Sampling_parameters), [D3D9](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dsamplerstatetype), [D3D12](https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_sampler_desc) and [Metal](https://developer.apple.com/documentation/metal/mtlsamplerdescriptor) seem fairly congruent, albeit mangled. I agree that writing a comprehensive abstraction for even these few backends remains challenging. It's also not clear whether the [D3D12 filter type](https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_filter) is some kind of bitmask and how precisely it relates to the [D3D9 filter type](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dtexturefiltertype), especially where mips are concerned. I'm also not sure whether information about sampler objects in OpenGL 3.3 is applicable to OpenGL ES 2.0.

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

PR Comment: https://git.openjdk.org/jfx/pull/1281#issuecomment-3092506961

From zjx001202 at gmail.com  Sun Jul 20 18:29:47 2025
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 21 Jul 2025 02:29:47 +0800
Subject: Some feature requests/improvement suggestions for the JavaFX Font API
Message-ID: <CAJL5A3mM7A_nJTPzduzZoqiPgAaQMLcOrY_zWOj+y-pmqWXnpg@mail.gmail.com>

Hi,

We noticed that the Font API had many bugs and inconsistencies, and was
missing a lot of functionality.
Unfortunately, I don't have enough knowledge in this field to solve them.
So I'm making some feature requests/improvement suggestions on this to see
if anyone is interested.

1. Unify the meaning of "font family".

Currently "font family" has different meanings on different platforms:

   - On Windows, it usually means the localized name of the font family
   name (nameID=1);
   - On Linux,  it usually means the non-localized font family name
   (nameID=1, langID=0x0);
   - On macOS,  it usually means the non-localized typographical family
   name (nameID=16, langID=0x0).

This inconsistency makes the behavior of the program confusing and it is
impossible to know what will happen without testing on multiple platforms.

I want JavaFX to use the non-localized typographical family name
(nameID=16, langID=0x0) on all platforms.
The reason is that the font family name (nameID=1) of many fonts actually
contains the font style information,
and using it makes it difficult for us to select font style.

For example, if we want to get JetBrains Mono Bold on Windows, we need to
use Font.font("JetBrains Mono", FontWeight.BOLD, 13),
but to get JetBrains Mono ExtraBold, we need to use Font.font("JetBrains
Mono ExtraBold", FontWeight.NORMAL, 13).
This is really frustrating :(

Additionally, I encountered a bug on macOS that prevented me from selecting
the font weight.
I explained this issue in a previous email:
https://mail.openjdk.org/pipermail/openjfx-dev/2025-July/055417.html

2. Make Font.font(String) accept both font name and font family name.

I wish Font.font(String) could accept more names than just the font family
name.

As mentioned in the previous section, the current concept of font family
names in JavaFX is confusing and often contains font style information.
Therefore, it is very difficult to use the Font.font(String) in the correct
way.
If it would accept a variety of font names, both localized and
non-localized, it would be less difficult to use.

3. Add more methods to get font localized names

I would like to get these methods in Font class to get the localized name
of the font:

   - static Map<Locale, String> getLocalizedFamilyNames(String family)
   - static String getLocalizedFamilyName(String family, Locale locale)
   - static String getLocalizedFontNames(Locale locale)
   - static String getLocalizedFontNames(String family, Locale locale)
   - Map<Locale, String> getLocalizedNames()
   - String getLocalizedName(Locale locale)
   - Map<Locale, String> getLocalizedFamily()
   - String getLocalizedFamily(Locale locale)

4. More methods for handling font styles

Right now we can only use FontWeight and FontPosture to select a font style
when looking up a font,
but the only way to get the style from a given Font object is
Font::getStyle(), which is very asymmetrical.

I would like to get these methods to handle font styles:

   - static List<String> getStyles(String family)
   - static Font font(String family, String style)
   - FontWeight getWeight()
   - FontPosture getPosture()

5. Support fallback fonts and CSS font list for UI controls
6. Provides a way to control the typographic features of fonts
      Refer to Flutter's FontFeature class:
https://api.flutter.dev/flutter/dart-ui/FontFeature-class.html

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250721/d98d7ccc/attachment.htm>

From kcr at openjdk.org  Mon Jul 21 16:54:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 16:54:00 GMT
Subject: [jfx25u] RFR: 8362896: Change JavaFX release version to 25.0.1 in
 jfx25u
Message-ID: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>

Updates for the beginning of the 25.0.1 release.

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

Commit messages:
 - 8362896: Change JavaFX release version to 25.0.1 in jfx25u

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

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

From angorya at openjdk.org  Mon Jul 21 17:06:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 21 Jul 2025 17:06:37 GMT
Subject: [jfx25u] RFR: 8362896: Change JavaFX release version to 25.0.1 in
 jfx25u
In-Reply-To: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
References: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
Message-ID: <GpMmcj3whKvUWxKEDmPacfL6lQSkW7j5kSwvn3-8gzM=.c79bc006-4692-402a-b0a6-8daf5fb5a752@github.com>

On Mon, 21 Jul 2025 16:46:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 25.0.1 release.

the branches look correct.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx25u/pull/1#pullrequestreview-3038975245

From kcr at openjdk.org  Mon Jul 21 17:20:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 17:20:42 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <N5lQKKUrDwZup8K9Bj5YogBFQQeAuqK9riyPtkKuS3k=.7a14f047-6cc2-4b6c-8831-5f0a38f1d916@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

There first needs to be a new bug filed. Once there is, and a fix is available, we can see how risky the fix will be and decide  whether to backport it to jfx25.

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3097656100

From kcr at openjdk.org  Mon Jul 21 17:41:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 17:41:45 GMT
Subject: [jfx25u] RFR: 8362896: Change JavaFX release version to 25.0.1 in
 jfx25u
In-Reply-To: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
References: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
Message-ID: <1jRAhum14bVPHKDiUCtE03uBLaWZjrOZTp-GOaOHDXg=.4fe419e9-cd0b-4484-b569-183401724592@github.com>

On Mon, 21 Jul 2025 16:46:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 25.0.1 release.

@johanvos Can you do the maintainer approval when you get a chance?

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

PR Comment: https://git.openjdk.org/jfx25u/pull/1#issuecomment-3097719978

From lkostyra at openjdk.org  Mon Jul 21 18:05:43 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 21 Jul 2025 18:05:43 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v48]
In-Reply-To: <33_Bb6F66GjY4S-NFs9KGXGVo2rRSPth4Q7q3Tu50_0=.113a957e-6c09-4e3d-94fa-ce168af2e7e3@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <aICBD_mIFz1vXUX5PcMeeBnt249MPCbDkg0cx5q4ocw=.e2de4009-ed23-4101-b12f-f4d6bd972258@github.com>
 <33_Bb6F66GjY4S-NFs9KGXGVo2rRSPth4Q7q3Tu50_0=.113a957e-6c09-4e3d-94fa-ce168af2e7e3@github.com>
Message-ID: <cRU90CuNty8sAX9nJxxxXr3fTMdMlyo80Mf3C2xrP-k=.cc389e4c-24c8-46d4-9a34-e08097fcf9d7@github.com>

On Sun, 29 Jun 2025 11:58:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused const
>
> I have updated the main explanation of the changes. I also ran extensive tests on XWayland, Xorg, KDE, GNOME, and across different OS versions and distributions.

@tsayao is this PR ready for review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3097870504

From kcr at openjdk.org  Mon Jul 21 18:37:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 18:37:37 GMT
Subject: [jfx25u] Integrated: 8362896: Change JavaFX release version to 25.0.1
 in jfx25u
In-Reply-To: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
References: <xRwLD_cCInYjwt900JxSEgGjuqQeWTun7kgy1s2p1fo=.0230b5e8-28c4-4df0-82d9-a0b22d6d0f0e@github.com>
Message-ID: <1p8GsAJdu1p7WKZrWYq_3jynGdlMEi2Y8W28Pp_RdiU=.59639e91-5e39-4aaa-b9c0-f616e2f3de05@github.com>

On Mon, 21 Jul 2025 16:46:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 25.0.1 release.

This pull request has now been integrated.

Changeset: bfceb6a7
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/bfceb6a72b52ad2e2a637389d72e8b43021d0093
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8362896: Change JavaFX release version to 25.0.1 in jfx25u

Reviewed-by: angorya

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

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

From jhendrikx at openjdk.org  Mon Jul 21 18:51:35 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 21 Jul 2025 18:51:35 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <N5lQKKUrDwZup8K9Bj5YogBFQQeAuqK9riyPtkKuS3k=.7a14f047-6cc2-4b6c-8831-5f0a38f1d916@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
 <N5lQKKUrDwZup8K9Bj5YogBFQQeAuqK9riyPtkKuS3k=.7a14f047-6cc2-4b6c-8831-5f0a38f1d916@github.com>
Message-ID: <D2iaJG7yLAZz-Qe40QulhWsi2vnFL0LEvwEdVkKtO3k=.bd402815-7278-4114-a66c-f1224d60c53b@github.com>

On Mon, 21 Jul 2025 17:17:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> There first needs to be a new bug filed. Once there is, and a fix is available, we can see how risky the fix will be and decide  whether to backport it to jfx25.

@kevinrushforth @Glavo bug is filed here: https://bugs.openjdk.org/browse/JDK-8362873

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

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-3097987541

From kcr at openjdk.org  Mon Jul 21 21:11:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 21:11:01 GMT
Subject: [jfx25u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx
 update repos
Message-ID: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>

This is a copy of the jfx24u README and CONTRIBUTING docs, changing 24 to 25.

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

Commit messages:
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos

Changes: https://git.openjdk.org/jfx25u/pull/2/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx25u&pr=2&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304008
  Stats: 269 lines in 2 files changed: 1 ins; 256 del; 12 mod
  Patch: https://git.openjdk.org/jfx25u/pull/2.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/2/head:pull/2

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

From kcr at openjdk.org  Mon Jul 21 21:11:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 21 Jul 2025 21:11:01 GMT
Subject: [jfx25u] RFR: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
References: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
Message-ID: <SV5ydgEfKFAkRcoq2kHbOwm2fLvNrpEjhQdNm4nwnq0=.9ced2a9a-51e8-4c59-991f-a2f57919e0e9@github.com>

On Mon, 21 Jul 2025 21:00:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a copy of the jfx24u README and CONTRIBUTING docs, changing 24 to 25.

Reviewer: @johanvos

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

PR Comment: https://git.openjdk.org/jfx25u/pull/2#issuecomment-3098912739

From jhendrikx at openjdk.org  Tue Jul 22 00:13:36 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 22 Jul 2025 00:13:36 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
Message-ID: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>

This PR fixes a regression introduced in #1723

It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.

Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

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

Commit messages:
 - Fix regression

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

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

From jhendrikx at openjdk.org  Tue Jul 22 00:13:36 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 22 Jul 2025 00:13:36 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <3jiglrHefBNbqFLvxQo3psRtjc6SytMdKWD4WlEPpCA=.c2e5144b-cdbe-419b-b346-7cf70557aac3@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

@Glavo this should fix the regression

@kevinrushforth since the regression was introduced in the version we're about to release, we may want to consider this for immediate backport to avoid shipping it in the final version.

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

PR Comment: https://git.openjdk.org/jfx/pull/1850#issuecomment-3100014499

From jhendrikx at openjdk.org  Tue Jul 22 00:15:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 22 Jul 2025 00:15:30 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <9Ali9bZKgmn6UOypjYygJNEi63EGk9KXUxwY6BNIyi8=.8778809c-4544-4196-9e74-19134a289bea@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java line 630:

> 628:             Insets margin = getNodeMargin(child);
> 629:             return minimum ? computeChildMinAreaHeight(child, -1, margin, width, true):
> 630:                                    computeChildPrefAreaHeight(child, -1, margin, width, true);

Note: before the last boolean parameter was introduced in the `computeChildXXXAreaHeight` functions in `Region`, the default behavior was to have fill width set to `true`.  The reason I picked `false` is because the calculation above in `getAreaWidth` was using `false`, but it looks now that this was never correct.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1850#discussion_r2220620965

From jvos at openjdk.org  Tue Jul 22 06:42:32 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 22 Jul 2025 06:42:32 GMT
Subject: [jfx25u] RFR: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
References: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
Message-ID: <w9pYQS8NA9h_6YsxQcEU9FYHkXDiv9mfcYL0bn6eo5Y=.ac527f60-45f8-4919-9721-4d10af4651d0@github.com>

On Mon, 21 Jul 2025 21:00:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a copy of the jfx24u README and CONTRIBUTING docs, changing 24 to 25.

The result of the PR looks very similar to the README.md and CONTRIBUTING.md in jfx21u, as expected.

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

Marked as reviewed by jvos (Reviewer).

PR Review: https://git.openjdk.org/jfx25u/pull/2#pullrequestreview-3041371894

From jvos at openjdk.org  Tue Jul 22 07:09:58 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 22 Jul 2025 07:09:58 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v11]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Add copyright sections

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/b3d69a17..46bb2072

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=09-10

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

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

From tsayao at openjdk.org  Tue Jul 22 10:53:35 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 22 Jul 2025 10:53:35 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v48]
In-Reply-To: <33_Bb6F66GjY4S-NFs9KGXGVo2rRSPth4Q7q3Tu50_0=.113a957e-6c09-4e3d-94fa-ce168af2e7e3@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <aICBD_mIFz1vXUX5PcMeeBnt249MPCbDkg0cx5q4ocw=.e2de4009-ed23-4101-b12f-f4d6bd972258@github.com>
 <33_Bb6F66GjY4S-NFs9KGXGVo2rRSPth4Q7q3Tu50_0=.113a957e-6c09-4e3d-94fa-ce168af2e7e3@github.com>
Message-ID: <XRJgkE32geM5Iyp79BCt46NoqYzUMwHUSC_63xC9-GI=.52f38f37-5591-4746-b131-e2ca0adcecbb@github.com>

On Sun, 29 Jun 2025 11:58:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused const
>
> I have updated the main explanation of the changes. I also ran extensive tests on XWayland, Xorg, KDE, GNOME, and across different OS versions and distributions.

> @tsayao is this PR ready for review?

Yes

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3102205752

From kcr at openjdk.org  Tue Jul 22 12:43:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 12:43:34 GMT
Subject: [jfx25u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
References: <72RWsr92kt2K8EvoMn4AFIJuISSOTA1zlg1fDVHkcHc=.73e6cd96-ec67-46e4-9f6c-4adc234ba4b7@github.com>
Message-ID: <YhX-HR0Rzz8WbkIq-KCMh-g576_ulbwl6PieY8BIkZk=.0086c376-2fbd-4174-96e2-f0052d459281@github.com>

On Mon, 21 Jul 2025 21:00:57 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is a copy of the jfx24u README and CONTRIBUTING docs, changing 24 to 25.

This pull request has now been integrated.

Changeset: 8e835833
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/8e83583379a474cb1812cdc32ad372e2f8afc51a
Stats:     269 lines in 2 files changed: 1 ins; 256 del; 12 mod

8304008: Update README.md and CONTRIBUTING.md for jfx update repos

Reviewed-by: jvos
Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6

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

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

From kcr at openjdk.org  Tue Jul 22 12:57:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 12:57:33 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <3jiglrHefBNbqFLvxQo3psRtjc6SytMdKWD4WlEPpCA=.c2e5144b-cdbe-419b-b346-7cf70557aac3@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
 <3jiglrHefBNbqFLvxQo3psRtjc6SytMdKWD4WlEPpCA=.c2e5144b-cdbe-419b-b346-7cf70557aac3@github.com>
Message-ID: <Wc8niOfCc_GW6pwMPWqLnoBtPvuqVYQUj3sKYh6GjFU=.7a7028d0-15e3-4e05-bc46-342e9a008c8f@github.com>

On Tue, 22 Jul 2025 00:08:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> @kevinrushforth since the regression was introduced in the version we're about to release, we may want to consider this for immediate backport to avoid shipping it in the final version.

Agreed. This is a good candidate to backport to jfx25.

> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

Since we want to backport this to jfx25, it would be safer to just fix the regression introduced in 25.

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

PR Comment: https://git.openjdk.org/jfx/pull/1850#issuecomment-3102598913

From kcr at openjdk.org  Tue Jul 22 12:57:33 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 12:57:33 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <Wc8niOfCc_GW6pwMPWqLnoBtPvuqVYQUj3sKYh6GjFU=.7a7028d0-15e3-4e05-bc46-342e9a008c8f@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
 <3jiglrHefBNbqFLvxQo3psRtjc6SytMdKWD4WlEPpCA=.c2e5144b-cdbe-419b-b346-7cf70557aac3@github.com>
 <Wc8niOfCc_GW6pwMPWqLnoBtPvuqVYQUj3sKYh6GjFU=.7a7028d0-15e3-4e05-bc46-342e9a008c8f@github.com>
Message-ID: <eXN1JDD4glEXlVlERsomm_kf6gftS2vlHb7cH-Pa45M=.58282adc-b285-41c9-ae4d-22f19df5579b@github.com>

On Tue, 22 Jul 2025 12:54:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @Glavo this should fix the regression
>> 
>> @kevinrushforth since the regression was introduced in the version we're about to release, we may want to consider this for immediate backport to avoid shipping it in the final version.
>
>> @kevinrushforth since the regression was introduced in the version we're about to release, we may want to consider this for immediate backport to avoid shipping it in the final version.
> 
> Agreed. This is a good candidate to backport to jfx25.
> 
>> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.
> 
> Since we want to backport this to jfx25, it would be safer to just fix the regression introduced in 25.

Reviewers: @kevinrushforth @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1850#issuecomment-3102599565

From kevin.rushforth at oracle.com  Tue Jul 22 15:59:52 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 22 Jul 2025 08:59:52 -0700
Subject: jfx25u open for JavaFX 25.0.1 backports
Message-ID: <2c96adc7-7cd8-49dc-b6dc-822caecbfef1@oracle.com>

All,

The jfx25u repo [1] is now open for JavaFX 25.0.1 backports (the October 
2025 CPU release), with approval from one of the project leads. The 
general criteria is that we want to backport fixes for regressions 
introduced in JavaFX 25, third-party library updates, and a limited 
number of other important bug fixes. In most cases we'd like to see the 
fix "bake" in the mainline for a while before being backported to jfx25u.

NOTE: Only those fixes that will NOT be backported to the jfx25 [2] 
stabilization branch are candidates for backporting to jfx25u. A 
backport intended for the JavaFX 25 code line will go into either the 
jfx25 branch or the jfx25u repo, not both.

We use a similar procedure for making the request and noting the 
approval as is used by the JDK updates releases -- by using JBS labels 
to request a backport and indicate approval or rejection.

Here is the procedure:

1. If you are not sure whether something is a good candidate for 
backporting, ask on the mailing list or in the PR you want to backport.

2. Create the backport PR for jfx25u, either manually or using the 
"/backport" command. You can use Skara's "/approval" command to request 
approval. Skara will not mark a jfx25u PR as ready until approved.

Let Johan or me know if you have any questions.

Thanks.

-- Kevin

[1] https://github.com/openjdk/jfx25u
[2] https://github.com/openjdk/jfx/tree/jfx25


From angorya at openjdk.org  Tue Jul 22 16:14:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 22 Jul 2025 16:14:01 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <oo8n5PdsmKH9pmiwEamEKP2zJ72Q9rgYWTtM-5YVYP8=.72162cb5-40de-4d86-8d0b-0fc6af397806@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

Marked as reviewed by angorya (Reviewer).

This PR fixes the vertical layout case (`verticalLayout = true;`).

Do we have a ticket for the incorrect computation for the horizontal layout?  If not, could you please create a follow-up one?

<img width="861" height="816" alt="Screenshot 2025-07-22 at 09 08 16" src="https://github.com/user-attachments/assets/a7604eae-65c3-46cd-8d02-06b9cf531e08" />

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

PR Review: https://git.openjdk.org/jfx/pull/1850#pullrequestreview-3043780478
PR Comment: https://git.openjdk.org/jfx/pull/1850#issuecomment-3103612681

From mstrauss at openjdk.org  Tue Jul 22 16:27:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 22 Jul 2025 16:27:01 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <6le0Fwj2gQrKLyL6RFYUupBAOHqWnUHHzkd67fupEQg=.4611e567-8a20-4a4a-94a0-410f74b3e186@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

The fix looks good.

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

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1850#pullrequestreview-3043825356

From nlisker at openjdk.org  Tue Jul 22 16:42:10 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 22 Jul 2025 16:42:10 GMT
Subject: RFR: 8092272: [D3D 3D] Need a robust 3D states management for
 texture [v2]
In-Reply-To: <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
References: <Z1gOM7AKvXnI3HkLMv1PaR-meTg7P2o0dm3GHlj7U2Q=.b69acc8e-acee-406b-8537-5c1eeadaf7c5@github.com>
 <zS6BeS2MD21vPPitDnDzyYJbAuOZd-qDromA1pzfSQ0=.cc33dc34-8e9b-4164-9775-5b727263f519@github.com>
Message-ID: <CvI5ZhqaySpc1mSh5j1GOddro0oq7OxHtfSV6X2hpnU=.7cf13136-aa63-4870-8289-dbcf307481b3@github.com>

On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Moves the filter setting of the samplers from the device parameters configuration to the use-site, allowing for dynamic changes in the sampler. This PR does internal plumbing work only to bring it close to the ES2 pipeline. A followup PR will create the public API.
>> 
>> Summary of the changes:
>> * Created a new (internal for now) `TextureData` object that is intended to contain all the data of texture (map) of `PhongMaterial`, such as filters, addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** as a starting point, more settings can be added later.
>> * Creates an update mechanism from the Java side material to the native D3D layer. The public API `PhoneMaterial` is *not* changed yet. The peer `NGPhongMaterial` is configured to receive update from the public `PhongMaterial` when the public API is created via new `ObjectProperty<TextureData>` properties.
>> * Small refactoring in the D3D layer with a new map types enum to control the texture settings more easily.
>> 
>> The JBS issue lists some regressions in a comment, but I couldn't reproduce them. It looks like the sampler settings needed to be added anywhere, and that was the easiest to do at the time. Now they were just moved.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

And there are also render states here to take into account.

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

PR Comment: https://git.openjdk.org/jfx/pull/1281#issuecomment-3103765991

From arapte at openjdk.org  Tue Jul 22 16:51:28 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 16:51:28 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v10]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <3GvYv9rOPpiGDwIYkM-8ztoT2aSgVAq7csVzDEzAEec=.65b6cd69-dd2f-4c2d-99ad-695689faa08c@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:

 - add comment for ES2SwapChain.getFboID
 - remove MTLLog

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/b9b35608..774890e4

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

  Stats: 50 lines in 4 files changed: 2 ins; 48 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 Jul 22 16:51:28 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 16:51:28 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
 <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
Message-ID: <VSckH2B5rD0sICXNmXLIA1UtPiObemTX_CecrFI7uwI=.cb34f1ba-8f73-41b5-b8ac-f6692277ef63@github.com>

On Wed, 16 Jul 2025 19:48:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java line 240:
>> 
>>> 238:     @Override
>>> 239:     public int getFboID() {
>>> 240:         return (int)nativeDestHandle;
>> 
>> this results in loss of information.  any possibility that it may backfire somehow, by mapping two different `nativeDestHandle`s to the same `int`?
>
> Good question. Given that the ES2 pipeline only ever uses an int value, it's _probably_ fine. But it's hard to prove without looking at the native code. At the very least, a comment explaining this would be good.

I shall add a comment, the value that nativeDestHandle stores is of type unsigned int. hence this type conversion is safe.

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

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

From arapte at openjdk.org  Tue Jul 22 16:51:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 16:51:29 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <vxFg4umUb2cv6JH-Q6DR2Tovf68yEEee1EIS8Uq73rg=.443898b0-df8d-4f98-87ea-6c2bf892f575@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>
Message-ID: <E5Vp_UeDcyrILxCm_Y-lIKXmC2Fw9P5rh7OQ40t_urw=.2f2d7e13-49cb-4a75-9499-1b4a142358b0@github.com>

On Wed, 16 Jul 2025 17:48:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes for running apps in eclipse
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLLog.java line 31:
> 
>> 29: 
>> 30: public class MTLLog {
>> 31:     public static void Debug(String str) {
> 
> Since `MTTLLog` is a home-grown facility:
> 
> perhaps we should consider allowing `Supplier<String>` lambdas (or `Supplier<Object>`), or allow for `MessageFormat`'ted strings, to avoid concatenations.
> 
> Lambdas may be faster, but they do require effectively final parameters.

The Log were helpful during development, but now it can be removed. Thanks for pointing it out.

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

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

From arapte at openjdk.org  Tue Jul 22 17:00:25 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 17:00:25 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@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 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/4bb277a2...1a9a0a41

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/774890e4..1a9a0a41

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

  Stats: 8969 lines in 118 files changed: 7204 ins; 1380 del; 385 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 Jul 22 17:00:25 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 17:00:25 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v8]
In-Reply-To: <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <fy4IS2ZDP45v9VZi5s7aN5Y2jMImoCkmfuevg330vHk=.4faa302c-a2fd-4508-a3a5-bb47c7d2df9d@github.com>
 <x-wkgG5foCCNtifeQBz5u8O_UrpQqcBJauN1o_vYsvc=.76f54cb0-c6f4-4419-abef-eb9194eeaf82@github.com>
 <yWMBAxjskCH4nAhYfppU5qh_j3YdkE5QUQ-lA0UDwC8=.a960c7d0-2e81-451a-8d0b-8b99f9929a11@github.com>
Message-ID: <t2wYOhU4YAsbC8hqjk5CL0TxOvvlqcF0z5YQelPCgaM=.e07d4352-107d-49f9-a22a-37c8a4d6c212@github.com>

On Thu, 17 Jul 2025 12:31:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > you might want to sync up with the latest master.
> 
> Agreed, although you might wait until after the jfx25 fork at this point.

Merged in the latest master.

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

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

From arapte at openjdk.org  Tue Jul 22 17:38:32 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 22 Jul 2025 17:38:32 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
Message-ID: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>

The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

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

Commit messages:
 - null check for NewObjectArray

Changes: https://git.openjdk.org/jfx/pull/1851/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1851&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363813
  Stats: 31 lines in 4 files changed: 10 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1851.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1851/head:pull/1851

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

From kcr at openjdk.org  Tue Jul 22 17:38:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 17:38:32 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
Message-ID: <nV_euzAabxOXG5zKv_1tFM57sNkt4Qf5Zs0gpE8-yTM=.749509b7-7115-45dc-8bc8-d149d5bb620b@github.com>

On Tue, 22 Jul 2025 17:28:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

LGTM

Reviewers: @kevinrushforth @johanvos 

Johan: can you take a look at the/ios/ changes?

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1851#pullrequestreview-3044107426
PR Comment: https://git.openjdk.org/jfx/pull/1851#issuecomment-3104000027

From mstrauss at openjdk.org  Tue Jul 22 18:31:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 22 Jul 2025 18:31:00 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <UQokl26Rc0fp_sLbeoVODsWtLQd-gwN9XfY9GpUJlO4=.6b226ddb-6e9f-4d64-bc75-4e2474a33c0b@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

I think this fix should make the 25 release if possible, as it would be unfortunate to preview the new feature with distracting bugs included. The fix is also quite well-tested at this point.

@kevinrushforth @andy-goryachev-oracle Do you have any review capacity to spare for this within the current RDP?

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

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3104261081

From duke at openjdk.org  Tue Jul 22 19:08:01 2025
From: duke at openjdk.org (Cormac Redmond)
Date: Tue, 22 Jul 2025 19:08:01 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <UQokl26Rc0fp_sLbeoVODsWtLQd-gwN9XfY9GpUJlO4=.6b226ddb-6e9f-4d64-bc75-4e2474a33c0b@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
 <UQokl26Rc0fp_sLbeoVODsWtLQd-gwN9XfY9GpUJlO4=.6b226ddb-6e9f-4d64-bc75-4e2474a33c0b@github.com>
Message-ID: <E9M09uMLgg7xpiXAEtGqey5VaIDrYnIVPtltvVkzOcs=.03df4365-e25c-4afc-be96-bfe604f2c52d@github.com>

On Tue, 22 Jul 2025 18:28:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> I think this fix should make the 25 release if possible, as it would be unfortunate to preview the new feature with distracting bugs included. The fix is also quite well-tested at this point.
> 
> @kevinrushforth @andy-goryachev-oracle Do you have any review capacity to spare for this within the current RDP?

Agreed. It wouldn't take long until others come across this and raise the same issue.

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

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3104440555

From credmond at certak.com  Tue Jul 22 19:08:08 2025
From: credmond at certak.com (Cormac Redmond)
Date: Tue, 22 Jul 2025 20:08:08 +0100
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
Message-ID: <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>

Any thoughts on this? It seems like a definite JavaFX bug with hopefully a
simple fix. Choosing any fractional scaled resolution may or may not cause
the issue. I also wonder what other controls may suffer from the same
issues.

On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com> wrote:

> Hi,
>
> I've traced the bug down to a rounding error. See the below screenshot in
> ToolBarSkin's getOverflowNodeIndex(double length).
>
> These two numbers are not equal, but should be. snapSizeX() ultimately
> ends up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1
> (i.e., no scaling), we don't see this issue. If it's 1.25, we see this
> rounding difference between the two numbers in this instance. If these two
> numbers are not equal, the calling code mistakenly assumes the overflow box
> is necessary.
>
> [image: image.png]
>
> Can someone fix this?
>
>
>
> Kind Regards,
> Cormac
>
> On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com> wrote:
>
>> Confusingly, make the string longer, such as "Create Schema 123 123 123":
>>
>>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123
>> 123"))));
>>
>> ...and the overflow doesn't appear (but still, anything between and
>> including 13-24, it does):
>>
>> [image: image.png]
>>
>>
>>
>>
>> Kind Regards,
>> Cormac
>>
>> On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com> wrote:
>>
>>> Hi,
>>>
>>> There's a bug whenever using a ToolBar on Windows if you set your
>>> resolution scale > 100% (which is quite common). E.g., 125%:
>>>
>>> [image: image.png]
>>>
>>> E.g., this is what a ToolBar always renders if scale is 125%:
>>>
>>> [image: image.png]
>>>
>>> As compared to what you'd expect (scale set to normal/100%):
>>>
>>> [image: image.png]
>>>
>>> Very easy to reproduce the above, set your scale to 125% and run this:
>>>
>>> public class ToolbarBugApp extends Application {
>>>
>>>     @Override
>>>     public void start(Stage primaryStage) {
>>>         BorderPane bp = new BorderPane();
>>>         // Wrapping in HBox and using button with 13+ chars causes bug
>>>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema"))));
>>> // BUG
>>>         // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
>>> (no HBox)
>>>         // bp.setTop(new HBox(new ToolBar(new Button("Create Schem"))));
>>> // NO BUG (12 chars)
>>>         primaryStage.setScene(new Scene(bp, 600, 400));
>>>         primaryStage.show();
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>         launch(args);
>>>     }
>>> }
>>>
>>> As per the comments, this bug appears to happen when your ToolBar is
>>> wrapped in a HBox and contains a Button that has 13+ characters, for
>>> example. This is quite a serious bug, in my opinion.
>>>
>>> I believe this is present in JFX 24 and the JFX 25 master branch.
>>>
>>>
>>> Kind Regards,
>>>
>>> *Cormac Redmond*
>>> Software Engineer, Certak Ltd.
>>>
>>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/22e566c3/image-0009.png>

From kcr at openjdk.org  Tue Jul 22 20:00:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 20:00:05 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <E9M09uMLgg7xpiXAEtGqey5VaIDrYnIVPtltvVkzOcs=.03df4365-e25c-4afc-be96-bfe604f2c52d@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
 <UQokl26Rc0fp_sLbeoVODsWtLQd-gwN9XfY9GpUJlO4=.6b226ddb-6e9f-4d64-bc75-4e2474a33c0b@github.com>
 <E9M09uMLgg7xpiXAEtGqey5VaIDrYnIVPtltvVkzOcs=.03df4365-e25c-4afc-be96-bfe604f2c52d@github.com>
Message-ID: <CQZFBm-G_rtz5eKnLYhu7LbKHpSpG4gbVL0OF7mjkxY=.b453d22e-d4ee-4289-9d8d-8be6e6ef4578@github.com>

On Tue, 22 Jul 2025 19:05:12 GMT, Cormac Redmond <duke at openjdk.org> wrote:

> I think this fix should make the 25 release if possible, as it would be unfortunate to preview the new feature with distracting bugs included. The fix is also quite well-tested at this point.
> 
> @kevinrushforth @andy-goryachev-oracle Do you have any review capacity to spare for this within the current RDP?

Yes, I'll review it this week. It seems a good candidate for backporting to jfx25.

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

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3104651115

From Mitchell.Z.Wagner at leidos.com  Tue Jul 22 20:04:46 2025
From: Mitchell.Z.Wagner at leidos.com (Wagner, Mitchell [US-US])
Date: Tue, 22 Jul 2025 20:04:46 +0000
Subject: Dragged Text Object not shown.
Message-ID: <SA1P110MB2054B0C20A66D7A38C667BBDC15CA@SA1P110MB2054.NAMP110.PROD.OUTLOOK.COM>

Leidos Proprietary

Hi all,

We have an urgent JavaFX issue.  Please see the following.  If anyone can help or give any help.  Please let me know.



Summary:
OpenJFX: Dragged Text Object not shown.
Description:
We have a use case involving the dragging of text across a Stage. To support this, we have created a Text object, which is registered to the root AnchorPane. The Text Object can be dragged freely around the Stage. However, we've encountered an issue where the text sometimes fails to render, even though the Text Object contains the expected data.
When the mouse click happens, the current action is:
root.getChildren().remove(dragText);
root.getChildren().add(dragText);
This happens directly before we start the drag action:
dragText.startFullDrag();

(dragText is a Text Object)
The dragText contains the expected value when the Text object is rendered or not. The issue seems to be with rendering of the object. When the issue occurs, the JavaFX application must be restarted to recover. Have verified:

  *   anchor root is valid with correct x/y locations
  *   the text node that is being dragged is visible/has focus/correct x/y values in relation to parent stage
  *   toBack/toFront does not change the results
  *   increasing the font to a much larger size changed nothing
  *   occurs randomly (with multiple application restarts between instances) on both single and multiple monitor workstations

Steps to reproduce:
Drag text repeatedly until text does not show up.
Only reproducible on physical equipment.  Not currently reproducible on Virtual Machines.
Current environment is: RHEL 8.10, X11, openJDK: 17.0.12, openJFX: 17
Expected Results:
Text should always be rendered.
Actual Results:
Text is not always rendered when dragged.


Thanks,

Mitchell Wagner | Leidos
Lead Software Engineer | Civil
phone: 609.272.2051
mitchell.z.wagner at leidos.com<mailto:mitchell.z.wagner at leidos.com>  |  leidos.com/civil<http://www.leidos.com/civil>



This email and any attachments to it are intended only for the identified recipients. It may contain proprietary or otherwise legally protected information of Leidos. Any unauthorized use or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete or otherwise destroy the email and all attachments immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250722/1493470a/attachment-0001.htm>

From Mitchell.Z.Wagner at leidos.com  Tue Jul 22 20:05:39 2025
From: Mitchell.Z.Wagner at leidos.com (Wagner, Mitchell [US-US])
Date: Tue, 22 Jul 2025 20:05:39 +0000
Subject: Recall: Dragged Text Object not shown.
Message-ID: <SA1P110MB20548F1749DF4695B5CD5235C15CA@SA1P110MB2054.NAMP110.PROD.OUTLOOK.COM>

Wagner, Mitchell [US-US] would like to recall the message, "Dragged Text Object not shown.".

From Mitchell.Z.Wagner at leidos.com  Tue Jul 22 20:06:15 2025
From: Mitchell.Z.Wagner at leidos.com (Wagner, Mitchell [US-US])
Date: Tue, 22 Jul 2025 20:06:15 +0000
Subject: Dragged Text Object not shown.
Message-ID: <SA1P110MB205436F962DE3CCC504D2233C15CA@SA1P110MB2054.NAMP110.PROD.OUTLOOK.COM>

Hi all,

We have an urgent JavaFX issue.  Please see the following.  If anyone can help or give any help.  Please let me know.



Summary:
OpenJFX: Dragged Text Object not shown.
Description:
We have a use case involving the dragging of text across a Stage. To support this, we have created a Text object, which is registered to the root AnchorPane. The Text Object can be dragged freely around the Stage. However, we've encountered an issue where the text sometimes fails to render, even though the Text Object contains the expected data.
When the mouse click happens, the current action is:
root.getChildren().remove(dragText);
root.getChildren().add(dragText);
This happens directly before we start the drag action:
dragText.startFullDrag();

(dragText is a Text Object)
The dragText contains the expected value when the Text object is rendered or not. The issue seems to be with rendering of the object. When the issue occurs, the JavaFX application must be restarted to recover. Have verified:

  *   anchor root is valid with correct x/y locations
  *   the text node that is being dragged is visible/has focus/correct x/y values in relation to parent stage
  *   toBack/toFront does not change the results
  *   increasing the font to a much larger size changed nothing
  *   occurs randomly (with multiple application restarts between instances) on both single and multiple monitor workstations

Steps to reproduce:
Drag text repeatedly until text does not show up.
Only reproducible on physical equipment.  Not currently reproducible on Virtual Machines.
Current environment is: RHEL 8.10, X11, openJDK: 17.0.12, openJFX: 17
Expected Results:
Text should always be rendered.
Actual Results:
Text is not always rendered when dragged.


Thanks,

Mitchell Wagner | Leidos
Lead Software Engineer | Civil
phone: 609.272.2051
mitchell.z.wagner at leidos.com<mailto:mitchell.z.wagner at leidos.com>  |  leidos.com/civil<http://www.leidos.com/civil>

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

From crschnick at xpipe.io  Wed Jul 23 05:55:05 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 23 Jul 2025 07:55:05 +0200
Subject: Dragged Text Object not shown.
In-Reply-To: <SA1P110MB205436F962DE3CCC504D2233C15CA@SA1P110MB2054.NAMP110.PROD.OUTLOOK.COM>
References: <SA1P110MB205436F962DE3CCC504D2233C15CA@SA1P110MB2054.NAMP110.PROD.OUTLOOK.COM>
Message-ID: <115a6eb1-c75a-46f9-a96c-d95718a7b3fa@xpipe.io>

Is that specific to a Text node? Or what happens if you use a Label or 
similar. And also, is the whole node gone or only the text itself, e.g., 
what happens if you set a background color for the node you drag.

On 22/07/2025 22:06, Wagner, Mitchell [US-US] wrote:
>
> Hi all,
>
> We have an urgent JavaFX issue.? Please see the following.? If anyone 
> can help or give any help.? Please let me know.
>
> **
>
> **
>
> **
>
> *Summary: *
>
> OpenJFX: Dragged Text Object not shown.
>
> *Description:*
>
> We have a use case involving the dragging of text across a Stage. To 
> support this, we have created a Text object, which is registered to 
> the root AnchorPane. The Text Object can be dragged freely around the 
> Stage. However, we've encountered an issue where the text sometimes 
> fails to render, even though the Text Object contains the expected data.
>
> When the mouse click happens, the current action is:
> root.getChildren().remove(dragText);
> root.getChildren().add(dragText);
>
> This happens directly before we start the drag action:
>
> dragText.startFullDrag();
>
> /(dragText is a Text Object)/
>
> The dragText contains the expected value when the Text object is 
> rendered or not. The issue seems to be with rendering of the object. 
> When the issue occurs, the JavaFX application must be restarted to 
> recover.?Have verified:
>
>   * anchor root is valid with correct x/y locations
>   * the text node that is being dragged is visible/has focus/correct
>     x/y values in relation to parent stage
>   * toBack/toFront does not change the results
>   * increasing the font to a much larger size changed nothing
>   * occurs randomly (with multiple application restarts between
>     instances) on both single and multiple monitor workstations
>
> *Steps to reproduce: *
>
> Drag text repeatedly until text does not show up.
>
> Only reproducible on physical equipment.? Not currently reproducible 
> on Virtual Machines.
>
> Current environment is: RHEL 8.10, X11, openJDK: 17.0.12, openJFX: 17
>
> *Expected Results: *
>
> Text should always be rendered.
>
> *Actual Results: *
>
> Text is not always rendered when dragged.
>
> Thanks,
>
> *Mitchell Wagner?| Leidos*
>
> Lead Software Engineer | Civil
>
> phone: 609.272.2051
> mitchell.z.wagner at leidos.com <mailto:mitchell.z.wagner at leidos.com>?| 
> leidos.com/civil <http://www.leidos.com/civil>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/76aa88ad/attachment.htm>

From kizune at openjdk.org  Wed Jul 23 06:17:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 23 Jul 2025 06:17:00 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
Message-ID: <HYv_kYCkyBr30SpUZsuankzZBYt9ydSuMJLuzMDtnF0=.cce25182-68ff-4802-9f87-1c055b3fb6ee@github.com>

On Tue, 22 Jul 2025 17:28:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

Marked as reviewed by kizune (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1851#pullrequestreview-3045801628

From jvos at openjdk.org  Wed Jul 23 08:54:01 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 23 Jul 2025 08:54:01 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
Message-ID: <R7-cs5X-e5xX5jTljcHTpA5e5aTo656WuIXwDYDq8po=.c079ee30-8bf6-4aca-9766-6a680d6671f1@github.com>

On Tue, 22 Jul 2025 17:28:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1851#pullrequestreview-3046377118

From jvos at openjdk.org  Wed Jul 23 08:54:01 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 23 Jul 2025 08:54:01 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <nV_euzAabxOXG5zKv_1tFM57sNkt4Qf5Zs0gpE8-yTM=.749509b7-7115-45dc-8bc8-d149d5bb620b@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
 <nV_euzAabxOXG5zKv_1tFM57sNkt4Qf5Zs0gpE8-yTM=.749509b7-7115-45dc-8bc8-d149d5bb620b@github.com>
Message-ID: <AnvvUnhdMZiV4uLKesoKskZ9ro9bPmclykALAD7aTOI=.c61034dc-6535-422b-a222-26023181fec7@github.com>

On Tue, 22 Jul 2025 17:31:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Johan: can you take a look at the/ios/ changes?

At first sight, those changes are not causing regression on ios. I'll do a deeper end-to-end test, but will already approve this since I don't want to stop this PR from being integrated.

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

PR Comment: https://git.openjdk.org/jfx/pull/1851#issuecomment-3106593655

From jdv at openjdk.org  Wed Jul 23 09:36:11 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Jul 2025 09:36:11 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <_iOBAYAJMKLyfYUzIVu7JBKs6wXHco-yRhN7JLXSTz8=.c0c25ce3-1337-44ea-80cf-19e1c6782599@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <_iOBAYAJMKLyfYUzIVu7JBKs6wXHco-yRhN7JLXSTz8=.c0c25ce3-1337-44ea-80cf-19e1c6782599@github.com>
Message-ID: <gU7tqmc7YGoG5fy8cxiJeSm86oykbsDKlaiZSqCcKI8=.8da21c3d-8c69-4a39-b732-5c1a408801d4@github.com>

On Tue, 22 Jul 2025 17:57:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The code changes look good.
> 
> I played with `PickTest3D` a bit, and at some point clicking on one of the handles caused one object to disappear. Clicked on something else, and entire assembly disappeared.
> 
> (This might be something in `PickTest3D`, or working as designed, since it also happens in the master branch).

Picktest3D updates depth test or activates/de-activates shapes based on mouse events.
Behaviour is same in both OpenGL and Metal.

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

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

From lkostyra at openjdk.org  Wed Jul 23 12:17:06 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 23 Jul 2025 12:17:06 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v49]
In-Reply-To: <MJaLuX2s_kx4fVw2vwB76tcqsIi5pagdOMICdpeJ7S4=.20cabf40-be00-4fcd-91d6-07f632e0a417@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <MJaLuX2s_kx4fVw2vwB76tcqsIi5pagdOMICdpeJ7S4=.20cabf40-be00-4fcd-91d6-07f632e0a417@github.com>
Message-ID: <K38E6DrQAvsukrJrMQKTcCSGYlE3zOVEMH0JgIoFXYc=.6eb68911-52a0-47a8-825d-2547f560a558@github.com>

On Mon, 30 Jun 2025 10:39:00 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 58 commits:
> 
>  - 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
>  - Re-allow fullscreen on child
>  - Test fixes for mac + typo
>  - ... and 48 more: https://git.openjdk.org/jfx/compare/0270847b...016ff681

This is quite a big change but after the first pass it seems to be quite good. I left only a couple minor comments, but I will have to do more "passes" on this PR (especially through the tests which I only loosely glanced on).

As such, two requests for this PR for now:
1. This PR fixes quite a bit of issues we had with Linux that were reported, they are listed in the PR description. Can you link all of them via Skara's `/issue add <JDK-ID>` so that they get resolved once this PR goes through? I think you should be able to link all issues within one command so `/issue add JDK-ID,JDK-ID,...`
2. Can you merge latest master? We recently updated used JDK and Gradle version and this PR still lags behind on old ones which collides with test runs.

I also did an initial test run, I did get quite a bit of failures (Ubuntu 24.04.2 LTS VM, Gnome 46 on Wayland, 91 total tests failing; to name a few prominent groups that fail - `TextCharacterIndexTest`, `TextFlowSurrogatePairInsertionIndexTest`, `RegionBackgroundFillUITest`, `RegionBackgroundImageUITest`) but I'm not sure if those also fail on master yet - I'll re-check after the master merge.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1036:

> 1034: void WindowContext::notify_fullscreen(bool enter) {
> 1035:     if (enter) {
> 1036:         LOG("com_sun_glass_events_ViewEvent_FULLSCREEN_ENTER\n");

This could be simplified to


LOG("com_sun_glass_events_ViewEvent_FULLSCREEN_%s\n", enter ? "ENTER" : "EXIT");
mainEnv->CallVoidMethod(jview, jViewNotifyView, enter ? com_sun_glass_events_ViewEvent_FULLSCREEN_ENTER : com_sun_glass_events_ViewEvent_FULLSCREEN_EXIT);
CHECK_JNI_EXCEPTION(mainEnv)

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1359:

> 1357: }
> 1358: 
> 1359: // This only works o Xorg

Minor: "works o" -> "works on"

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

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3039031659
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2225189967
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2225228459

From kcr at openjdk.org  Wed Jul 23 12:40:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 12:40:59 GMT
Subject: RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <-oVsEr4a5oafbbaC33vqa-m2vydVD6thKkbzRBSGHTI=.4bace78a-3b0e-4e6d-948c-53c3cdeab01f@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

LGTM

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1850#pullrequestreview-3047223777

From kevin.rushforth at oracle.com  Wed Jul 23 13:34:18 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 23 Jul 2025 06:34:18 -0700
Subject: Is there an easier way to "fix" a control instead of building
 everything (i.e., java, native, etc.)?
In-Reply-To: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com>
References: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com>
Message-ID: <a6c4d03e-b736-400c-a7c3-db6097e09489@oracle.com>

[redirecting to openjfx-dev]

You will need to build all of JavaFX using gradle.

You might be running into an issue with the version of Xcode you are 
using. You will need macOS 14 or 15 with a recent version of Xcode. We 
use Xcode 15.4 for our production builds.

Can you list the version of macOS and Xcode you are using? And 
copy/paste the specific error message(s) you see?

-- Kevin


On 7/22/2025 8:21 PM, Paul Furbacher wrote:
> I want to investigate fixing what I consider a bug or deficiency in a particular control in the easiest manner possible.
>
> Initially, I thought to just build everything, but that hasn?t worked because I run into an issue with native compilation, notably in ?:graphics:ccMacGlass?.
>
> Instead of battling gradle to build the whole shebang, it seems to me it would be much quicker to simply patch an existing distribution. Browsing ?build.gradle?, nothing jumps out at me.
>
> Is it possible to just patch a published distribution with a ?fixed? javafx.controls jar?
>
> (Leave jmods out of the picture for the moment because I?ll initially use javafx on the classpath. If my idea of a fix pans out, then I?d proceed with filing a bug report with suggested changes, and maybe doing a pull request ? that?s for later.)
>
> If that?s not possible, I might be back here asking for help diagnosing what?s causing clang to finish with a non-zero exit value
>
>
> Regards,
>
> Paul Furbacher
>


From jdv at openjdk.org  Wed Jul 23 13:41:05 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 23 Jul 2025 13:41:05 GMT
Subject: RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
Message-ID: <V3HqH9754WnJ0M8wwC_ORw1ZnV-fLg0YhTXhOdPSjOw=.17d9c1d0-02a2-48fb-a7ac-9893524d76a7@github.com>

On Tue, 22 Jul 2025 17:28:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

Marked as reviewed by jdv (Committer).

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

PR Review: https://git.openjdk.org/jfx/pull/1851#pullrequestreview-3047508094

From angorya at openjdk.org  Wed Jul 23 14:52:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Jul 2025 14:52:08 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
Message-ID: <w2X2FqcNBzRKOqJ178LLzW0_VBiCeLnVsX_6DLnZlOk=.701cd630-09ab-4a17-8c01-113fb719ee6d@github.com>

On Tue, 22 Jul 2025 17:00:25 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 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/7e8a88c8...1a9a0a41

lgtm, thanks!

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

Marked as reviewed by angorya (Reviewer).

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

From jhendrikx at openjdk.org  Wed Jul 23 15:26:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 23 Jul 2025 15:26:15 GMT
Subject: Integrated: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
References: <N7avOdVtnBxQzpEBsuLOk7O_SgcVGE_JnAukeloqNxE=.17f6af0a-511d-46b2-b916-de34d557e493@github.com>
Message-ID: <KSGGXarHRmwcUamh1uGCqj29SxvfWLJIS-h8is05xFQ=.fa1e221b-8c26-4208-9736-b63e476830b4@github.com>

On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR fixes a regression introduced in #1723
> 
> It reverts the changes made in the BorderPaneTest with new comments explaining why the values are what they are.  It only fixes the regression that was introduced, but it can be said that the calculation is probably also incorrect when a vertical biased control is encountered (the `getAreaWidth` and `getAreaHeight` in `BorderPane` were, and are still not using the same way to calculate their respective sizes).  See the ticket for more details and screenshots.
> 
> Let me know if I should only address the regression introduced, or also include the fix for the bias calculation for vertical bias controls.

This pull request has now been integrated.

Changeset: 7b59ebce
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb
Stats:     50 lines in 2 files changed: 37 ins; 0 del; 13 mod

8362873: Regression in BorderPane after JDK-8350149

Reviewed-by: angorya, mstrauss, kcr

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

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

From john.hendrikx at gmail.com  Wed Jul 23 15:32:45 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 23 Jul 2025 17:32:45 +0200
Subject: Is there an easier way to "fix" a control instead of building
 everything (i.e., java, native, etc.)?
In-Reply-To: <a6c4d03e-b736-400c-a7c3-db6097e09489@oracle.com>
References: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com>
 <a6c4d03e-b736-400c-a7c3-db6097e09489@oracle.com>
Message-ID: <d06a06ec-b3a7-4fe1-a090-1be24063e81f@gmail.com>

For investigating a bug, what I usually do is copy the
control/skin/class/etc in question into my current project, leaving it
in its original package.? This effectively overwrites that class,
allowing you to make edits to it (like adding debug prints, or altering
calculations).? This works pretty easily as long as the project is
non-modular; with modular projects you may need to add command line
options.? For most of my investigations, I keep things simple and just
use a non-modular project.? I've debugged many controls, layout issues
and CSS code this way in the past, without having to run the JavaFX
build at all, allowing for almost instant feedback.

So for example, you have something you want to investigate in BorderPane
(my most recent exploit).? Go to the class, copy the whole code, paste
it into your project (my IDE will automatically place it in its original
package).? Now the code is editable.? Make your test changes, run the
project, and see if they improve the situation.? I generally do this
with Maven projects, and a class provided by the main artifact will
override anything provide by a dependency.

--John

On 23/07/2025 15:34, Kevin Rushforth wrote:
> [redirecting to openjfx-dev]
>
> You will need to build all of JavaFX using gradle.
>
> You might be running into an issue with the version of Xcode you are
> using. You will need macOS 14 or 15 with a recent version of Xcode. We
> use Xcode 15.4 for our production builds.
>
> Can you list the version of macOS and Xcode you are using? And
> copy/paste the specific error message(s) you see?
>
> -- Kevin
>
>
> On 7/22/2025 8:21 PM, Paul Furbacher wrote:
>> I want to investigate fixing what I consider a bug or deficiency in a
>> particular control in the easiest manner possible.
>>
>> Initially, I thought to just build everything, but that hasn?t worked
>> because I run into an issue with native compilation, notably in
>> ?:graphics:ccMacGlass?.
>>
>> Instead of battling gradle to build the whole shebang, it seems to me
>> it would be much quicker to simply patch an existing distribution.
>> Browsing ?build.gradle?, nothing jumps out at me.
>>
>> Is it possible to just patch a published distribution with a ?fixed?
>> javafx.controls jar?
>>
>> (Leave jmods out of the picture for the moment because I?ll initially
>> use javafx on the classpath. If my idea of a fix pans out, then I?d
>> proceed with filing a bug report with suggested changes, and maybe
>> doing a pull request ? that?s for later.)
>>
>> If that?s not possible, I might be back here asking for help
>> diagnosing what?s causing clang to finish with a non-zero exit value
>>
>>
>> Regards,
>>
>> Paul Furbacher
>>
>

From jhendrikx at openjdk.org  Wed Jul 23 15:52:16 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 23 Jul 2025 15:52:16 GMT
Subject: [jfx25] RFR: 8362873: Regression in BorderPane after JDK-8350149
Message-ID: <VUqjICLRTVEvGCj4wGqvOmHZqv6JfeR9Kx7FisHfvD8=.eda8afe2-630e-4936-979a-7f731b0ad5a3@github.com>

This pull request contains a backport of commit [7b59ebce](https://github.com/openjdk/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by John Hendrikx on 23 Jul 2025 and was reviewed by Andy Goryachev, Michael Strau? and Kevin Rushforth.

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

Commit messages:
 - Backport 7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb

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

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

From kcr at openjdk.org  Wed Jul 23 16:35:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 16:35:06 GMT
Subject: [jfx25] RFR: 8362873: Regression in BorderPane after JDK-8350149
In-Reply-To: <VUqjICLRTVEvGCj4wGqvOmHZqv6JfeR9Kx7FisHfvD8=.eda8afe2-630e-4936-979a-7f731b0ad5a3@github.com>
References: <VUqjICLRTVEvGCj4wGqvOmHZqv6JfeR9Kx7FisHfvD8=.eda8afe2-630e-4936-979a-7f731b0ad5a3@github.com>
Message-ID: <F99ejq6SgWzeavBE75X2u45W_nPAv9Myx2EorWDo2Kk=.49d9f89c-49dc-4dba-bbcb-917ee457abaf@github.com>

On Wed, 23 Jul 2025 15:43:32 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This pull request contains a backport of commit [7b59ebce](https://github.com/openjdk/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by John Hendrikx on 23 Jul 2025 and was reviewed by Andy Goryachev, Michael Strau? and Kevin Rushforth.

OK to backport to jfx25. One reviewer is sufficient.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1852#pullrequestreview-3048212785

From angorya at openjdk.org  Wed Jul 23 16:39:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 23 Jul 2025 16:39:04 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <_HslBikl0XnTaElWSJmhIvomPC-pkPXBdsHTqJu4jLQ=.3874dadf-4a94-4ae8-839a-a06f8e537d29@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/layout/HeaderButtonBehavior.java line 73:

> 71: 
> 72:         if (type == HeaderButtonType.MAXIMIZE) {
> 73:             subscription = Subscription.combine(subscription,

here and on L66 the `subscription` pointer (set in L61) gets overwritten.  does it mean some subscription(s) won't be cancelled in `dispose()`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1831#discussion_r2226122084

From zjx001202 at gmail.com  Wed Jul 23 17:41:04 2025
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 24 Jul 2025 01:41:04 +0800
Subject: Some feature requests/improvement suggestions for the JavaFX Font
 API
In-Reply-To: <CAJL5A3mM7A_nJTPzduzZoqiPgAaQMLcOrY_zWOj+y-pmqWXnpg@mail.gmail.com>
References: <CAJL5A3mM7A_nJTPzduzZoqiPgAaQMLcOrY_zWOj+y-pmqWXnpg@mail.gmail.com>
Message-ID: <CAJL5A3m_9kWCc1W+7s9qV_hEkGjKCipaimKw51HWkGrqNskY+g@mail.gmail.com>

Has anyone seen this email?

Glavo

On Mon, Jul 21, 2025 at 2:29?AM Glavo <zjx001202 at gmail.com> wrote:

> Hi,
>
> We noticed that the Font API had many bugs and inconsistencies, and was
> missing a lot of functionality.
> Unfortunately, I don't have enough knowledge in this field to solve them.
> So I'm making some feature requests/improvement suggestions on this to see
> if anyone is interested.
>
> 1. Unify the meaning of "font family".
>
> Currently "font family" has different meanings on different platforms:
>
>    - On Windows, it usually means the localized name of the font family
>    name (nameID=1);
>    - On Linux,  it usually means the non-localized font family name
>    (nameID=1, langID=0x0);
>    - On macOS,  it usually means the non-localized typographical family
>    name (nameID=16, langID=0x0).
>
> This inconsistency makes the behavior of the program confusing and it is
> impossible to know what will happen without testing on multiple platforms.
>
> I want JavaFX to use the non-localized typographical family name
> (nameID=16, langID=0x0) on all platforms.
> The reason is that the font family name (nameID=1) of many fonts actually
> contains the font style information,
> and using it makes it difficult for us to select font style.
>
> For example, if we want to get JetBrains Mono Bold on Windows, we need to
> use Font.font("JetBrains Mono", FontWeight.BOLD, 13),
> but to get JetBrains Mono ExtraBold, we need to use Font.font("JetBrains
> Mono ExtraBold", FontWeight.NORMAL, 13).
> This is really frustrating :(
>
> Additionally, I encountered a bug on macOS that prevented me from
> selecting the font weight.
> I explained this issue in a previous email:
> https://mail.openjdk.org/pipermail/openjfx-dev/2025-July/055417.html
>
> 2. Make Font.font(String) accept both font name and font family name.
>
> I wish Font.font(String) could accept more names than just the font
> family name.
>
> As mentioned in the previous section, the current concept of font family
> names in JavaFX is confusing and often contains font style information.
> Therefore, it is very difficult to use the Font.font(String) in the
> correct way.
> If it would accept a variety of font names, both localized and
> non-localized, it would be less difficult to use.
>
> 3. Add more methods to get font localized names
>
> I would like to get these methods in Font class to get the localized name
> of the font:
>
>    - static Map<Locale, String> getLocalizedFamilyNames(String family)
>    - static String getLocalizedFamilyName(String family, Locale locale)
>    - static String getLocalizedFontNames(Locale locale)
>    - static String getLocalizedFontNames(String family, Locale locale)
>    - Map<Locale, String> getLocalizedNames()
>    - String getLocalizedName(Locale locale)
>    - Map<Locale, String> getLocalizedFamily()
>    - String getLocalizedFamily(Locale locale)
>
> 4. More methods for handling font styles
>
> Right now we can only use FontWeight and FontPosture to select a font
> style when looking up a font,
> but the only way to get the style from a given Font object is
> Font::getStyle(), which is very asymmetrical.
>
> I would like to get these methods to handle font styles:
>
>    - static List<String> getStyles(String family)
>    - static Font font(String family, String style)
>    - FontWeight getWeight()
>    - FontPosture getPosture()
>
> 5. Support fallback fonts and CSS font list for UI controls
> 6. Provides a way to control the typographic features of fonts
>       Refer to Flutter's FontFeature class:
> https://api.flutter.dev/flutter/dart-ui/FontFeature-class.html
>
> Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/b9d37dfd/attachment-0001.htm>

From martinfox656 at gmail.com  Wed Jul 23 18:57:01 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 23 Jul 2025 11:57:01 -0700
Subject: Is there an easier way to "fix" a control instead of building
 everything (i.e., java, native, etc.)?
In-Reply-To: <a6c4d03e-b736-400c-a7c3-db6097e09489@oracle.com>
References: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com>
 <a6c4d03e-b736-400c-a7c3-db6097e09489@oracle.com>
Message-ID: <808CADC5-D264-4D5D-B3B3-C46A164350AC@gmail.com>

The most likely reason for a Mac Glass compilation error is using Xcode 16 to build an older version of JavaFX (anything before PR #1812 was integrated in May of this year). Xcode 16 enabled a new check which caught an old type mismatch error in GlassTouches.m.

If that?s what you?re seeing you can either grab the latest master or just cut out enough code in GlassTouches.m to get it to compile. The event tap that drove GlassTouches was disabled years ago so it?s all dead code. The May PR removed it entirely.

Martin

> On Jul 23, 2025, at 6:34?AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> [redirecting to openjfx-dev]
> 
> You will need to build all of JavaFX using gradle.
> 
> You might be running into an issue with the version of Xcode you are using. You will need macOS 14 or 15 with a recent version of Xcode. We use Xcode 15.4 for our production builds.
> 
> Can you list the version of macOS and Xcode you are using? And copy/paste the specific error message(s) you see?
> 
> -- Kevin
> 
> 
> On 7/22/2025 8:21 PM, Paul Furbacher wrote:
>> I want to investigate fixing what I consider a bug or deficiency in a particular control in the easiest manner possible.
>> 
>> Initially, I thought to just build everything, but that hasn?t worked because I run into an issue with native compilation, notably in ?:graphics:ccMacGlass?.
>> 
>> Instead of battling gradle to build the whole shebang, it seems to me it would be much quicker to simply patch an existing distribution. Browsing ?build.gradle?, nothing jumps out at me.
>> 
>> Is it possible to just patch a published distribution with a ?fixed? javafx.controls jar?
>> 
>> (Leave jmods out of the picture for the moment because I?ll initially use javafx on the classpath. If my idea of a fix pans out, then I?d proceed with filing a bug report with suggested changes, and maybe doing a pull request ? that?s for later.)
>> 
>> If that?s not possible, I might be back here asking for help diagnosing what?s causing clang to finish with a non-zero exit value
>> 
>> 
>> Regards,
>> 
>> Paul Furbacher
>> 
> 


From andy.goryachev at oracle.com  Wed Jul 23 19:30:01 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 23 Jul 2025 19:30:01 +0000
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
 <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
Message-ID: <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>

Do we have the JBS ticket filed for this issue?

-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac Redmond <credmond at certak.com>
Date: Tuesday, July 22, 2025 at 12:08
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Bug: ToolBar always using overflow menu whenever a scaled resolution set

Any thoughts on this? It seems like a definite JavaFX bug with hopefully a simple fix. Choosing any fractional scaled resolution may or may not cause the issue. I also wonder what other controls may suffer from the same issues.

On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi,

I've traced the bug down to a rounding error. See the below screenshot in ToolBarSkin's getOverflowNodeIndex(double length).

These two numbers are not equal, but should be. snapSizeX() ultimately ends up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1 (i.e., no scaling), we don't see this issue. If it's 1.25, we see this rounding difference between the two numbers in this instance. If these two numbers are not equal, the calling code mistakenly assumes the overflow box is necessary.

[cid:ii_mdajteh84]

Can someone fix this?



Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Confusingly, make the string longer, such as "Create Schema 123 123 123":

        bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123 123"))));

...and the overflow doesn't appear (but still, anything between and including 13-24, it does):

[cid:ii_mdaiye703]




Kind Regards,
Cormac

On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi,

There's a bug whenever using a ToolBar on Windows if you set your resolution scale > 100% (which is quite common). E.g., 125%:

[cid:ii_mda2w6ew0]

E.g., this is what a ToolBar always renders if scale is 125%:

[cid:ii_mda2y4u71]

As compared to what you'd expect (scale set to normal/100%):

[cid:ii_mda306hd2]

Very easy to reproduce the above, set your scale to 125% and run this:

public class ToolbarBugApp extends Application {

    @Override
    public void start(Stage primaryStage) {
        BorderPane bp = new BorderPane();
        // Wrapping in HBox and using button with 13+ chars causes bug
        bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); // BUG
        // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG (no HBox)
        // bp.setTop(new HBox(new ToolBar(new Button("Create Schem")))); // NO BUG (12 chars)
        primaryStage.setScene(new Scene(bp, 600, 400));
        primaryStage.show();
    }

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

As per the comments, this bug appears to happen when your ToolBar is wrapped in a HBox and contains a Button that has 13+ characters, for example. This is quite a serious bug, in my opinion.

I believe this is present in JFX 24 and the JFX 25 master branch.


Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<http://www.certak.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: image.png
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/3225ec76/image-0009.png>

From mfox at openjdk.org  Wed Jul 23 20:52:03 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 23 Jul 2025 20:52:03 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
Message-ID: <3RKQkLDmwzIraYxSW1PYT9LWygXOrVhkDYSd8jE_RvQ=.aaa929f9-7900-402c-94b8-93e25d5eaff5@github.com>

On Thu, 17 Jul 2025 09:18:42 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust error message for window-on-top check

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 208:

> 206:                 for (int y = 0; y < STAGE_SIZE; ++y) {
> 207:                     Color color = captureReader.getColor(x, y);
> 208:                     assertTrue(checkColorEquals(SCENE_COLOR, color, TOLERANCE),

It looks like this assertion is executed in the JavaFX thread instead of the JUnit testing thread. Is this officially supported? Seems to be working in my testing.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2226478846

From credmond at certak.com  Wed Jul 23 22:17:48 2025
From: credmond at certak.com (Cormac Redmond)
Date: Wed, 23 Jul 2025 23:17:48 +0100
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
 <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
 <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>
Message-ID: <CAG_-AaCoBdRWyJZka_aRZsZ-23NCf=im=R+m7fJ7jfwtrOnvxg@mail.gmail.com>

I've a habit of finding non-bugs, so prefer to discuss it first to get some
feedback (and/or to avoid duplicating known bugs), but I assume this is
definitely an issue, so I created it on JBS now: 9078765...

Unfortunately one cannot attach screenshots on JBS submissions, so a text
description will have to do.

Thanks!


Kind Regards,
Cormac

On Wed, 23 Jul 2025 at 20:30, Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Do we have the JBS ticket filed for this issue?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac
> Redmond <credmond at certak.com>
> *Date: *Tuesday, July 22, 2025 at 12:08
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Bug: ToolBar always using overflow menu whenever a scaled
> resolution set
>
> Any thoughts on this? It seems like a definite JavaFX bug with hopefully a
> simple fix. Choosing any fractional scaled resolution may or may not cause
> the issue. I also wonder what other controls may suffer from the same
> issues.
>
>
>
> On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com> wrote:
>
> Hi,
>
>
>
> I've traced the bug down to a rounding error. See the below screenshot in
> ToolBarSkin's getOverflowNodeIndex(double length).
>
>
>
> These two numbers are not equal, but should be. snapSizeX() ultimately
> ends up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1
> (i.e., no scaling), we don't see this issue. If it's 1.25, we see this
> rounding difference between the two numbers in this instance. If these two
> numbers are not equal, the calling code mistakenly assumes the overflow box
> is necessary.
>
>
>
>
>
> Can someone fix this?
>
>
>
>
>
>
>
> Kind Regards,
>
> Cormac
>
>
>
> On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com> wrote:
>
> Confusingly, make the string longer, such as "Create Schema 123 123 123":
>
>
>
>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123
> 123"))));
>
>
>
> ...and the overflow doesn't appear (but still, anything between and
> including 13-24, it does):
>
>
>
>
>
>
>
>
>
>
>
> Kind Regards,
>
> Cormac
>
>
>
> On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com> wrote:
>
> Hi,
>
>
>
> There's a bug whenever using a ToolBar on Windows if you set your
> resolution scale > 100% (which is quite common). E.g., 125%:
>
>
>
>
>
> E.g., this is what a ToolBar always renders if scale is 125%:
>
>
>
>
>
> As compared to what you'd expect (scale set to normal/100%):
>
>
>
>
>
> Very easy to reproduce the above, set your scale to 125% and run this:
>
>
>
> public class ToolbarBugApp extends Application {
>
>
>     @Override
>     public void start(Stage primaryStage) {
>         BorderPane bp = new BorderPane();
>         // Wrapping in HBox and using button with 13+ chars causes bug
>         bp.setTop(new HBox(new ToolBar(new Button("Create Schema")))); //
> BUG
>         // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
> (no HBox)
>         // bp.setTop(new HBox(new ToolBar(new Button("Create Schem"))));
> // NO BUG (12 chars)
>         primaryStage.setScene(new Scene(bp, 600, 400));
>         primaryStage.show();
>     }
>
>     public static void main(String[] args) {
>         launch(args);
>     }
> }
>
>
>
> As per the comments, this bug appears to happen when your ToolBar is
> wrapped in a HBox and contains a Button that has 13+ characters, for
> example. This is quite a serious bug, in my opinion.
>
>
>
> I believe this is present in JFX 24 and the JFX 25 master branch.
>
>
>
>
>
> Kind Regards,
>
>
>
> *Cormac Redmond*
>
> Software Engineer, Certak Ltd.
>
>
>
> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250723/e8b816e0/image-0009.png>

From arapte at openjdk.org  Wed Jul 23 23:41:01 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 23 Jul 2025 23:41:01 GMT
Subject: Integrated: 8363813: Missing null check in GlassScreen
In-Reply-To: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
References: <Gchs9ot8qzIgs933Zvx9-MJlPWTNkd59eZ_f7XEYbZ4=.94c1d2df-3e6f-4c1c-94c9-91688c01abfa@github.com>
Message-ID: <Z3AaZY0Iz8-me4lj68lp8mmGQK99kLA8C94U_q8YZ_g=.426dcdaf-4f52-41dd-abac-137c73292ed7@github.com>

On Tue, 22 Jul 2025 17:28:22 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The JNI method NewObjectArray may return null, so a null check should be added as a precaution in methods that creates an array of Screens.

This pull request has now been integrated.

Changeset: dbd43a37
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/dbd43a371a2460c3cf8aed108d349b301bd2a1b2
Stats:     31 lines in 4 files changed: 10 ins; 4 del; 17 mod

8363813: Missing null check in GlassScreen

Reviewed-by: kcr, kizune, jvos, jdv

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

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

From arapte at openjdk.org  Wed Jul 23 23:50:35 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 23 Jul 2025 23:50:35 GMT
Subject: [jfx25] RFR: 8363813: Missing null check in GlassScreen
Message-ID: <vPgTVPKo6LnlVUvcLecnQQdIGgXVmWXBnA99oGzaOHE=.4aa64bae-2e1a-4541-a6f7-db5d51c11db3@github.com>

Clean backport of adding simple null checks in glass screen fix to the `jfx25` stabilization branch.

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

Commit messages:
 - Backport dbd43a371a2460c3cf8aed108d349b301bd2a1b2

Changes: https://git.openjdk.org/jfx/pull/1854/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1854&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8363813
  Stats: 31 lines in 4 files changed: 10 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1854.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1854/head:pull/1854

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

From kcr at openjdk.org  Thu Jul 24 02:02:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 02:02:06 GMT
Subject: [jfx25] RFR: 8363813: Missing null check in GlassScreen
In-Reply-To: <vPgTVPKo6LnlVUvcLecnQQdIGgXVmWXBnA99oGzaOHE=.4aa64bae-2e1a-4541-a6f7-db5d51c11db3@github.com>
References: <vPgTVPKo6LnlVUvcLecnQQdIGgXVmWXBnA99oGzaOHE=.4aa64bae-2e1a-4541-a6f7-db5d51c11db3@github.com>
Message-ID: <m-7Cti3YAx19n-zpHUHcZ5cBCROjpwBAxnx5NnXjpcw=.11c577ae-794c-4a57-910f-27377be581ee@github.com>

On Wed, 23 Jul 2025 23:45:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Clean backport of adding simple null checks in glass screen fix to the `jfx25` stabilization branch.

Looks good to go into jfx25.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1854#pullrequestreview-3049726975

From jhendrikx at openjdk.org  Thu Jul 24 02:38:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 24 Jul 2025 02:38:00 GMT
Subject: [jfx25] Integrated: 8362873: Regression in BorderPane after
 JDK-8350149
In-Reply-To: <VUqjICLRTVEvGCj4wGqvOmHZqv6JfeR9Kx7FisHfvD8=.eda8afe2-630e-4936-979a-7f731b0ad5a3@github.com>
References: <VUqjICLRTVEvGCj4wGqvOmHZqv6JfeR9Kx7FisHfvD8=.eda8afe2-630e-4936-979a-7f731b0ad5a3@github.com>
Message-ID: <qhccM4eFpRxPumDuJ0xjH3W1qJOzNd-sGQ2Ytuon8lc=.de15cdf8-a6cb-4fb6-9a72-94198fd01297@github.com>

On Wed, 23 Jul 2025 15:43:32 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This pull request contains a backport of commit [7b59ebce](https://github.com/openjdk/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by John Hendrikx on 23 Jul 2025 and was reviewed by Andy Goryachev, Michael Strau? and Kevin Rushforth.

This pull request has now been integrated.

Changeset: 3293ed8c
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3293ed8cbf887db1216fb415343ada9c6f859209
Stats:     50 lines in 2 files changed: 37 ins; 0 del; 13 mod

8362873: Regression in BorderPane after JDK-8350149

Reviewed-by: kcr
Backport-of: 7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb

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

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

From arapte at openjdk.org  Thu Jul 24 04:21:58 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 24 Jul 2025 04:21:58 GMT
Subject: [jfx25] Integrated: 8363813: Missing null check in GlassScreen
In-Reply-To: <vPgTVPKo6LnlVUvcLecnQQdIGgXVmWXBnA99oGzaOHE=.4aa64bae-2e1a-4541-a6f7-db5d51c11db3@github.com>
References: <vPgTVPKo6LnlVUvcLecnQQdIGgXVmWXBnA99oGzaOHE=.4aa64bae-2e1a-4541-a6f7-db5d51c11db3@github.com>
Message-ID: <2hzDXvEU2rQHj1uSvmD_LvabMmXq3N-gWQ4XDai_lLc=.5cb8e469-391e-41c1-97fc-7687e44b1274@github.com>

On Wed, 23 Jul 2025 23:45:12 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Clean backport of adding simple null checks in glass screen fix to the `jfx25` stabilization branch.

This pull request has now been integrated.

Changeset: b60486c4
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b60486c4ead35f776d1a7580dc6f55769b780804
Stats:     31 lines in 4 files changed: 10 ins; 4 del; 17 mod

8363813: Missing null check in GlassScreen

Reviewed-by: kcr
Backport-of: dbd43a371a2460c3cf8aed108d349b301bd2a1b2

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

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

From nlisker at gmail.com  Thu Jul 24 04:26:43 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 24 Jul 2025 07:26:43 +0300
Subject: Some feature requests/improvement suggestions for the JavaFX Font
 API
In-Reply-To: <CAJL5A3m_9kWCc1W+7s9qV_hEkGjKCipaimKw51HWkGrqNskY+g@mail.gmail.com>
References: <CAJL5A3mM7A_nJTPzduzZoqiPgAaQMLcOrY_zWOj+y-pmqWXnpg@mail.gmail.com>
 <CAJL5A3m_9kWCc1W+7s9qV_hEkGjKCipaimKw51HWkGrqNskY+g@mail.gmail.com>
Message-ID: <CA+0ynh9ZGBeR_xxsVYctRuOFCYbWJyFysnLBsdpR+Q+0-iWceA@mail.gmail.com>

Yes, but I don't know much about the font area. Also, "Christmas shopping
lists" can be difficult to respond to. You'll need to wait for someone who
has input.

On Wed, Jul 23, 2025 at 8:41?PM Glavo <zjx001202 at gmail.com> wrote:

> Has anyone seen this email?
>
> Glavo
>
> On Mon, Jul 21, 2025 at 2:29?AM Glavo <zjx001202 at gmail.com> wrote:
>
>> Hi,
>>
>> We noticed that the Font API had many bugs and inconsistencies, and was
>> missing a lot of functionality.
>> Unfortunately, I don't have enough knowledge in this field to solve them.
>> So I'm making some feature requests/improvement suggestions on this to
>> see if anyone is interested.
>>
>> 1. Unify the meaning of "font family".
>>
>> Currently "font family" has different meanings on different platforms:
>>
>>    - On Windows, it usually means the localized name of the font family
>>    name (nameID=1);
>>    - On Linux,  it usually means the non-localized font family name
>>    (nameID=1, langID=0x0);
>>    - On macOS,  it usually means the non-localized typographical family
>>    name (nameID=16, langID=0x0).
>>
>> This inconsistency makes the behavior of the program confusing and it is
>> impossible to know what will happen without testing on multiple platforms.
>>
>> I want JavaFX to use the non-localized typographical family name
>> (nameID=16, langID=0x0) on all platforms.
>> The reason is that the font family name (nameID=1) of many fonts actually
>> contains the font style information,
>> and using it makes it difficult for us to select font style.
>>
>> For example, if we want to get JetBrains Mono Bold on Windows, we need to
>> use Font.font("JetBrains Mono", FontWeight.BOLD, 13),
>> but to get JetBrains Mono ExtraBold, we need to use Font.font("JetBrains
>> Mono ExtraBold", FontWeight.NORMAL, 13).
>> This is really frustrating :(
>>
>> Additionally, I encountered a bug on macOS that prevented me from
>> selecting the font weight.
>> I explained this issue in a previous email:
>> https://mail.openjdk.org/pipermail/openjfx-dev/2025-July/055417.html
>>
>> 2. Make Font.font(String) accept both font name and font family name.
>>
>> I wish Font.font(String) could accept more names than just the font
>> family name.
>>
>> As mentioned in the previous section, the current concept of font family
>> names in JavaFX is confusing and often contains font style information.
>> Therefore, it is very difficult to use the Font.font(String) in the
>> correct way.
>> If it would accept a variety of font names, both localized and
>> non-localized, it would be less difficult to use.
>>
>> 3. Add more methods to get font localized names
>>
>> I would like to get these methods in Font class to get the localized
>> name of the font:
>>
>>    - static Map<Locale, String> getLocalizedFamilyNames(String family)
>>    - static String getLocalizedFamilyName(String family, Locale locale)
>>    - static String getLocalizedFontNames(Locale locale)
>>    - static String getLocalizedFontNames(String family, Locale locale)
>>    - Map<Locale, String> getLocalizedNames()
>>    - String getLocalizedName(Locale locale)
>>    - Map<Locale, String> getLocalizedFamily()
>>    - String getLocalizedFamily(Locale locale)
>>
>> 4. More methods for handling font styles
>>
>> Right now we can only use FontWeight and FontPosture to select a font
>> style when looking up a font,
>> but the only way to get the style from a given Font object is
>> Font::getStyle(), which is very asymmetrical.
>>
>> I would like to get these methods to handle font styles:
>>
>>    - static List<String> getStyles(String family)
>>    - static Font font(String family, String style)
>>    - FontWeight getWeight()
>>    - FontPosture getPosture()
>>
>> 5. Support fallback fonts and CSS font list for UI controls
>> 6. Provides a way to control the typographic features of fonts
>>       Refer to Flutter's FontFeature class:
>> https://api.flutter.dev/flutter/dart-ui/FontFeature-class.html
>>
>> Glavo
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/b6b2c8cb/attachment.htm>

From kcr at openjdk.org  Thu Jul 24 11:58:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 11:58:03 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <3RKQkLDmwzIraYxSW1PYT9LWygXOrVhkDYSd8jE_RvQ=.aaa929f9-7900-402c-94b8-93e25d5eaff5@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
 <3RKQkLDmwzIraYxSW1PYT9LWygXOrVhkDYSd8jE_RvQ=.aaa929f9-7900-402c-94b8-93e25d5eaff5@github.com>
Message-ID: <Y3tR55_pGIFV69E8b0L9NRDZPBX_taCuSeFQ6jJCnX4=.9ea70093-6f9a-46b3-88f2-589a82764071@github.com>

On Wed, 23 Jul 2025 19:40:20 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust error message for window-on-top check
>
> tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 208:
> 
>> 206:                 for (int y = 0; y < STAGE_SIZE; ++y) {
>> 207:                     Color color = captureReader.getColor(x, y);
>> 208:                     assertTrue(checkColorEquals(SCENE_COLOR, color, TOLERANCE),
> 
> It looks like this assertion is executed in the JavaFX thread instead of the JUnit testing thread. Is this officially supported? Seems to be working in my testing.

Yes, this is supported. The `Util.runAndWait` method catches all Throwables and re-throws them to the calling thread.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2228300644

From kevin.rushforth at oracle.com  Thu Jul 24 14:15:13 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 24 Jul 2025 07:15:13 -0700
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <CAG_-AaCoBdRWyJZka_aRZsZ-23NCf=im=R+m7fJ7jfwtrOnvxg@mail.gmail.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
 <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
 <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaCoBdRWyJZka_aRZsZ-23NCf=im=R+m7fJ7jfwtrOnvxg@mail.gmail.com>
Message-ID: <b8be6f75-6665-4a51-948c-03288f46a56d@oracle.com>

This does look like a real bug. Thanks for filing it.

> Unfortunately one cannot attach screenshots on JBS submissions, so a 
> text description will have to do.

I have attached the two images to the bug. It will show up publicly, 
with a JDK bug ID, soon.

-- Kevin


On 7/23/2025 3:17 PM, Cormac Redmond wrote:
> I've a habit of finding non-bugs, so prefer to discuss it first to get 
> some feedback (and/or to avoid duplicating known bugs), but I assume 
> this is definitely an issue, so I created it on JBS now: 9078765...
>
> Unfortunately one cannot attach screenshots on JBS submissions, so a 
> text description will have to do.
>
> Thanks!
>
>
> Kind Regards,
> Cormac
>
> On Wed, 23 Jul 2025 at 20:30, Andy Goryachev 
> <andy.goryachev at oracle.com> wrote:
>
>     Do we have the JBS ticket filed for this issue?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of
>     Cormac Redmond <credmond at certak.com>
>     *Date: *Tuesday, July 22, 2025 at 12:08
>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>     *Subject: *Re: Bug: ToolBar always using overflow menu whenever a
>     scaled resolution set
>
>     Any thoughts on this? It seems like a definite JavaFX bug with
>     hopefully a simple fix. Choosing any fractional scaled resolution
>     may or may not cause the issue. I also wonder what other controls
>     may suffer from the same issues.
>
>     On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com> wrote:
>
>         Hi,
>
>         I've traced the bug down to a rounding error. See the below
>         screenshot in ToolBarSkin's?getOverflowNodeIndex(double length).
>
>         These two numbers are not equal, but should be. snapSizeX()
>         ultimately ends up grabbing getSnapScaleX(), whose value would
>         be 1.25. If it's 1 (i.e., no scaling), we don't see this
>         issue. If it's 1.25, we see this rounding?difference between
>         the two numbers in this instance. If these two numbers are not
>         equal, the calling code mistakenly assumes the overflow box is
>         necessary.
>
>         Can someone fix this?
>
>         Kind Regards,
>
>         Cormac
>
>         On Sat, 19 Jul 2025 at 18:33, Cormac Redmond
>         <credmond at certak.com> wrote:
>
>             Confusingly, make the string longer, such as "Create
>             Schema 123 123 123":
>
>             bp.setTop(new HBox(new ToolBar(new Button("Create Schema
>             123 123 123"))));
>
>             ...and the overflow doesn't appear (but still, anything
>             between and including 13-24, it does):
>
>             Kind Regards,
>
>             Cormac
>
>             On Sat, 19 Jul 2025 at 11:12, Cormac Redmond
>             <credmond at certak.com> wrote:
>
>                 Hi,
>
>                 There's a bug whenever using a ToolBar on Windows if
>                 you set your resolution scale > 100% (which is quite
>                 common). E.g., 125%:
>
>                 E.g., this is what a ToolBar always renders if scale
>                 is 125%:
>
>                 As compared to what you'd expect (scale set to
>                 normal/100%):
>
>                 Very easy to reproduce the above, set your scale to
>                 125% and run this:
>
>                 public class ToolbarBugApp extends Application {
>
>
>                 ? ? @Override
>                 ? ? public void start(Stage primaryStage) {
>                 ? ? ? ? BorderPane bp = new BorderPane();
>                 ? ? ? ? // Wrapping in HBox and using button with 13+
>                 chars causes bug
>                 ? ? ? ? bp.setTop(new HBox(new ToolBar(new
>                 Button("Create Schema")))); // BUG
>                 ? ? ? ? // bp.setTop(new ToolBar(new Button("Create
>                 Schema"))); // NO BUG(no HBox)
>                 ? ? ? ? // bp.setTop(new HBox(new ToolBar(new
>                 Button("Create Schem")))); // NO BUG(12 chars)
>                 primaryStage.setScene(new Scene(bp, 600, 400));
>                 ? ? ? ? primaryStage.show();
>                 ? ? }
>
>                 ? ? public static void main(String[] args) {
>                 ? ? ? ? launch(args);
>                 ? ? }
>                 }
>
>                 As per the comments, this bug appears to happen when
>                 your ToolBar is wrapped in a HBox and contains a
>                 Button that has 13+ characters, for example. This is
>                 quite a serious bug, in my opinion.
>
>                 I believe this is present in JFX 24 and the JFX 25
>                 master branch.
>
>                 Kind Regards,
>
>                 *Cormac Redmond*
>
>                 Software Engineer, Certak Ltd.
>
>                 e: credmond at certak.com | m: +353 (0) 86 268 2152 | w:
>                 www.certak.com <http://www.certak.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/44b05f57/image-0009.png>

From kevin.rushforth at oracle.com  Thu Jul 24 15:10:49 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 24 Jul 2025 08:10:49 -0700
Subject: Bug: ToolBar always using overflow menu whenever a scaled
 resolution set
In-Reply-To: <b8be6f75-6665-4a51-948c-03288f46a56d@oracle.com>
References: <CAGBnJPvxyDqSjOpgqjWpBWjma7-efw_tO1acS3JREn88KurotA@mail.gmail.com>
 <CAG_-AaAKwyk3-kPQEeNgSt4S2UBgSoSXedMaEbfW3=PokEk23w@mail.gmail.com>
 <CAG_-AaAg=pKDvrtLCqRkU1gzvDMY=vuK9DHKyS-APd2j3bhywA@mail.gmail.com>
 <CAG_-AaCpxq9Vn8bQCvkoNZKW590V5sEnXUtwQJj7q_5Oe3a5sQ@mail.gmail.com>
 <CY8PR10MB7265157823D211B6AE764448E55FA@CY8PR10MB7265.namprd10.prod.outlook.com>
 <CAG_-AaCoBdRWyJZka_aRZsZ-23NCf=im=R+m7fJ7jfwtrOnvxg@mail.gmail.com>
 <b8be6f75-6665-4a51-948c-03288f46a56d@oracle.com>
Message-ID: <52a3bca8-1ade-45d1-851c-4d8d9bba22d7@oracle.com>

https://bugs.openjdk.org/browse/JDK-8364049


On 7/24/2025 7:15 AM, Kevin Rushforth wrote:
> This does look like a real bug. Thanks for filing it.
>
>> Unfortunately one cannot attach screenshots on JBS submissions, so a 
>> text description will have to do.
>
> I have attached the two images to the bug. It will show up publicly, 
> with a JDK bug ID, soon.
>
> -- Kevin
>
>
> On 7/23/2025 3:17 PM, Cormac Redmond wrote:
>> I've a habit of finding non-bugs, so prefer to discuss it first to 
>> get some feedback (and/or to avoid duplicating known bugs), but I 
>> assume this is definitely an issue, so I created it on JBS now: 
>> 9078765...
>>
>> Unfortunately one cannot attach screenshots on JBS submissions, so a 
>> text description will have to do.
>>
>> Thanks!
>>
>>
>> Kind Regards,
>> Cormac
>>
>> On Wed, 23 Jul 2025 at 20:30, Andy Goryachev 
>> <andy.goryachev at oracle.com> wrote:
>>
>>     Do we have the JBS ticket filed for this issue?
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of
>>     Cormac Redmond <credmond at certak.com>
>>     *Date: *Tuesday, July 22, 2025 at 12:08
>>     *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>     *Subject: *Re: Bug: ToolBar always using overflow menu whenever a
>>     scaled resolution set
>>
>>     Any thoughts on this? It seems like a definite JavaFX bug with
>>     hopefully a simple fix. Choosing any fractional scaled resolution
>>     may or may not cause the issue. I also wonder what other controls
>>     may suffer from the same issues.
>>
>>     On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com>
>>     wrote:
>>
>>         Hi,
>>
>>         I've traced the bug down to a rounding error. See the below
>>         screenshot in ToolBarSkin's?getOverflowNodeIndex(double length).
>>
>>         These two numbers are not equal, but should be. snapSizeX()
>>         ultimately ends up grabbing getSnapScaleX(), whose value
>>         would be 1.25. If it's 1 (i.e., no scaling), we don't see
>>         this issue. If it's 1.25, we see this rounding?difference
>>         between the two numbers in this instance. If these two
>>         numbers are not equal, the calling code mistakenly assumes
>>         the overflow box is necessary.
>>
>>         Can someone fix this?
>>
>>         Kind Regards,
>>
>>         Cormac
>>
>>         On Sat, 19 Jul 2025 at 18:33, Cormac Redmond
>>         <credmond at certak.com> wrote:
>>
>>             Confusingly, make the string longer, such as "Create
>>             Schema 123 123 123":
>>
>>             bp.setTop(new HBox(new ToolBar(new Button("Create Schema
>>             123 123 123"))));
>>
>>             ...and the overflow doesn't appear (but still, anything
>>             between and including 13-24, it does):
>>
>>             Kind Regards,
>>
>>             Cormac
>>
>>             On Sat, 19 Jul 2025 at 11:12, Cormac Redmond
>>             <credmond at certak.com> wrote:
>>
>>                 Hi,
>>
>>                 There's a bug whenever using a ToolBar on Windows if
>>                 you set your resolution scale > 100% (which is quite
>>                 common). E.g., 125%:
>>
>>                 E.g., this is what a ToolBar always renders if scale
>>                 is 125%:
>>
>>                 As compared to what you'd expect (scale set to
>>                 normal/100%):
>>
>>                 Very easy to reproduce the above, set your scale to
>>                 125% and run this:
>>
>>                 public class ToolbarBugApp extends Application {
>>
>>
>>                 ? ? @Override
>>                 ? ? public void start(Stage primaryStage) {
>>                 ? ? ? ? BorderPane bp = new BorderPane();
>>                 ? ? ? ? // Wrapping in HBox and using button with 13+
>>                 chars causes bug
>>                 ? ? ? ? bp.setTop(new HBox(new ToolBar(new
>>                 Button("Create Schema")))); // BUG
>>                 ? ? ? ? // bp.setTop(new ToolBar(new Button("Create
>>                 Schema"))); // NO BUG(no HBox)
>>                 ? ? ? ? // bp.setTop(new HBox(new ToolBar(new
>>                 Button("Create Schem")))); // NO BUG(12 chars)
>>                 primaryStage.setScene(new Scene(bp, 600, 400));
>>                 ? ? ? ? primaryStage.show();
>>                 ? ? }
>>
>>                 ? ? public static void main(String[] args) {
>>                 ? ? ? ? launch(args);
>>                 ? ? }
>>                 }
>>
>>                 As per the comments, this bug appears to happen when
>>                 your ToolBar is wrapped in a HBox and contains a
>>                 Button that has 13+ characters, for example. This is
>>                 quite a serious bug, in my opinion.
>>
>>                 I believe this is present in JFX 24 and the JFX 25
>>                 master branch.
>>
>>                 Kind Regards,
>>
>>                 *Cormac Redmond*
>>
>>                 Software Engineer, Certak Ltd.
>>
>>                 e: credmond at certak.com | m: +353 (0) 86 268 2152 | w:
>>                 www.certak.com <http://www.certak.com>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/image-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/image-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/image-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250724/ee679d6d/image-0009.png>

From kcr at openjdk.org  Thu Jul 24 21:41:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 21:41:01 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <0V4OsbjCR5ofi2bqNCb1RuAJ5m3IPPY35zfLwvacEng=.bde969c8-ac47-49a4-8d7f-e11198ff45ca@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

The code looks good. I submitted a set of headful test jobs and will report when done. I want to do a little light manual testing, especially on macOS where there are a few changes in the non-extended case (although the code looks equivalent).

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow+Java.m line 215:

> 213: }
> 214: 
> 215: - (void)_setResizable:(bool)resizable

Good. It definitely seems cleaner to pass in resizable as a parameter rather than having this method be a "toggle" resizable as it was previously.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1165:

> 1163:     {
> 1164:         GlassWindow *window = getGlassWindow(env, jPtr);
> 1165:         [window _setResizable:jResizable];

I presume you removed the `performSelectorOnMainThread` because the calling method always calls this on the main thread?

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

PR Review: https://git.openjdk.org/jfx/pull/1831#pullrequestreview-3053397171
PR Review Comment: https://git.openjdk.org/jfx/pull/1831#discussion_r2229616697
PR Review Comment: https://git.openjdk.org/jfx/pull/1831#discussion_r2229618920

From mstrauss at openjdk.org  Thu Jul 24 22:02:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 24 Jul 2025 22:02:00 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <0V4OsbjCR5ofi2bqNCb1RuAJ5m3IPPY35zfLwvacEng=.bde969c8-ac47-49a4-8d7f-e11198ff45ca@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
 <0V4OsbjCR5ofi2bqNCb1RuAJ5m3IPPY35zfLwvacEng=.bde969c8-ac47-49a4-8d7f-e11198ff45ca@github.com>
Message-ID: <JTh-_FuVU_h_ZuATpNrpaIhMZCZDf8d-Us3TpJNmSuw=.148fed8d-e1ae-4c79-861f-06567928970e@github.com>

On Thu, 24 Jul 2025 21:28:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix resizable state of macOS window
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1165:
> 
>> 1163:     {
>> 1164:         GlassWindow *window = getGlassWindow(env, jPtr);
>> 1165:         [window _setResizable:jResizable];
> 
> I presume you removed the `performSelectorOnMainThread` because the calling method always calls this on the main thread?

Yes, this is a call that always happens on the FX thread as a result of calling `javafx.stage.Window.show()`. This is verified just a few lines earlier with `GLASS_ASSERT_MAIN_JAVA_THREAD` (that's always been there, I didn't add it).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1831#discussion_r2229665362

From kcr at openjdk.org  Thu Jul 24 22:20:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 22:20:01 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <MVDTO4rgxgPX0bGOXKpP6AxrMdxTwuRWPP36FWcnB-8=.32a53551-843f-4601-924e-faa294ee85b4@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

The headful CI tests passed on Linux and macOS (I will need to manually run it on Windows).

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

PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3115149588

From kcr at openjdk.org  Thu Jul 24 22:20:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 22:20:02 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <JTh-_FuVU_h_ZuATpNrpaIhMZCZDf8d-Us3TpJNmSuw=.148fed8d-e1ae-4c79-861f-06567928970e@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
 <0V4OsbjCR5ofi2bqNCb1RuAJ5m3IPPY35zfLwvacEng=.bde969c8-ac47-49a4-8d7f-e11198ff45ca@github.com>
 <JTh-_FuVU_h_ZuATpNrpaIhMZCZDf8d-Us3TpJNmSuw=.148fed8d-e1ae-4c79-861f-06567928970e@github.com>
Message-ID: <WKNvj1KA6gklvC8mIV424NBoFjb686l00C2UGSLvi6U=.58604890-48e9-4e96-ba42-3d4db78d8cbb@github.com>

On Thu, 24 Jul 2025 21:59:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1165:
>> 
>>> 1163:     {
>>> 1164:         GlassWindow *window = getGlassWindow(env, jPtr);
>>> 1165:         [window _setResizable:jResizable];
>> 
>> I presume you removed the `performSelectorOnMainThread` because the calling method always calls this on the main thread?
>
> Yes, this is a call that always happens on the FX thread as a result of calling `javafx.stage.Window.show()`. This is verified just a few lines earlier with `GLASS_ASSERT_MAIN_JAVA_THREAD` (that's always been there, I didn't add it).

Also, the calling Java code does a thread check. So we're good.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1831#discussion_r2229693772

From pfurbacher at mac.com  Fri Jul 25 02:32:23 2025
From: pfurbacher at mac.com (Paul Furbacher)
Date: Thu, 24 Jul 2025 22:32:23 -0400
Subject: Is there an easier way to "fix" a control instead of building 
 everything (i.e., java, native, etc.)?
Message-ID: <518DE023-05EB-4BCF-A515-26F510C61304@mac.com>

Thanks everyone for the various pieces of advice. 

Switching to the master branch (I had been using jfx21) resolved the problem with clang failing to compile :graphics:ccMacGlass. That yielded a successful build.

Turns out, when I ran my simple demo of the problem against the build, the incorrect behavior didn?t manifest itself. I began to doubt what I had seen in jfx21, but rerunning using jfx21, it was there: a buried exception which was leaving the date picker textfield with an invalid value when typed and committed by the user.

That?s when, after crafting a number of unsuccessful searches in JBS, I finally found the issue (https://bugs.openjdk.org/browse/JDK-8303478) and that it had been resolved in jfx22. So, all I have to do is upgrade my much larger apps that use the DatePicker to at least jfx22.

Again, thanks for all the help, although I wasn't able to get John Hendrikx?s approach (I?m using gradle, and couldn?t figure out how to get it to put my versions of the javafx classes first on the class path).

Best regards, 

Paul Furbacher



From lkostyra at openjdk.org  Fri Jul 25 12:09:04 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 25 Jul 2025 12:09:04 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
Message-ID: <4Z8B4GLICMzbgXOUKYcoihvXsy7fCOabt2luf3fVop4=.5bdab030-e3f0-462c-93d3-13a3d6642a83@github.com>

On Tue, 22 Jul 2025 17:00:25 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 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/4a48e6e5...1a9a0a41

I focused on reviewing native code and skimmed over the rest. Looks good overall.

I only found one more issue in `build.gradle` which we should address, as it could pose some problems when merging D3D12 and Metal together.

build.gradle line 2680:

> 2678:     // Prism JSL
> 2679:     outPkg = IS_WINDOWS ? "com/sun/prism/d3d/hlsl" : (IS_MAC ? "com/sun/prism/mtl/msl" : "")
> 2680:     addJSL(project, "Prism", outPkg, null) { sourceDir, destinationDir ->

I'm not quite sure if this is the best way to do it when counting in other platforms. While this used to work well on Windows with ES2 and D3D being the only backends, and it works well on Mac with ES2-MTL transition, it would unfortunately fall apart when mixing in D3D12.

On D3D12 branch JSLC generates two types of shaders at once - HLSL and HLSL6. With this change, on Windows both shaders would end up in `com/sun/prism/d3d/hlsl` when they should be separated. I think we should look through this and unify the way `addJSL` is called so that it functions better for multiple shader types. This would also be helpful when eventually merging direct3d12 to this code.

I think a better approach (you can source this from `direct3d12` branch [right here - added L1710 and L2808](https://github.com/openjdk/jfx-sandbox/commit/380fc8ea06a0a3187460013b254f93df4d683b32)) would be to have a generic package prefix `com/sun/prism` here and add shader-specific suffixes inside `addJSL` compile targets. Those targets would also be enabled-disabled based on current build platform (ex. HLSL/HLSL6 are both enabled by IS_WINDOWS property, whereas MSL would be enabled by IS_MAC property).

Let me know what you think of this approach and would it work with your backend.

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

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

From kcr at openjdk.org  Fri Jul 25 12:58:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Jul 2025 12:58:04 GMT
Subject: RFR: 8359601: Fix window button states of an extended stage [v6]
In-Reply-To: <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
 <hLwr2rzKlIgdFnakudAUJ4kj-jqan4EdxsY2qwOlpa8=.4997aee9-4ec0-4888-bce7-328ba85f5778@github.com>
Message-ID: <zPHWqzGuNetu-eex9FeqazPBzefYzOev88oQ2mZn_YA=.27c00407-6409-4b72-a804-9ce7e40b79b0@github.com>

On Sat, 21 Jun 2025 23:37:13 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
>> 
>> #### Windows 11
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | visible, disabled | visible |
>> | resizable, modal | visible, disabled | visible | visible |
>> | not resizable, modal | hidden | hidden | visible, utility-style |
>> 
>> #### Ubuntu 24 / Fedora 41 (GNOME)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> #### Kubuntu 24 (KDE)
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | visible | visible | visible |
>> | not resizable, not modal | visible | hidden | visible |
>> | resizable, modal | visible, _not working_ | visible | visible |
>> | not resizable, modal | visible, _not working_ | hidden | visible |
>> 
>> ## Observations
>> 
>> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
>> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
>> 
>> ## Permitted window button operations
>> 
>> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
>> 
>> | Window attributes | Iconify | Maximize | Close |
>> |---|---|---|---|
>> | resizable, not modal | yes | yes | yes |
>> | not resizable, not modal | yes | no | yes |
>> | resizable, modal | no | yes | yes |
>> | not resizable, modal | no | no | yes |
>> 
>> ## Fixes
>> 
>> This PR includes the following changes:
>> 1. Unused code relating to window modality is removed...
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix resizable state of macOS window

Marked as reviewed by kcr (Lead).

Headful tests passed on Windows.

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

PR Review: https://git.openjdk.org/jfx/pull/1831#pullrequestreview-3055301521
PR Comment: https://git.openjdk.org/jfx/pull/1831#issuecomment-3117696892

From mstrauss at openjdk.org  Fri Jul 25 13:04:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 25 Jul 2025 13:04:04 GMT
Subject: Integrated: 8359601: Fix window button states of an extended stage
In-Reply-To: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
References: <HT4TkXwyXgpj2fFMeb9OBOcfaxRh795u9M8PHAinIXM=.36e3a705-c134-474d-aef3-6cc1df69ed31@github.com>
Message-ID: <B3GuVhNZV-FtDVOCOPEGl2rzcjNQZC_z15jrUIKwis8=.10e9dcd0-b518-40e6-8324-a4771adaad28@github.com>

On Sun, 15 Jun 2025 20:01:11 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> The window button states (disabled/hidden) of extended stages with a `HeaderButtonOverlay` or custom header buttons are inconsistent with what we would expect from the OS (Windows and Linux). To figure out what we would expect, I started with gathering some data. The following table shows the button states of system-decorated windows on various platforms:
> 
> #### Windows 11
> 
> | Window attributes | Iconify | Maximize | Close |
> |---|---|---|---|
> | resizable, not modal | visible | visible | visible |
> | not resizable, not modal | visible | visible, disabled | visible |
> | resizable, modal | visible, disabled | visible | visible |
> | not resizable, modal | hidden | hidden | visible, utility-style |
> 
> #### Ubuntu 24 / Fedora 41 (GNOME)
> 
> | Window attributes | Iconify | Maximize | Close |
> |---|---|---|---|
> | resizable, not modal | visible | visible | visible |
> | not resizable, not modal | visible | hidden | visible |
> | resizable, modal | visible, _not working_ | visible, _not working_ | visible |
> | not resizable, modal | visible, _not working_ | hidden | visible |
> 
> #### Kubuntu 24 (KDE)
> 
> | Window attributes | Iconify | Maximize | Close |
> |---|---|---|---|
> | resizable, not modal | visible | visible | visible |
> | not resizable, not modal | visible | hidden | visible |
> | resizable, modal | visible, _not working_ | visible | visible |
> | not resizable, modal | visible, _not working_ | hidden | visible |
> 
> ## Observations
> 
> 1. On Windows, buttons are generally disabled when their operation is not possible with the given window attributes.
>    * Exception: modal/non-resizable windows look like utility windows (iconify and maximize are hidden)
> 2. On GNOME and KDE, buttons are generally hidden when their operation is not possible.
>    * Exception: iconify and maximize on modal windows is not hidden, but seems to simply not do anything (bug?)
> 
> ## Permitted window button operations
> 
> Given the gathered observations and some simple logic, this is the table of operations that are permitted for all combinations of modal and resizable window attributes:
> 
> | Window attributes | Iconify | Maximize | Close |
> |---|---|---|---|
> | resizable, not modal | yes | yes | yes |
> | not resizable, not modal | yes | no | yes |
> | resizable, modal | no | yes | yes |
> | not resizable, modal | no | no | yes |
> 
> ## Fixes
> 
> This PR includes the following changes:
> 1. Unused code relating to window modality is removed.
> 2. The disabled states of `HeaderButtonOverlay` as well as `HeaderButtonBehavior` are changed to mat...

This pull request has now been integrated.

Changeset: bc433da8
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bc433da812461a1c2796cdb3123f814e4ce532d5
Stats:     604 lines in 20 files changed: 277 ins; 260 del; 67 mod

8359601: Fix window button states of an extended stage
8359763: Close request handler is not called for an extended stage

Reviewed-by: mmack, kcr

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

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

From mstrauss at openjdk.org  Fri Jul 25 13:15:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 25 Jul 2025 13:15:11 GMT
Subject: [jfx25] RFR: 8359601: Fix window button states of an extended stage
Message-ID: <UFwd9vziwG8feAhXJIVOGapKCuTVCkpN4Z42Rp9FPMA=.00f012cc-e4f5-4985-a1b9-7be384eb07a8@github.com>

8359601: Fix window button states of an extended stage

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

Commit messages:
 - Backport bc433da812461a1c2796cdb3123f814e4ce532d5

Changes: https://git.openjdk.org/jfx/pull/1855/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359601
  Stats: 604 lines in 20 files changed: 277 ins; 260 del; 67 mod
  Patch: https://git.openjdk.org/jfx/pull/1855.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1855/head:pull/1855

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

From kcr at openjdk.org  Fri Jul 25 13:42:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Jul 2025 13:42:07 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <bxUibGGkV0OhkDI02ByzEvdwzEdFnyG6V4I3AFVdukc=.df8dead3-34c6-4bb7-8e43-97b4267480b8@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
 <3NIKtGgMH1-blsQkSIss2g6XqQC7JJDKDNgaNhgy9dI=.3226151e-5e43-46c4-8fb6-f3b755d6ed86@github.com>
 <bxUibGGkV0OhkDI02ByzEvdwzEdFnyG6V4I3AFVdukc=.df8dead3-34c6-4bb7-8e43-97b4267480b8@github.com>
Message-ID: <6bJITNiIIaoaJ3mwh-sJ_XjwTVi04hJrzGg_5duJj4k=.93cf8cff-c505-436b-8df2-9071f7c9ecdc@github.com>

On Fri, 18 Jul 2025 19:26:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Do you refer to the Node.snapshot()?
> 
> In my case, it was Scene::snapshot(), but basically the question is where the screen size has any effect? Robot?
> 
> It does not seem to impact Scene::snapshot.

The screen size is not relevant for snapshot (intentionally so). It's a good question as to where it would make a difference.

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3117862545

From kcr at openjdk.org  Fri Jul 25 13:45:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Jul 2025 13:45:08 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v11]
In-Reply-To: <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>
Message-ID: <gPyDWX-EOYflKGf05PII60n2NoUIn1Io18MoLYVR-nI=.4e1542c6-ed52-48e9-bcc3-ae75973c4b65@github.com>

On Tue, 22 Jul 2025 07:09:58 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyright sections

I'll review the code soon. I ran a full set of tests, excluding the robot tests, and see two failures (below), which you mentioned are expected. Presumably these are the same two failures you see?

It would probably be best to skip these two tests when running the Headless glass platform. This could either be done as part of this PR or in a follow-up "Skip failing tests on Headless glass platform" bug.

1. MacPasteboardTest


MacPasteboardTest > testValidLocalImageURLMacPasteboard() FAILED
    java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
        at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testValidLocalImageURLMacPasteboard$0(MacPasteboardTest.java:73)

MacPasteboardTest > testDataBase64ImageMacPasteboard() FAILED
    java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
        at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testDataBase64ImageMacPasteboard$0(MacPasteboardTest.java:89)

MacPasteboardTest > testNotAnImageURLMacPasteboard() FAILED
    java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
        at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testNotAnImageURLMacPasteboard$0(MacPasteboardTest.java:100)


The tests in this class assume we are running the Mac glass platform, so they should all be skipped when running the Headless glass platform. One way to do this would be to add a `PlatformUtil::isHeadless` method and change all of the `assumeTrue(PlatformUtil.isMac())` calls to `assumeTrue(PlatformUtil.isMac() && !PlatformUtil.isHeadless())`. The assumeTrue wouldn't be annotated with a bug ID, since this expresses a fundamental requirement of the test, not a bug that needs to be fixed.


2. ClipboardTest::testCopyUTF8String


ClipboardTest > testCopyUTF8String() FAILED
    org.opentest4j.AssertionFailedError: expected: < Jump to: ?? Jump> but was: <HEADLESS_TEST>
        at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
        at app//test.javafx.scene.input.ClipboardTest.testCopyUTF8String(ClipboardTest.java:94)


This looks like a bug in the Headless glass platform code (not the test), so a bug tracking this headless clipboard failure should be filed. Then add `assumeTrue(!PlatformUtil.isHeadless())` along with a comment above the assumeTrue with the bug ID of the headless clipboard tracking bug.

Separately, another bug should be filed for the failing robot tests (I don't have a list, since I didn't run it with `-PUSE_ROBOT=true` for this test run).

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3117871252

From angorya at openjdk.org  Fri Jul 25 17:29:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 25 Jul 2025 17:29:14 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
Message-ID: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>

This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.

While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:


        if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
            for (Node node : toolbar.getItems()) {
                if (!node.isManaged()) continue;
                prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
            }
            prefWidth -= getSpacing();
        } else {


the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.

Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:


snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))


It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.

Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.

I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

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

Commit messages:
 - snap length

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

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

From tom_L64 at hotmail.com  Fri Jul 25 18:02:47 2025
From: tom_L64 at hotmail.com (tom L)
Date: Fri, 25 Jul 2025 18:02:47 +0000
Subject: JavaFX TextInputControl private access yet supposed to be overrided
 problem
Message-ID: <PAXP251MB06713AADDBF3395A8206AA668859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>

Hello.
I have this problem where a lot of methods and utility in TextInputControl have package private access while at the same time are expected to be used/overriden by children.
For example,
```
    String filterInput(String text) {
        // This method should be overridden by child classes.
        // It is overridden in TextField and TextArea as needed.
        return text;
    }
```
This method is clearly supposed to be overriden, and I am making a hex editor, requiring me to create my own text field, but I can't override it.
It is the same for other methods, also including utility methods, like for example, with the same name :
```
    static String filterInput(String txt, boolean stripNewlines, boolean stripTabs)
```
In order to do what I want, I am no choice but to copy paste half the code of this class, since even if I override the only method that uses filterInput, public void replaceText, there are a lot of package private stuff inside (mainly getFormatterAccessor), so I am ended up with trying to copy paste the whole class.

On another note, since I am talking about formatter accessor, this inner class in TextInputControl has a typos in it: TextInputControlFromatterAccessor.

Is it possible to fix this?
Thank you in advance.

Best regards,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250725/fdeac679/attachment.htm>

From nlisker at openjdk.org  Fri Jul 25 20:10:21 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 25 Jul 2025 20:10:21 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
Message-ID: <0U0u4jzpdUHm8oxef4DZux-QmfXbYhN5oztVkQ9-lbY=.31313832-381a-4cc4-930b-5d41e760e2d4@github.com>

On Tue, 22 Jul 2025 17:00:25 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 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/bc5879c6...1a9a0a41

I did a sanity review of some of the Java section as I don't have a Mac to test on.

build.gradle line 2705:

> 2703:                 exec {
> 2704:                     commandLine("${metalCompiler}")
> 2705:                     args += [ "-std=macos-metal2.4" ]

Should this version number be moved to the properties file with the other versions? Is it expected to be updated? Metal 4 was released recently, and Metal 3 was released a few years ago. Are we not going to end up with a version that's going to be "old" by the time it's released?

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

> 1: /*
> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.

Is the copyright of 2021 needed if the file was introduced in 2025? Other files are also like that, but not all.

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

> 50: import static java.util.Map.entry;
> 51: 
> 52: public class MSLBackend extends SLBackend {

Since this is a new class, can we have a bit of class docs to explain what it is and what it relates to? Same for the other classes where you deem it not trivial.

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

> 62: 
> 63:     private String shaderFunctionName;
> 64:     private String textureSamplerName;

This variable is assigned but never read (unused). Is it needed for anything?

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

> 180:     protected String getQualifier(Qualifier q) {
> 181:         String qual = QUAL_MAP.get(q.toString());
> 182:         return (qual != null) ? qual : q.toString();

All these "get or else" methods can use `Map::getOrDefault`:

return QUAL_MAP.getOrDefault(q.toString(), q.toString());

And if `toString` is expensive, it can be stored in a local variable first.

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

> 214:                 // For every user defined function, pass reference to 4 samplers and
> 215:                 // reference to the uniforms struct.
> 216:                 if (!CoreSymbols.getFunctions().contains(getFuncName(e.getFunction().getName())) &&

Eclipse kindly warns that `CoreSymbols.getFunctions()` is a collection of `Function`, but it's searched of a `String`. Perhaps `.getName()` shouldn't be called here?

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

> 236:             if (first) {
> 237:                 // Add 4 sampler variables and "device <Uniforms>& uniforms" as the parameter to all user defined functions.
> 238:                 if (!CoreSymbols.getFunctions().contains(getFuncName(d.getFunction().getName())) &&

Same "unlikely argument".

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

> 254:         Variable var = d.getVariable();
> 255:         Qualifier qual = var.getQualifier();
> 256:         if (qual == Qualifier.CONST) { // example. const int i = 10;

Using a switch expression here on the enum will be cleaner. First, the `else` at the end can't be reached unless `qual == null`. If it's at all possible for it to be `null`, it should be explicitly expressed (via `case null -> ...`). Second, if other enum constants are added later (is it possible even?), we *should* get a compiler error and not go to the `else` blindly.

I would also extract the content of each branch to its own private method, especially when there're a lot of comments that could go on it:

case null -> visitVarDecl(d) // if can be null
case CONST -> handleConst()
case PARAM -> handleParam()

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

> 315:         String shaderType = isPrismShader ? "PRISM" : "DECORA";
> 316: 
> 317:         if (fragmentShaderHeader == null) {

Looks like `fragmentShaderHeader` is only used once and then retained in memory just to check later on if it was initialized  and written. Perhaps a boolean flag would make it clearer? In that case the builder is used and discarded with the appropriately-named flag conveying a meaning better than "string builder == null", such as `wasHeaderWritten`.

I would also extract the content of the `if` to its own method, but it's just my style to break up long methods.

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

> 357: 
> 358:             if (objCHeader.length() == 0) {
> 359:                 objCHeader.append("#ifndef " + shaderType + "_SHADER_COMMON_H\n" +

Is `objHeader` supposed to have this content initialized only once? Doesn't `shaderType` change in later calls?
It's also never cleared, is it supposed to retain all its content?

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

> 509:         texSamplerMap = new HashMap<>();
> 510:         helperFunctions = new ArrayList<>();
> 511:         uniformNames = new ArrayList<>();

You should be able to initialize these at the declaration site and make them final. Here you can call `clear` to reset the content. Perhaps it's better than recreating the data structure?

Alternatively, you can encapsulate all the variables and methods that are used per-shader in a single inner class and create a new instance per shader for the duration of handling that shader. This approach provides better separation and encapsulation and tends to be less error prone.

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

> 527:         } else {
> 528:             objCHeaderFileName = DECORA_SHADER_HEADER_FILE_NAME;
> 529:         }

If you prefer, this can be
`objCHeaderFileName = isPrismShader ? PRISM_SHADER_HEADER_FILE_NAME : DECORA_SHADER_HEADER_FILE_NAME;`

modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/model/CoreSymbols.java line 57:

> 55: 
> 56:     public static Set<Function> getFunctions() {
> 57:         return Collections.unmodifiableSet(getAllFunctions());

Could be `Set::copyOf` if you prefer.

modules/javafx.graphics/src/main/java/com/sun/prism/GraphicsPipeline.java line 52:

> 50:          */
> 51:         GLSL,
> 52:         /**

An empty line between the constants can help with readability.

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

> 48: import java.nio.ByteBuffer;
> 49: 
> 50: public class MTLContext extends BaseShaderContext {

Looks like all the fields here can be private. I don't see them used outside of this class.

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

> 95:     static {
> 96:         final String shaderLibName = "msl/jfxshaders.metallib";
> 97:         final Class clazz = MTLContext.class;

Raw type -> `Class<MTLContext>`

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

> 230:             }
> 231:             MTLShader.setTexture(texUnit, tex, linear, wrapMode);
> 232:         }

Maybe this is cleaner, and the removal of the default branch is safer.

        if (tex == null) return;
        boolean linear = tex.getLinearFiltering();
        int wrapMode = switch (tex.getWrapMode()) {
            case CLAMP_NOT_NEEDED -> MTL_SAMPLER_ADDR_MODE_NOP;
            case CLAMP_TO_EDGE, CLAMP_TO_EDGE_SIMULATED, CLAMP_TO_ZERO_SIMULATED -> MTL_SAMPLER_ADDR_MODE_CLAMP_TO_EDGE;
            case CLAMP_TO_ZERO -> MTL_SAMPLER_ADDR_MODE_CLAMP_TO_ZERO;
            case REPEAT, REPEAT_SIMULATED -> MTL_SAMPLER_ADDR_MODE_REPEAT;
        };
        MTLShader.setTexture(texUnit, tex, linear, wrapMode);

Can the texture legally be `null` and this method still called with it? Looks odd to call `updateTexture` with a `null` texture.

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

> 245:         } else {
> 246:             scratchTx = scratchTx.mul(xform).mul(perspectiveTransform);
> 247:         }

Looks like `mul` already does the short-circuiting identity check, so no need for the if-else:
`scratchTx.set(projViewTx).mul(xform).mul(getPerspectiveTransformNoClone());`

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

> 256:     protected void updateWorldTransform(BaseTransform xform) {
> 257:         worldTx.setIdentity();
> 258:         if ((xform != null) && (!xform.isIdentity())) {

Redundant identity check.

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

> 300:             default:
> 301:                 throw new InternalError("Unrecognized composite mode: " + mode);
> 302:         }

This can be an expression switch:

        int mtlCompMode = switch (mode) {
            case CLEAR -> MTL_COMPMODE_CLEAR;
            case SRC -> MTL_COMPMODE_SRC;
            case SRC_OVER -> MTL_COMPMODE_SRCOVER;
            case DST_OUT -> MTL_COMPMODE_DSTOUT;
            case ADD -> MTL_COMPMODE_ADD;
        };

No need for a default branch with enum. You want an error when a new constant is added.

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

> 313:         // implement or change in future if necessary
> 314:         long dstNativeHandle = dstRTT == null ? 0L : ((MTLTexture)dstRTT).getNativeHandle();
> 315:         long srcNativeHandle = ((MTLTexture)srcRTT).getNativeHandle();

Raw types -> `MTLTexture<?>`

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

> 405:         } else {
> 406:             throw new IllegalArgumentException("illegal value for CullMode: " + cullMode);
> 407:         }

Can be an expression switch.

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

> 483: 
> 484:     private void updateRawMatrix(GeneralTransform3D src) {
> 485:         rawMatrix[0]  = (float)src.get(0); // Scale X

Is there a meaningful loss of precision here?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLGraphics.java line 32:

> 30: import com.sun.prism.paint.Color;
> 31: 
> 32: public class MTLGraphics extends BaseShaderGraphics {

Doesn't look like the class needs to be public. Same for other classes in this package, like `MTLContext`. I suggest minimizing visibility to avoid leaking the class outside of its scope and also for better readability context.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLGraphics.java line 45:

> 43:             return null;
> 44:         }
> 45:         return new MTLGraphics(context, target);

Can be a ternary if you prefer.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 32:

> 30: 
> 31: class MTLMesh extends BaseMesh {
> 32:     static int count = 0;

Do we use a new line after a class declaration?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 83:

> 81:     }
> 82: 
> 83:     static class MTLMeshDisposerRecord implements Disposer.Record {

Can be private.

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()`?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMeshView.java line 113:

> 111:     }
> 112: 
> 113:     static class MTLMeshViewDisposerRecord implements Disposer.Record {

Can be private. Same in other places.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 37:

> 35: import com.sun.prism.impl.Disposer;
> 36: 
> 37: class MTLPhongMaterial extends BasePhongMaterial implements PhongMaterial {

The superclass already implements the interface, so it's redundant here.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 43:

> 41:     private final MTLContext context;
> 42:     private final long nativeHandle;
> 43:     private TextureMap maps[] = new TextureMap[MAX_MAP_TYPE];

Can be final.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 81:

> 79:         Texture texture = (image == null) ? null
> 80:                 : context.getResourceFactory().getCachedTexture(image, Texture.WrapMode.REPEAT, useMipmap);
> 81:         long hTexture = (texture != null) ? ((MTLTexture) texture).getNativeHandle() : 0;

Raw type

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

> 63:     @Override
> 64:     public boolean init() {
> 65:         Map devDetails = new HashMap();

Raw types (though the problem is upstream and really should be fixed).

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

> 91:             Map devDetails = MTLPipeline.getInstance().getDeviceDetails();
> 92:             devDetails.put("mtlCommandQueue",
> 93:                                 mtlResourceFactory.getContext().getMetalCommandQueue());

Raw type again, causing a warning because the compiler doesn't know if `put` is given valid types.

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

> 127:             default:
> 128:                 return false;
> 129:         }

Can be a switch expression. Also no need for the comment because the constant has docs ? 

        return switch (type) {
            case MSL -> true;
            default -> false;
        };

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

> 137:             default:
> 138:                 return false;
> 139:         }

Can be like above.

Also, can Metal really support SM3? Isn't it a D3D-only model?

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

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTexture.java line 53:

> 51: 
> 52:     private boolean opaque;
> 53:     private boolean MSAA;

Can be final except for `opaque`.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTexture.java line 89:

> 87:                 wrapMode, msaa);
> 88:         MTLTextureData textData = new MTLRTTextureData(context, nPtr, size);
> 89:         MTLTextureResource resource = new MTLTextureResource(textData, true);

Raw type

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRTTexture.java line 101:

> 99: 
> 100:         MTLTextureData textData = new MTLFBOTextureData(context, nPtr, size);
> 101:         MTLTextureResource resource = new MTLTextureResource(textData, false);

Raw type

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

> 131:         // In future, if needed, need to implement pix as ByteBuffer
> 132:         if (pix instanceof IntBuffer) {
> 133:             nReadPixelsFromRTT(nTexPtr, (IntBuffer)pix);

Can pattern match instead of cast.

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

> 27: 
> 28: public class MTLRTTextureData extends MTLTextureData {
> 29:     MTLRTTextureData(MTLContext context, long texPtr, long size) {

New line, also in other places?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRenderTarget.java line 1:

> 1: /*

Why is this interface needed if it's implemented only in 1 class and the return value from the method is always 0?

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

> 42: import com.sun.prism.impl.TextureResourcePool;
> 43: import com.sun.prism.impl.ps.BaseShaderFactory;
> 44: import com.sun.prism.mtl.MTLContext;

Unused import

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

> 55: 
> 56: public class MTLResourceFactory extends BaseShaderFactory {
> 57:     private final MTLContext context;

New line?

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

> 101:             return createShader(pixelShaderName, samplers, params, maxTexCoordIndex,
> 102:                                 isPixcoordUsed, isPerVertexColorUsed);
> 103:         } catch (Exception e) {

`e` is unused and can be `_` if this is correct (e.g., no `e.printStackTrace()`). Same in other places.

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

> 112:         Shader shader = MTLShader.createShader(getContext(), shaderName, samplers,
> 113:                 params, maxTexCoordIndex, isPixcoordUsed, isPerVertexColorUsed);
> 114:         return shader;

Can return the method result directly if you prefer.

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

> 119:         if (shaderName == null) {
> 120:             throw new IllegalArgumentException("Shader name must be non-null");
> 121:         }

Can be `Objects.requireNonNull(shaderName, "Shader name must be non-null")` if an NPE acceptable instead of an IAE (I think it's better even).

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

> 124:                 System.err.println("MTLResourceFactory: Prism - createStockShader: " + shaderName);
> 125:             }
> 126:             Class klass = Class.forName("com.sun.prism.shader." + shaderName + "_Loader");

Raw type

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

> 135: 
> 136:     @Override
> 137:     public TextureResourcePool getTextureResourcePool() {

`TextureResourcePool` is a raw type.

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

> 168:             allocw = w;
> 169:             alloch = h;
> 170:         }

If you prefer:

        int allocw = PrismSettings.forcePow2 ? nextPowerOfTwo(w, Integer.MAX_VALUE) : w;
        int alloch = PrismSettings.forcePow2 ? nextPowerOfTwo(h, Integer.MAX_VALUE) : h;

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

> 174:         int bpp = formatHint.getBytesPerPixelUnit();
> 175:         if (allocw >= (Integer.MAX_VALUE / alloch / bpp)) {
> 176:             throw new RuntimeException("Illegal texture dimensions (" + allocw + "x" + alloch + ")");

Is a `RuntimeException` necessary here? Can we not recover?

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

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

Raw type

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

> 279:     @Override
> 280:     public boolean isFormatSupported(PixelFormat format) {
> 281:         switch (format) {

I suggest an exhaustive no-default switch for enums.

        return switch (format) {
            case BYTE_RGB, BYTE_GRAY, BYTE_ALPHA, BYTE_BGRA_PRE, INT_ARGB_PRE, FLOAT_XYZW, BYTE_APPLE_422 -> true;
            case MULTI_YCbCr_420 -> false;
        };

You can keep the 1 constant per line formatting if you prefer.

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

> 346:         int createh = height;
> 347:         int cx = 0;
> 348:         int cy = 0;

Unused variables

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

> 351:             createw = nextPowerOfTwo(createw, Integer.MAX_VALUE);
> 352:             createh = nextPowerOfTwo(createh, Integer.MAX_VALUE);
> 353:         }

Can be folded into a ternary in the initial assignment if you prefer.

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

> 44:     private final Map<Integer, WeakReference<Object>> textureIdRefMap = new HashMap<>();
> 45: 
> 46:     private static Map<String, MTLShader> shaderMap = new HashMap<>();

Can be final.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 64:

> 62:     public static Shader createShader(MTLContext ctx, String fragFuncName, Map<String, Integer> samplers,
> 63:                                       Map<String, Integer> params, int maxTexCoordIndex,
> 64:                                       boolean isPixcoordUsed, boolean isPerVertexColorUsed) {

All 4 are unused.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 67:

> 65:         if (shaderMap.containsKey(fragFuncName)) {
> 66:             return shaderMap.get(fragFuncName);
> 67:         } else {

`else` is not required because `if` returns. Up to you.

Can also use `Map::getOrDefault` if you want to extract the shader creation into a method.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 79:

> 77:         } else {
> 78:             return new MTLShader(ctx, fragFuncName);
> 79:         }

Can use `Map::getOrDefault`.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 85:

> 83:         for (Map.Entry<String, Integer> entry : samplers.entrySet()) {
> 84:             this.samplers.put(entry.getValue(), entry.getKey());
> 85:         }

Can be `samplers.forEach((key, val) -> this.samplers.put(val, key));` with better argument names.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 109:

> 107:         } else {
> 108:             return false;
> 109:         }

`return nMetalShaderRef != 0`?

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 117:

> 115: 
> 116:         currentEnabledShader.textureIdRefMap.put(texUnit, new WeakReference(tex));
> 117:         MTLTexture mtlTex = (MTLTexture)tex;

Raw types

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

> 195: 
> 196:     private static native long nCreateMetalShader(long context, String fragFuncName);
> 197:     private static native Map  nGetUniformNameIdMap(long nMetalShader);

Raw type

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 30:

> 28: import com.sun.glass.ui.Screen;
> 29: import com.sun.javafx.geom.Rectangle;
> 30: import com.sun.prism.CompositeMode;

Unused

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 39:

> 37: public class MTLSwapChain implements MTLRenderTarget, Presentable, GraphicsResource {
> 38: 
> 39:     private PresentableState pState;

final

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 59:

> 57:     @Override
> 58:     public boolean lockResources(PresentableState state) {
> 59: 

No need for empty line.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 87:

> 85:         MTLContext context = getContext();
> 86:         context.flushVertexBuffer();
> 87:         MTLGraphics g = (MTLGraphics) MTLGraphics.create(context, stableBackbuffer);

Unnecessary cast

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 126:

> 124:     @Override
> 125:     public Graphics createGraphics() {
> 126: 

Empty line

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLSwapChain.java line 148:

> 146:             long pTex = pState.getNativeFrameBuffer();
> 147: 
> 148:             stableBackbuffer = (MTLRTTexture)MTLRTTexture.create(getContext(), pTex, w, h, 0);

Unnecessary cast

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.

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

> 39: 
> 40:     private final MTLContext context;
> 41:     private long texPtr;

final

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

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

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

> 95:                         int srcscan, boolean skipFlush) {
> 96: 
> 97:         switch (format.getDataType()) {

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.

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

> 34:     private long size;
> 35: 
> 36:     private MTLTextureData() {

Unused constructor. Prevents the fields from being final. Doesn't look like it's needed.

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLTextureResource.java line 32:

> 30: public class MTLTextureResource<T extends MTLTextureData> extends DisposerManagedResource<T> {
> 31: 
> 32:     boolean canDispose;

private final

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLVramPool.java line 36:

> 34:                implements TextureResourcePool<MTLTextureData> {
> 35: 
> 36:     private static MTLVramPool theInstance = new MTLVramPool();

final

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLVramPool.java line 49:

> 47:     public long estimateTextureSize(int width, int height, PixelFormat format) {
> 48:         return ((long) width) * ((long) height) *
> 49:                ((long) format.getBytesPerPixelUnit());

Unnecessary cast

modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLVramPool.java line 54:

> 52:     @Override
> 53:     public long estimateRTTextureSize(int width, int height, boolean hasDepth) {
> 54:         // REMIND: need to deal with size of depth buffer, etc.

Is this comment supposed to go in?

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

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3055919768
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231425136
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231643473
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231434571
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231476027
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231447687
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231481882
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231487233
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231509449
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231537374
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231566616
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231582333
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231544130
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231633067
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231635900
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231692608
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231711272
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231709236
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231731280
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231733285
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231702027
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231713202
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231716612
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231738770
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231749898
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231746162
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231757335
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231757753
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231761693
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231761972
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231763737
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231764851
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231766544
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231777814
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231779325
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231781861
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231790290
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231834264
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231836448
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231837112
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231837549
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231838620
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231840770
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231793697
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231795530
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231795928
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231802438
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231804350
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231807526
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231808072
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231809412
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231813640
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231816624
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231820659
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231824222
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231827607
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231829034
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231848617
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231846379
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231847525
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231855592
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231861918
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231863160
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231867919
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231844004
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231886182
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231887184
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231889067
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231891135
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231891964
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231893319
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231896842
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231899223
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231900351
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231900934
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231919533
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231904681
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231907827
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231911150
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231912646
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2231913076

From nlisker at openjdk.org  Fri Jul 25 20:17:05 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 25 Jul 2025 20:17:05 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
Message-ID: <PaqIAqM264d822vkYx1fuWA1XP9FtbOenS_X3y5QsbE=.5eac4544-3deb-42c8-9718-91e5013dc8ed@github.com>

On Tue, 22 Jul 2025 17:00:25 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 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/71ae6ae9...1a9a0a41

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

> 32: public class GenAllDecoraShaders {
> 33: 
> 34:     static String [][] compileShaders = {

private final?

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

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

From mfox at openjdk.org  Fri Jul 25 20:20:02 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 25 Jul 2025 20:20:02 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
Message-ID: <0YELjMcGLrI9tYp6inpQHyziq8n5pYXtxS-glXK4mJg=.e9f7a8e0-46dd-47d9-bf10-9cac3dd51f66@github.com>

On Thu, 17 Jul 2025 09:18:42 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust error message for window-on-top check

Looks good to me.

BTW, this test also fails on macOS 16 unless `--no-daemon` is specified. I'm also seeing failures on the MenuDoubleShortcutTest that are new. So it looks like macOS has also tightened up security related to background processes stealing focus.

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

Marked as reviewed by mfox (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-3056692834

From angorya at openjdk.org  Fri Jul 25 20:35:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 25 Jul 2025 20:35:10 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: <8BWzu14LTrbX8mJomYQ6Ydng7GhLhMIIaxia-1BMHj4=.b516dcf6-a663-42ac-9274-3ee7baef91d3@github.com>

On Fri, 25 Jul 2025 15:50:35 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/82a2f5ef...1a9a0a41
>
> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 216:
> 
>> 214:                 // For every user defined function, pass reference to 4 samplers and
>> 215:                 // reference to the uniforms struct.
>> 216:                 if (!CoreSymbols.getFunctions().contains(getFuncName(e.getFunction().getName())) &&
> 
> Eclipse kindly warns that `CoreSymbols.getFunctions()` is a collection of `Function`, but it's searched of a `String`. Perhaps `.getName()` shouldn't be called here?

This means your Eclipse configuration differs from mine.  Should we pull your configuration changes to this PR?

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

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

From nlisker at openjdk.org  Fri Jul 25 20:58:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 25 Jul 2025 20:58:03 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <8BWzu14LTrbX8mJomYQ6Ydng7GhLhMIIaxia-1BMHj4=.b516dcf6-a663-42ac-9274-3ee7baef91d3@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>
Message-ID: <qxIEiwvEIsOdblX5rox9BdcMSYWISCLmdZCFMkRCJoE=.dae74adc-9ca1-497b-9dd9-751a5dcaa8c8@github.com>

On Fri, 25 Jul 2025 20:32:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 216:
>> 
>>> 214:                 // For every user defined function, pass reference to 4 samplers and
>>> 215:                 // reference to the uniforms struct.
>>> 216:                 if (!CoreSymbols.getFunctions().contains(getFuncName(e.getFunction().getName())) &&
>> 
>> Eclipse kindly warns that `CoreSymbols.getFunctions()` is a collection of `Function`, but it's searched of a `String`. Perhaps `.getName()` shouldn't be called here?
>
> This means your Eclipse configuration differs from mine.  Should we pull your configuration changes to this PR?

I commented on all the places where Eclipse gives a warning in this PR. Do you want me to upload the compiler settings? I think we discussed at some point the need to upload the formatter and other setting to the repo.

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

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

From angorya at openjdk.org  Fri Jul 25 21:05:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 25 Jul 2025 21:05:02 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <qxIEiwvEIsOdblX5rox9BdcMSYWISCLmdZCFMkRCJoE=.dae74adc-9ca1-497b-9dd9-751a5dcaa8c8@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>
Message-ID: <wO5Z_D-cGZWNtNNCfLYLN6IF38NWkosMBGpw-BMmlEs=.c4493776-6a95-444e-ae19-b6e17291524d@github.com>

On Fri, 25 Jul 2025 20:55:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This means your Eclipse configuration differs from mine.  Should we pull your configuration changes to this PR?
>
> I commented on all the places where Eclipse gives a warning in this PR. Do you want me to upload the compiler settings? I think we discussed at some point the need to upload the formatter and other setting to the repo.

We might, at some point, but my question is about .classpath files probably.  I don't see MSLBackend.java as being on the source path, which makes me think you have a different setup, and I'd like to know the difference.

Speaking of errors, I currently have the errors configured to show 0 warnings.  In this particular case, 

`unlikely argument type for collection methods using 'Object'` and 
`Unlikely argument type for method equals()` both set to WARNING, though
`Perform strict analysis against the expected type` is not checked.

If I enable the latter, I get 229 warnings all over the place.

My concern is that what you found is a real issue, yet (at least my config) does not show it.

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

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

From nlisker at openjdk.org  Fri Jul 25 21:17:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 25 Jul 2025 21:17:03 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <wO5Z_D-cGZWNtNNCfLYLN6IF38NWkosMBGpw-BMmlEs=.c4493776-6a95-444e-ae19-b6e17291524d@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>
Message-ID: <DJgG2cMLgdWcl-Skqy1afCFAn-LHtKtQqPQofxwseqo=.99d36095-80f6-406d-b034-17731342e400@github.com>

On Fri, 25 Jul 2025 21:02:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I commented on all the places where Eclipse gives a warning in this PR. Do you want me to upload the compiler settings? I think we discussed at some point the need to upload the formatter and other setting to the repo.
>
> We might, at some point, but my question is about .classpath files probably.  I don't see MSLBackend.java as being on the source path, which makes me think you have a different setup, and I'd like to know the difference.
> 
> Speaking of errors, I currently have the errors configured to show 0 warnings.  In this particular case, 
> 
> `unlikely argument type for collection methods using 'Object'` and 
> `Unlikely argument type for method equals()` both set to WARNING, though
> `Perform strict analysis against the expected type` is not checked.
> 
> If I enable the latter, I get 229 warnings all over the place.
> 
> My concern is that what you found is a real issue, yet (at least my config) does not show it.

Oh, I thought you were saying that you didn't see that warning because of the compiler configuration, not the project configuration.

I manually added the source folders that are relevant to this PR and that are not in the default configuration. I'm not sure if there's merit to change the classpath file in the repo.

`unlikely argument type for collection methods using 'Object'` without `Perform strict analysis against the expected type` is enough to give this warning.

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

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

From angorya at openjdk.org  Fri Jul 25 21:17:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 25 Jul 2025 21:17:04 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <DJgG2cMLgdWcl-Skqy1afCFAn-LHtKtQqPQofxwseqo=.99d36095-80f6-406d-b034-17731342e400@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>
Message-ID: <Iz8JDP2C401WP2O2gLvQXf8737OF7om4-ORjlH2-MYA=.f8e07f3e-1c4b-41cd-8009-8bcbddb0369c@github.com>

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

>> We might, at some point, but my question is about .classpath files probably.  I don't see MSLBackend.java as being on the source path, which makes me think you have a different setup, and I'd like to know the difference.
>> 
>> Speaking of errors, I currently have the errors configured to show 0 warnings.  In this particular case, 
>> 
>> `unlikely argument type for collection methods using 'Object'` and 
>> `Unlikely argument type for method equals()` both set to WARNING, though
>> `Perform strict analysis against the expected type` is not checked.
>> 
>> If I enable the latter, I get 229 warnings all over the place.
>> 
>> My concern is that what you found is a real issue, yet (at least my config) does not show it.
>
> Oh, I thought you were saying that you didn't see that warning because of the compiler configuration, not the project configuration.
> 
> I manually added the source folders that are relevant to this PR and that are not in the default configuration. I'm not sure if there's merit to change the classpath file in the repo.
> 
> `unlikely argument type for collection methods using 'Object'` without `Perform strict analysis against the expected type` is enough to give this warning.

all right, so we probably want to leave the project config as is, and this manual change is a one-off.  Do you mind listing the changes here for future reference?

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

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

From kcr at openjdk.org  Fri Jul 25 21:23:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Jul 2025 21:23:02 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v4]
In-Reply-To: <-EWqPffHmp_NKfHW8QN5HmexgbxOnpNlT4BF8GMzYsY=.703b3cf5-a936-4922-8c90-4d5c2b75d77a@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <KORBESkRh_-XBq0ye2d6rURarAwrgCJnYDgkW7JVou8=.64db5355-d919-4757-887b-b77d3f0ae566@github.com>
 <Hff4IFm8Jk8K4kjjRAYWifYAFVy5OxgTM2AhoFR6OTw=.fbdcd1e0-a5a8-4075-ae50-1aea42befe70@github.com>
 <-EWqPffHmp_NKfHW8QN5HmexgbxOnpNlT4BF8GMzYsY=.703b3cf5-a936-4922-8c90-4d5c2b75d77a@github.com>
Message-ID: <nnht0pi-7A3izInT6nk6xg1Ule7vsHLJGTvtSSdOFZs=.33d1d24a-6cf9-4db1-8f22-a52caeb73f61@github.com>

On Mon, 7 Jul 2025 09:15:47 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 231:
>> 
>>> 229:         if (windows.isEmpty()) return null;
>>> 230:         if (windows.size() == 1) return (HeadlessWindow)windows.get(0);
>>> 231:         return (HeadlessWindow)windows.get(windows.size() -1);
>> 
>> call me old fashioned, but would a straightforward reverse `for` loop be better in this case?  no unnecessary memory allocations required.
>> 
>> here and in two methods below?
>
> I'm not a fan of using Streams if it's not really needed, but in this case I think there might be benefits in eliminating the non-candidates in 1 statement -- I might be wrong though, didn't look yet at how this is compiled.

I think this is fine as is. I do note that the following is redundant:


        if (windows.size() == 1) return (HeadlessWindow)windows.get(0);


The general case will handle this case (and should be just as efficient).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2231976178

From kcr at openjdk.org  Fri Jul 25 21:23:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 25 Jul 2025 21:23:01 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v11]
In-Reply-To: <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>
Message-ID: <kkpf4eLUXZaGOcNvbS9Jwt8Eg8mUo8khZ2wZlKmdGGg=.21153b58-95e4-4169-ab68-1a5d56b842b1@github.com>

On Tue, 22 Jul 2025 07:09:58 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyright sections

Looks good. I left a few minor comments / questions as well as noting a couple follow-up items inline.

There are several follow-on issues to be filed. You might link them to [JDK-8324941](https://bugs.openjdk.org/browse/JDK-8324941) when you file them.

One more follow-up: It might be useful to add two manual headless tests (or one test with two modes) -- one using `Scene::snapshot` and the other using `Robot::getScreenCapture` -- the tests would contain a scene and then save the resulting snapshot / screen capture to a PNG file, which could then be opened. Alternatively, the test(s) could be a headful Swing app that draws the captured image into a Swing JPanel for display. Since the automated system tests already exercise some of this, I think this manual test could be done separately.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessPlatformFactory.java line 50:

> 48:     public MenuBarDelegate createMenuBarDelegate(MenuBar menubar) {
> 49:         throw new UnsupportedOperationException("Not supported yet.");
> 50:     }

Suggestion: file one or more follow-on enhancements to add missing features (here and elsewhere).

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java line 58:

> 56: 
> 57:     void windowAdded(HeadlessWindow window) {
> 58:         if (this.activeWindow == null) activeWindow = window;

I think this means that if an app creates two windows, then closes the second, robot won't be able to capture anything from the first. Or will this method be called again on the first window when the second closes?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindowManager.java line 38:

> 36:                 .filter(win -> win.isVisible()).toList();
> 37:         for (Window win : windows) {
> 38:             if (win.isVisible() && (!win.isMinimized())) {

Minor: since you are already using streams, you could use a `.forEach` as the terminal operator rather than collecting it into a list to iterate over again. Separately, you could also convert the `!win.isMinimized()` test into a filter operation (note that the test for `win.isVisible()` is redundant since you already filter out non-visible windows).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3055871049
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2231391957
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2231707118
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2231500757

From nlisker at openjdk.org  Fri Jul 25 22:12:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 25 Jul 2025 22:12:01 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <Iz8JDP2C401WP2O2gLvQXf8737OF7om4-ORjlH2-MYA=.f8e07f3e-1c4b-41cd-8009-8bcbddb0369c@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>
Message-ID: <yiuKrNJdaiuQnttLjIgL2ozohkEuiOoIW8-h2Fv-XJw=.f384216f-e51f-43bb-9bd7-ac6ac2d0c92b@github.com>

On Fri, 25 Jul 2025 21:14:48 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oh, I thought you were saying that you didn't see that warning because of the compiler configuration, not the project configuration.
>> 
>> I manually added the source folders that are relevant to this PR and that are not in the default configuration. I'm not sure if there's merit to change the classpath file in the repo.
>> 
>> `unlikely argument type for collection methods using 'Object'` without `Perform strict analysis against the expected type` is enough to give this warning.
>
> all right, so we probably want to leave the project config as is, and this manual change is a one-off.  Do you mind listing the changes here for future reference?

I just looked at which .java files are not on the classpath and pulled those source folders in:
<img width="227" height="234" alt="image" src="https://github.com/user-attachments/assets/a81ef455-cc97-4b75-be96-cbd3de5bb266" />

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

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

From angorya at openjdk.org  Fri Jul 25 22:53:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 25 Jul 2025 22:53:42 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
Message-ID: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>

Fixed an NPE in the ToolBar, looks like a corner case.

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

Commit messages:
 - npe

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

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

From kizune at openjdk.org  Fri Jul 25 23:36:13 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 25 Jul 2025 23:36:13 GMT
Subject: RFR: 8358092: Create accessibility protocol implementation that covers
 various type of menu items
Message-ID: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>

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

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

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

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

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

From mstrauss at openjdk.org  Sat Jul 26 02:06:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 26 Jul 2025 02:06:06 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <tTKfuNra3aRf2jblExSoYUQ6rdetPwUyPK7UL0td4i4=.0a229885-86b4-40ca-ad7a-9b749cb0174f@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

Is this unit-testable?

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

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3120984515

From kcr at openjdk.org  Sat Jul 26 12:17:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 26 Jul 2025 12:17:00 GMT
Subject: [jfx25] RFR: 8359601: Fix window button states of an extended
 stage
In-Reply-To: <UFwd9vziwG8feAhXJIVOGapKCuTVCkpN4Z42Rp9FPMA=.00f012cc-e4f5-4985-a1b9-7be384eb07a8@github.com>
References: <UFwd9vziwG8feAhXJIVOGapKCuTVCkpN4Z42Rp9FPMA=.00f012cc-e4f5-4985-a1b9-7be384eb07a8@github.com>
Message-ID: <XQon0LN8l4LYAlBzW4mFCz616f4iYPAGODbaiEjTZiQ=.f6d6cd4d-b94a-44c2-9dc5-c599e946d6fb@github.com>

On Fri, 25 Jul 2025 13:10:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 8359601: Fix window button states of an extended stage

As noted in the mainline PR, this is a good fix to backport to jfx25. The backport is clean.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1855#pullrequestreview-3058038878

From kcr at openjdk.org  Sat Jul 26 12:17:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 26 Jul 2025 12:17:59 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: <32Ig7Zq1PgOoB_DAcy5NV9qD8hFEHp4bjVD_bKxQZIc=.d59f143b-9ced-4b64-8802-af7daacb9e22@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

Reviewers: @arapte @andy-goryachev-oracle

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

PR Comment: https://git.openjdk.org/jfx/pull/1858#issuecomment-3121729399

From mstrauss at openjdk.org  Sat Jul 26 17:17:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 26 Jul 2025 17:17:02 GMT
Subject: [jfx25] Integrated: 8359601: Fix window button states of an extended
 stage
In-Reply-To: <UFwd9vziwG8feAhXJIVOGapKCuTVCkpN4Z42Rp9FPMA=.00f012cc-e4f5-4985-a1b9-7be384eb07a8@github.com>
References: <UFwd9vziwG8feAhXJIVOGapKCuTVCkpN4Z42Rp9FPMA=.00f012cc-e4f5-4985-a1b9-7be384eb07a8@github.com>
Message-ID: <PumYO9H23b8Iaq_EWHJ6zNdCNPaB65vhcRKLfgx2Ht8=.68e2c1e9-d8fa-4bfe-a4e3-a531ddea78c4@github.com>

On Fri, 25 Jul 2025 13:10:03 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> 8359601: Fix window button states of an extended stage

This pull request has now been integrated.

Changeset: 5398b14c
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5398b14cac39a3e7371e3f837754a399ccd8b8ad
Stats:     604 lines in 20 files changed: 277 ins; 260 del; 67 mod

8359601: Fix window button states of an extended stage
8359763: Close request handler is not called for an extended stage

Reviewed-by: kcr
Backport-of: bc433da812461a1c2796cdb3123f814e4ce532d5

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

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

From tsayao at openjdk.org  Sun Jul 27 13:44:56 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 27 Jul 2025 13:44:56 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
Message-ID: <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@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 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

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

Changes: https://git.openjdk.org/jfx/pull/1789/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1789&range=49
  Stats: 4210 lines in 28 files changed: 2830 ins; 798 del; 582 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 Jul 27 15:20:02 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 27 Jul 2025 15:20:02 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v49]
In-Reply-To: <K38E6DrQAvsukrJrMQKTcCSGYlE3zOVEMH0JgIoFXYc=.6eb68911-52a0-47a8-825d-2547f560a558@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <MJaLuX2s_kx4fVw2vwB76tcqsIi5pagdOMICdpeJ7S4=.20cabf40-be00-4fcd-91d6-07f632e0a417@github.com>
 <K38E6DrQAvsukrJrMQKTcCSGYlE3zOVEMH0JgIoFXYc=.6eb68911-52a0-47a8-825d-2547f560a558@github.com>
Message-ID: <xMtWK5-tLYOH5uQOzrd8grH_qLytKOc5VIkuvtIJOIU=.bc14801e-d0a4-40c6-8044-440eddb94e90@github.com>

On Wed, 23 Jul 2025 11:07:06 GMT, Lukasz Kostyra <lkostyra 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 58 commits:
>> 
>>  - 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
>>  - Re-allow fullscreen on child
>>  - Test fixes for mac + typo
>>  - ... and 48 more: https://git.openjdk.org/jfx/compare/0270847b...016ff681
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1036:
> 
>> 1034: void WindowContext::notify_fullscreen(bool enter) {
>> 1035:     if (enter) {
>> 1036:         LOG("com_sun_glass_events_ViewEvent_FULLSCREEN_ENTER\n");
> 
> This could be simplified to
> 
> 
> LOG("com_sun_glass_events_ViewEvent_FULLSCREEN_%s\n", enter ? "ENTER" : "EXIT");
> mainEnv->CallVoidMethod(jview, jViewNotifyView, enter ? com_sun_glass_events_ViewEvent_FULLSCREEN_ENTER : com_sun_glass_events_ViewEvent_FULLSCREEN_EXIT);
> CHECK_JNI_EXCEPTION(mainEnv)

Done

> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1359:
> 
>> 1357: }
>> 1358: 
>> 1359: // This only works o Xorg
> 
> Minor: "works o" -> "works on"

Fixed

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2234027259
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2234027224

From mstrauss at openjdk.org  Sun Jul 27 18:46:46 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 27 Jul 2025 18:46:46 GMT
Subject: RFR: 8362091: Window title bar should reflect scene color scheme
 [v2]
In-Reply-To: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
References: <QZNwraDwbgXlaQTeGkLKu0tFnXRwK6ARs0YZoV2SWno=.595ca0ae-db3b-4fa2-8edb-bd656381fa98@github.com>
Message-ID: <Po6bwb1qC8ns2ghRckD0PUZAiSJprb1hBMHwwcCS7eE=.0252b8b6-5c8a-4faa-a713-da346a9efd32@github.com>

> 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

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

Changes: https://git.openjdk.org/jfx/pull/1845/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1845&range=01
  Stats: 183 lines in 17 files changed: 171 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1845.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1845/head:pull/1845

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

From mstrauss at openjdk.org  Sun Jul 27 18:48:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 27 Jul 2025 18:48:18 GMT
Subject: RFR: 8358820: Allow interpolation outside of range [0,1] [v3]
In-Reply-To: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
References: <5u8qmv4szpzdyxSDxxErYBM41szkfcPr7C-EnMjauzQ=.9f149d60-cf19-475f-a1ca-5a9643fa7396@github.com>
Message-ID: <zC6dOoZi_f2wmgF1vRatqmMd_naJanlT8NrKNGi4rS4=.4f4129c6-a978-4c39-be00-1dec1c22c273@github.com>

> JavaFX unnecessarily restricts interpolation in the following ways:
> 1. `Interpolatable` implementations often clamp intermediate values to the interpolation factor range [0,1].
> 2. `SplineInterpolator` doesn't accept Y coordinates outside of [0,1] for its control points. While this was probably done so that the computed interpolation factor doesn't exceed [0,1], the restriction goes far beyond that. For example, the following function is not representable, even though its values are all within the [0,1] range:<br>
>    <img src="https://github.com/user-attachments/assets/368b6142-052d-4ead-8a59-cbddf4a19660" width="400"/><br>
>    The following function is also not representable, but would be very useful for [bouncy animations](https://easings.net/#easeOutBack):<br>
>    <img src="https://github.com/user-attachments/assets/af02b044-ae4c-4250-b181-72178ad9f3f3" width="400"/>
> 
> Fortunately, there is no technical reason why JavaFX can't support the full range of animations that can be represented with a cubic Bezi?r interpolation function.
> 
> This PR includes the following changes:
> 1. The specification of `Interpolatable` is changed to require implementations to accept interpolation factors outside of [0,1].
> 2. All implementations of `Interpolatable` now correctly return intermediate values outside of [0,1].
> 3. `SplineInterpolator` now accepts control points with any Y coordinate.
> 
> Here's how the result looks like for the previously unrepresentable interpolation function `cubic-bezier(0.34, 2.2, 0.64, 1)`:<br>
> <img src="https://github.com/user-attachments/assets/72c10d0d-71b4-4bb5-b58c-ae377279b0fd" width="500"/>

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

 - Merge branch 'master' into feature/relaxed-interpolation
 - javadoc
 - Allow interpolation outside of range [0,1]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1822/files
  - new: https://git.openjdk.org/jfx/pull/1822/files/92d06d7e..26208229

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

  Stats: 18401 lines in 224 files changed: 15325 ins; 2250 del; 826 mod
  Patch: https://git.openjdk.org/jfx/pull/1822.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1822/head:pull/1822

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

From mstrauss at openjdk.org  Sun Jul 27 20:15:18 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 27 Jul 2025 20:15:18 GMT
Subject: RFR: 8358450: Viewport characteristics media features [v4]
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: <DObY1h8cFS39O3vy7gsWOXN-eddj7pPrSlosFXh8wC4=.a18d59ab-8db3-421e-bde8-e631a77fc61a@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 five additional commits since the last revision:

 - 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/8c93b359..0ce8703b

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

  Stats: 2151 lines in 73 files changed: 1546 ins; 381 del; 224 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 jvos at openjdk.org  Mon Jul 28 11:28:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 11:28:25 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v12]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <jiHlxqoeOOO2Vw7fxNV-hQ6OQJ0AnWjFlEwN9zKu4pc=.607af976-0e29-4f4b-a0d8-fe5725e22c51@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos 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 13 additional commits since the last revision:

 - Merge branch 'master' into 8324941-headless
 - Add copyright sections
 - Do not use System.getProperty() for getting configuration options for now.
   Especially, don't use properties prefixed for GTK.
 - Specify A as a double.
 - Do not invoke notifyMouse twice
 - Process more reviewer comments
 - More reviewer processing
 - Process reviewer comments
   Remove unused code
 - Process reviewer comments
 - Update modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessRobot.java
   
   use switch expressions
   
   Co-authored-by: mstr2 <43553916+mstr2 at users.noreply.github.com>
 - ... and 3 more: https://git.openjdk.org/jfx/compare/7521fac0...7adac9f1

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/46bb2072..7adac9f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1836&range=10-11

  Stats: 9682 lines in 150 files changed: 7528 ins; 1645 del; 509 mod
  Patch: https://git.openjdk.org/jfx/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1836/head:pull/1836

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

From jvos at openjdk.org  Mon Jul 28 11:38:26 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 11:38:26 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v13]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <eq15iQ92LxyjOKkeeLLenwdrAssgACOYVl773-MWjbE=.9d5fa110-f1ce-4d04-bd34-80af3c4750b0@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Remove modal support implementation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/7adac9f1..3c623618

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

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

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

From lkostyra at openjdk.org  Mon Jul 28 12:13:04 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 28 Jul 2025 12:13:04 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <0YELjMcGLrI9tYp6inpQHyziq8n5pYXtxS-glXK4mJg=.e9f7a8e0-46dd-47d9-bf10-9cac3dd51f66@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
 <0YELjMcGLrI9tYp6inpQHyziq8n5pYXtxS-glXK4mJg=.e9f7a8e0-46dd-47d9-bf10-9cac3dd51f66@github.com>
Message-ID: <GXs98RHCXxHQVsM8YOLT_-bHqIYOxZE0xAd3YFqKDMY=.27396c40-3e74-4a14-9f2c-b669b8d401fd@github.com>

On Fri, 25 Jul 2025 20:17:24 GMT, Martin Fox <mfox at openjdk.org> wrote:

> BTW, this test also fails on macOS 16 unless `--no-daemon` is specified. I'm also seeing failures on the MenuDoubleShortcutTest that are new. So it looks like macOS has also tightened up security related to background processes stealing focus.

Thanks for checking! I don't have access to macOS 16 yet, so it's good to know this ahead of time.

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

PR Comment: https://git.openjdk.org/jfx/pull/1804#issuecomment-3126941262

From kcr at openjdk.org  Mon Jul 28 12:43:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 12:43:04 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v13]
In-Reply-To: <eq15iQ92LxyjOKkeeLLenwdrAssgACOYVl773-MWjbE=.9d5fa110-f1ce-4d04-bd34-80af3c4750b0@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <eq15iQ92LxyjOKkeeLLenwdrAssgACOYVl773-MWjbE=.9d5fa110-f1ce-4d04-bd34-80af3c4750b0@github.com>
Message-ID: <HAlaPff88iW3fWnAQXWYjPcVc2WFbxGMO85jllR8ZVI=.db3f2c8b-0702-410b-b914-acd2230537d3@github.com>

On Mon, 28 Jul 2025 11:38:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove modal support implementation

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3062449652

From kcr at openjdk.org  Mon Jul 28 13:13:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 13:13:06 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <vRcXufP_KXcXJH-8y0YgaJflTi7u_ACW1X6JscinZXM=.a97c24d0-2634-4b91-b00b-8c822877bd1a@github.com>

On Fri, 25 Jul 2025 17:13:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

@arapte Can you review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3127180350

From tsayao at openjdk.org  Mon Jul 28 14:15:09 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 28 Jul 2025 14:15:09 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
Message-ID: <svdBNlTrhxolRneegSJMA93Alziav8QZEifHvTz87Xo=.41e3331c-5f9c-4409-afbc-9c6994ecd460@github.com>

On Sun, 27 Jul 2025 13:44:56 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 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

> 1. This PR fixes quite a bit of issues we had with Linux that were reported, they are listed in the PR description. Can you link all of them via Skara's `/issue add <JDK-ID>` so that they get resolved once this PR goes through? I t> I also did an initial test run, I did get quite a bit of failures (Ubuntu 24.04.2 LTS VM, Gnome 46 on Wayland, 91 total tests failing; to name a few prominent groups that fail - `TextCharacterIndexTest`, `TextFlowSurrogatePairInsertionIndexTest`, `RegionBackgroundFillUITest`, `RegionBackgroundImageUITest`) but I'm not sure if those also fail on master yet - I'll re-check after the master merge.


Those tests are failing for me too, I'll look into it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1789#issuecomment-3127428513

From angorya at openjdk.org  Mon Jul 28 14:48:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 14:48:06 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v13]
In-Reply-To: <eq15iQ92LxyjOKkeeLLenwdrAssgACOYVl773-MWjbE=.9d5fa110-f1ce-4d04-bd34-80af3c4750b0@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <eq15iQ92LxyjOKkeeLLenwdrAssgACOYVl773-MWjbE=.9d5fa110-f1ce-4d04-bd34-80af3c4750b0@github.com>
Message-ID: <wiCS1QRpZLyjsTuFn9_OKuvQwxzfTo2qti7TEjqHyvw=.eb699148-fb72-4923-9c8c-f1a3ec454222@github.com>

On Mon, 28 Jul 2025 11:38:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove modal support implementation

Marked as reviewed by angorya (Reviewer).

modules/javafx.graphics/src/main/java/com/sun/glass/ui/headless/HeadlessWindow.java line 56:

> 54:     private HeadlessRobot robot;
> 55: 
> 56:     private final int stride = 1000;

I see you've created [JDK-8364201](https://bugs.openjdk.org/browse/JDK-8364201) for the configuration options, thank you.

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3063150496
PR Review Comment: https://git.openjdk.org/jfx/pull/1836#discussion_r2236790770

From jvos at openjdk.org  Mon Jul 28 15:13:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 15:13:07 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v14]
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Optimize getting latest windows

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1836/files
  - new: https://git.openjdk.org/jfx/pull/1836/files/3c623618..b9148ed2

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

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

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

From jpereda at openjdk.org  Mon Jul 28 15:21:03 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 28 Jul 2025 15:21:03 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v14]
In-Reply-To: <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
Message-ID: <LTPgCg9MovreePTvrdPFk4-5zfZWRcP2li6zc0Pqqfk=.0d605e8e-065e-4dca-9561-91f5e965b28f@github.com>

On Mon, 28 Jul 2025 15:13:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize getting latest windows

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3063323915

From angorya at openjdk.org  Mon Jul 28 16:11:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 16:11:03 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v14]
In-Reply-To: <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
Message-ID: <3-6Spt-rE78ml-CKZ9q8kGXsNhyGGX1KLaJiWbstaeg=.2015ac7d-b28e-4c94-ba3b-0e70f56c4338@github.com>

On Mon, 28 Jul 2025 15:13:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize getting latest windows

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3063572383

From jvos at openjdk.org  Mon Jul 28 16:56:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 16:56:08 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v11]
In-Reply-To: <gPyDWX-EOYflKGf05PII60n2NoUIn1Io18MoLYVR-nI=.4e1542c6-ed52-48e9-bcc3-ae75973c4b65@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <Eg1oJr8LlBxlFOFvtoydmIY4-TsxbwIo9z7hXFeMqEQ=.e72be504-1183-4c93-930b-01265e890bf4@github.com>
 <gPyDWX-EOYflKGf05PII60n2NoUIn1Io18MoLYVR-nI=.4e1542c6-ed52-48e9-bcc3-ae75973c4b65@github.com>
Message-ID: <at-rwgi9xOdB4qSCIE5APv48OLrc8Ru-nDtZ4pvi-As=.7c5999b5-8ed1-4a9a-9953-c9afd264bf57@github.com>

On Fri, 25 Jul 2025 13:42:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add copyright sections
>
> I'll review the code soon. I ran a full set of tests, excluding the robot tests, and see two failures (below), which you mentioned are expected. Presumably these are the same two failures you see?
> 
> It would probably be best to skip these two tests when running the Headless glass platform. This could either be done as part of this PR or in a follow-up "Skip failing tests on Headless glass platform" bug.
> 
> 1. MacPasteboardTest
> 
> 
> MacPasteboardTest > testValidLocalImageURLMacPasteboard() FAILED
>     java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
>         at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testValidLocalImageURLMacPasteboard$0(MacPasteboardTest.java:73)
> 
> MacPasteboardTest > testDataBase64ImageMacPasteboard() FAILED
>     java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
>         at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testDataBase64ImageMacPasteboard$0(MacPasteboardTest.java:89)
> 
> MacPasteboardTest > testNotAnImageURLMacPasteboard() FAILED
>     java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.mac.MacPasteboardShim.pushMacPasteboard(java.util.HashMap)" because "test.com.sun.glass.ui.mac.MacPasteboardTest.macPasteboardShim" is null
>         at test.com.sun.glass.ui.mac.MacPasteboardTest.lambda$testNotAnImageURLMacPasteboard$0(MacPasteboardTest.java:100)
> 
> 
> The tests in this class assume we are running the Mac glass platform, so they should all be skipped when running the Headless glass platform. One way to do this would be to add a `PlatformUtil::isHeadless` method and change all of the `assumeTrue(PlatformUtil.isMac())` calls to `assumeTrue(PlatformUtil.isMac() && !PlatformUtil.isHeadless())`. The assumeTrue wouldn't be annotated with a bug ID, since this expresses a fundamental requirement of the test, not a bug that needs to be fixed.
> 
> 
> 2. ClipboardTest::testCopyUTF8String
> 
> 
> ClipboardTest > testCopyUTF8String() FAILED
>     org.opentest4j.AssertionFailedError: expected: < Jump to: ?? Jump> but was: <HEADLESS_TEST>
>         at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>         at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:...

@kevinrushforth I made one more final change, can you re-approve if you agree?

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

PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3128136836

From kcr at openjdk.org  Mon Jul 28 17:00:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 17:00:03 GMT
Subject: RFR: 8324941: POC for Headless platform for JavaFX [v14]
In-Reply-To: <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
 <XVWuF7yRZkN_KWljECNph04ARp3G7h7FvJgTSK269pE=.ef5e4ade-7c9e-468d-bde9-7e5bed67a105@github.com>
Message-ID: <hb3SIPSzp3qXSwsLAn6mWW7ikwBSzRfZY4jLJZSq5Sw=.3280a9d0-5287-4135-9bb8-3124068a16c9@github.com>

On Mon, 28 Jul 2025 15:13:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
>> 
>> ### the Headless Platform
>> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
>> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
>> 
>> ### changes
>> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
>> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
>> 
>> ### enable the Headless Platform
>> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
>> 
>> ### testing
>> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
>> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
>> 
>> ### robot tests
>> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize getting latest windows

Marked as reviewed by kcr (Lead).

Oh, I thought I already had.

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

PR Review: https://git.openjdk.org/jfx/pull/1836#pullrequestreview-3063798409
PR Comment: https://git.openjdk.org/jfx/pull/1836#issuecomment-3128151564

From angorya at openjdk.org  Mon Jul 28 17:22:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 17:22:11 GMT
Subject: RFR: 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: <ek6EXuYxvLFQlWZwWY4YthXMLn_fQby3b8CULlmBHsI=.7923746a-0c61-4d06-87a8-2c9115ee9e98@github.com>

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

> Fix for phantom disclosure nodes appearing when root is null

Hmm, I am not sure this is the right solution: remember, the tree works just fine if you change the root in the form of `TreeItem<>(new Entry(null))`, but breaks when you set `TreeItem<>(null)`.
 
This means one thing: the logic is there, but the `null` content of TreeItem messes it up.
 
Can you try one thing: run two instances of the app in the debugger side by side and step through the relevant parts of the code, until you find the difference?  I suspect some condition breaks when it encounters null.

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

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

From zelmidaoui at openjdk.org  Mon Jul 28 17:22:11 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 28 Jul 2025 17:22:11 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root with
 null value
Message-ID: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>

Fix for phantom disclosure nodes appearing when root is null

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

Commit messages:
 - Fix for issue with null root in TreeView
 - Merge branch 'openjdk:master' into 8341286.TreeViewArtifacts
 - Partial fix

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

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

From jvos at openjdk.org  Mon Jul 28 17:23:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 17:23:07 GMT
Subject: Integrated: 8324941: POC for Headless platform for JavaFX
In-Reply-To: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
References: <TR2wnb0BycFoqHjvefO8A3KE1L-b6L79Sq8i_oC2eTM=.376664f8-2623-43fa-8f22-f2ae22ef9751@github.com>
Message-ID: <JUK_IpFW1TmVivsYWtUAehyTnVD30ZJsUnP2XAOGGMo=.528cfd21-8f8d-4c53-98c9-a87a8b2f60a5@github.com>

On Thu, 19 Jun 2025 08:33:52 GMT, Johan Vos <jvos at openjdk.org> wrote:

> After spending a year in the sandbox repository, the Headless Platform is now ready to be reviewed in the main repository.
> 
> ### the Headless Platform
> The Headless Platform is a top-level com.sun.glass.ui platform that replaces the second-level Monocle-Headless subplatform, that is part of the top-level Monocle platform. 
> The platform can be used like any other platform, especially for running headless JavaFX applications, or for running tests (e.g. on CI systems)
> 
> ### changes
> The code for the Headless Platform is in a new package com.sun.glass.ui.headless in the javafx.graphics module, and it does not require a code change in other packages.
> This PR adds a simple change in the `build.gradle` file, to make the Headless Platform the standard when running headless tests (instead of using Monocle/Headless)
> 
> ### enable the Headless Platform
> Setting the system property `glass.platform` to `Headless` will select the Headless Platform instead of the default one (either gtk, mac or win).
> 
> ### testing
> `gradlew --info -PHEADLESS_TEST=true -PFULL_TEST=true :systemTests:cleanTest :systemTests:test`
> runs all the system tests, apart from the robot tests. There are 2 failing tests, but there are valid reasons for those to fail.
> 
> ### robot tests
> Most of the robot tests are working on headless as well. add `-PUSE_ROBOT` to test those.

This pull request has now been integrated.

Changeset: 3c4d2905
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3c4d29057999af89f3264810cb48a2819fdecf8e
Stats:     1607 lines in 11 files changed: 1603 ins; 2 del; 2 mod

8324941: POC for Headless platform for JavaFX

Reviewed-by: kcr, angorya, jpereda

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

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

From kcr at openjdk.org  Mon Jul 28 17:30:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 17:30:01 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v7]
In-Reply-To: <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <dMHgKNuUYtS4-LXxq1GdyPHxWKEkJSO69nIFR6oB83o=.128517ca-41b8-4683-a90a-63920fec3db9@github.com>
Message-ID: <UMFq81UVXV8hxmXQF0KcF82cVC0VBLat5JZS32JEk0E=.78bff6f2-1571-47a0-abc2-8098547162cc@github.com>

On Thu, 17 Jul 2025 09:18:42 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust error message for window-on-top check

Looks good. I verified on Windows that this test fails when I use the gradle daemon and passes without. I left one minor comment, but it is harmless to leave it as is. I'll reapprove if you change it.

tests/system/src/test/java/test/robot/javafx/stage/StageFocusTest.java line 94:

> 92:     public static void setupOnce() throws InterruptedException {
> 93:         Util.launch(launchLatch, TestApp.class);
> 94:         assertTrue(launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS), "Timeout waiting for test stage to be shown");

Minor: This is redundant, since `Util.launch` already waits for the latch to countdown (and if it hadn't already been done, a 2 second wait for toolkit startup is too short).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-3063678722
PR Review Comment: https://git.openjdk.org/jfx/pull/1804#discussion_r2237184929

From angorya at openjdk.org  Mon Jul 28 18:51:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 18:51:58 GMT
Subject: RFR: 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: <hScUlwIRILzC5qiqQA-hDXcW_B1MDm0_UJcDj9WDz_0=.ff159642-d720-4d56-96f5-4c3ff8a566c3@github.com>

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

> Fix for phantom disclosure nodes appearing when root is null

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 363:

> 361:     private void updateDisclosureNode() {
> 362: //        JDK-8341281 : Root TreeItem with null value breaks TreeTableView
> 363: //        if (getSkinnable().isEmpty()) return;

I think you've got it!
I can't reproduce the issue with your fix - both the reproducer and the monkey tester work correctly.

You don't need to keep the commented out code, please remove it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1838#discussion_r2237563172

From angorya at openjdk.org  Mon Jul 28 18:54:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 18:54:57 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <tTKfuNra3aRf2jblExSoYUQ6rdetPwUyPK7UL0td4i4=.0a229885-86b4-40ca-ad7a-9b749cb0174f@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
 <tTKfuNra3aRf2jblExSoYUQ6rdetPwUyPK7UL0td4i4=.0a229885-86b4-40ca-ad7a-9b749cb0174f@github.com>
Message-ID: <PLSUSlUVUPwKeYqggKH1pXv2Fsx9Tf-yl69QKz_1YXI=.9a2ad271-22af-404a-9332-e651889efbaa@github.com>

On Sat, 26 Jul 2025 02:03:26 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Is this unit-testable?

I would say it's probably not worth it, but I'll try come up with a headless test.  I certainly don't want a headful test for what looks like a programmer's oversight.

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

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3128546969

From angorya at openjdk.org  Mon Jul 28 20:38:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 28 Jul 2025 20:38:03 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: <Z1KFug-TIHjqbyqjuvmwJSbA46dxfg-K0BNGcMDEKHc=.a27e0515-b409-4900-ae8d-64870e8385c4@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

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 43:

> 41:      * enum javafx.scene.AccessibleRole
> 42:      */
> 43:     rolesMap = [[NSMutableDictionary alloc] initWithCapacity:21];

would it make more sense to set the expected size once and for all?

modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 65:

> 63:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"MENU_ITEM"];
> 64:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"RADIO_MENU_ITEM"];
> 65:     [rolesMap setObject:@"JFXMenuItemAccessibility" forKey:@"CHECK_MENU_ITEM"];

Question: do we need another entry for the `CustomMenuItem`?  It looks like the VoiceOver on macOS 15.5 announces a custom menu as "`menuText, interactive`" which seems correct.

There is also `SeparatorMenuItem`, though I suspect there is no need to add accessibility to it, is there?  (one can't focus on the menu separator).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1858#discussion_r2237800272
PR Review Comment: https://git.openjdk.org/jfx/pull/1858#discussion_r2237805194

From jvos at openjdk.org  Mon Jul 28 20:45:11 2025
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 28 Jul 2025 20:45:11 GMT
Subject: RFR: 8364203: ignore native mac tests on headless
Message-ID: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>

Add PlatformUtil.isHeadless() method.
Use that in tests to conditionally skip tests.

Fix JDK-8364203

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

Commit messages:
 - Add PlatformUtil.isHeadless() method.

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

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

From kcr at openjdk.org  Mon Jul 28 21:34:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 21:34:00 GMT
Subject: RFR: 8364203: ignore native mac tests on headless
In-Reply-To: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
References: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
Message-ID: <HTFg6kwnzm3N7OcFrOl0pNkHg1bpDQfNGR-h-rgCCxI=.820a6026-b19a-4cde-8838-3365b83b432d@github.com>

On Mon, 28 Jul 2025 20:41:46 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Add PlatformUtil.isHeadless() method.
> Use that in tests to conditionally skip tests.
> 
> Fix JDK-8364203

This looks reasonable with one comment inline.

Also, as noted by Skara, I recommend to capitalize the first letter of the title (both JBS and PR) for consistency.

tests/system/src/test/java/test/com/sun/glass/ui/mac/MacPasteboardTest.java line 70:

> 68:     @Test
> 69:     public void testValidLocalImageURLMacPasteboard() throws Exception {
> 70:         assumeTrue(PlatformUtil.isMac() && !PlatformUtil.isHeadless());

`setup` and `teardown` should probably be similarly qualified with "not headless".

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

PR Review: https://git.openjdk.org/jfx/pull/1859#pullrequestreview-3064631426
PR Review Comment: https://git.openjdk.org/jfx/pull/1859#discussion_r2237873525

From zelmidaoui at openjdk.org  Mon Jul 28 22:27:29 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 28 Jul 2025 22:27:29 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value
In-Reply-To: <hScUlwIRILzC5qiqQA-hDXcW_B1MDm0_UJcDj9WDz_0=.ff159642-d720-4d56-96f5-4c3ff8a566c3@github.com>
References: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
 <hScUlwIRILzC5qiqQA-hDXcW_B1MDm0_UJcDj9WDz_0=.ff159642-d720-4d56-96f5-4c3ff8a566c3@github.com>
Message-ID: <vRsudCqv5IEE3XQ7A1i1O7pt5ElHqbUZ4sDNFvdg11U=.da110f0f-d0f9-481e-ba8d-8180651e91a7@github.com>

On Mon, 28 Jul 2025 18:49:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fix for phantom disclosure nodes appearing when root is null
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 363:
> 
>> 361:     private void updateDisclosureNode() {
>> 362: //        JDK-8341281 : Root TreeItem with null value breaks TreeTableView
>> 363: //        if (getSkinnable().isEmpty()) return;
> 
> I think you've got it!
> I can't reproduce the issue with your fix - both the reproducer and the monkey tester work correctly.
> 
> You don't need to keep the commented out code, please remove it.

Yes this is what caused the issue and the disclosure nodes to appear randomly
I will remove it

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1838#discussion_r2237960762

From zelmidaoui at openjdk.org  Mon Jul 28 22:27:29 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 28 Jul 2025 22:27:29 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value
In-Reply-To: <vRsudCqv5IEE3XQ7A1i1O7pt5ElHqbUZ4sDNFvdg11U=.da110f0f-d0f9-481e-ba8d-8180651e91a7@github.com>
References: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
 <hScUlwIRILzC5qiqQA-hDXcW_B1MDm0_UJcDj9WDz_0=.ff159642-d720-4d56-96f5-4c3ff8a566c3@github.com>
 <vRsudCqv5IEE3XQ7A1i1O7pt5ElHqbUZ4sDNFvdg11U=.da110f0f-d0f9-481e-ba8d-8180651e91a7@github.com>
Message-ID: <ukHbTMns6F76ieq3CLq0l6da9fWxwJd9alAErL2Znps=.8077feb8-e0d8-46c2-a67d-7f5b265087bb@github.com>

On Mon, 28 Jul 2025 22:20:52 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeCellSkin.java line 363:
>> 
>>> 361:     private void updateDisclosureNode() {
>>> 362: //        JDK-8341281 : Root TreeItem with null value breaks TreeTableView
>>> 363: //        if (getSkinnable().isEmpty()) return;
>> 
>> I think you've got it!
>> I can't reproduce the issue with your fix - both the reproducer and the monkey tester work correctly.
>> 
>> You don't need to keep the commented out code, please remove it.
>
> Yes this is what caused the issue and the disclosure nodes to appear randomly
> I will remove it

Yes this is what caused the issue and the disclosure nodes to appear randomly
I will remove it

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1838#discussion_r2237961415

From kcr at openjdk.org  Mon Jul 28 22:33:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 28 Jul 2025 22:33:17 GMT
Subject: RFR: 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: <JJAnMJm1FqtQmoGdaXskoSHzGxPWw_0GyvrunjkwrAc=.2ad53d6e-50e6-46d1-a738-0115953b6ab4@github.com>

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

> Fix for phantom disclosure nodes appearing when root is null

@Ziad-Mid Can you add an evaluation to this PR (you can add it to the Description)? This may indeed be the right fix, but a good evaluation should explain the problem and why this is the right fix.

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

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

From kizune at openjdk.org  Tue Jul 29 02:18:23 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 29 Jul 2025 02:18:23 GMT
Subject: RFR: 8358092: Create accessibility protocol implementation that
 covers various type of menu items
In-Reply-To: <Z1KFug-TIHjqbyqjuvmwJSbA46dxfg-K0BNGcMDEKHc=.a27e0515-b409-4900-ae8d-64870e8385c4@github.com>
References: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
 <Z1KFug-TIHjqbyqjuvmwJSbA46dxfg-K0BNGcMDEKHc=.a27e0515-b409-4900-ae8d-64870e8385c4@github.com>
Message-ID: <gr9fCbq9Z5HgXEjYK-L6ifjjj7c2S7goz2vlRRIkiIM=.1a532e89-d1d2-4d42-a212-adcd8fb88ac5@github.com>

On Mon, 28 Jul 2025 20:26:35 GMT, Andy Goryachev <angorya 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
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 43:
> 
>> 41:      * enum javafx.scene.AccessibleRole
>> 42:      */
>> 43:     rolesMap = [[NSMutableDictionary alloc] initWithCapacity:21];
> 
> would it make more sense to set the expected size once and for all?

Well, right now i can not predict what would be the size of this dictionary. More than 21 but for sure less than 100. And it does not bother me to increase the capacity when i add new implementations - on the contrary, sometimes i recount components and check the capacity - and that is how i can catch the discrepancy when i implemented a component but forgot to add it to the dictionary :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1858#discussion_r2238163971

From kizune at openjdk.org  Tue Jul 29 02:23:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 29 Jul 2025 02:23:11 GMT
Subject: RFR: 8358092: Create accessibility protocol implementation that
 covers various type of menu items
In-Reply-To: <Z1KFug-TIHjqbyqjuvmwJSbA46dxfg-K0BNGcMDEKHc=.a27e0515-b409-4900-ae8d-64870e8385c4@github.com>
References: <5OB6dv2pi8zUgsgYLxi6RpR6gVJ8JiVybO5Azt_a30Y=.79d0b191-e471-4628-aae4-833097d122e0@github.com>
 <Z1KFug-TIHjqbyqjuvmwJSbA46dxfg-K0BNGcMDEKHc=.a27e0515-b409-4900-ae8d-64870e8385c4@github.com>
Message-ID: <YGXImGfQeGjE49qqxxY0e4YWoeTCpq0unSb3H4QwpuA=.2b0c8d8a-59c2-4c34-8f5e-04be3154d0ae@github.com>

On Mon, 28 Jul 2025 20:29:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Question: do we need another entry for the `CustomMenuItem`? It looks like the VoiceOver on macOS 15.5 announces a custom menu as "`menuText, interactive`" which seems correct.

I don't think so - as long as they are menu items it should respond to the menu item related accessibility requests and actions, if they extend the functionality then a11y subsystem will not know what to do with them anyways so treating them as menu items from a11y perspective is perfectly fine.

> There is also `SeparatorMenuItem`, though I suspect there is no need to add accessibility to it, is there? (one can't focus on the menu separator).

You can navigate to menu separator with the hovering controllers such as eye tracker and with the accessibility navigation shortcuts. But existing implementation covers it - they have both label and title as NULL so system deducts that they are separators and announces them as such.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1858#discussion_r2238169709

From kizune at openjdk.org  Tue Jul 29 02:25:39 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 29 Jul 2025 02:25:39 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <hVc-4fEKZDEI0xse4El_8-0T6XsF7I4ji88Q6rQIORg=.a9cf76f8-898c-4468-ae9b-eaeb52c6c36a@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

Change looks good but just for my curiosity - how do we get to this point? Any minimal test case?

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

Marked as reviewed by kizune (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1857#pullrequestreview-3064991403

From jvos at openjdk.org  Tue Jul 29 07:12:52 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 29 Jul 2025 07:12:52 GMT
Subject: RFR: 8364203: Ignore native mac tests on headless [v2]
In-Reply-To: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
References: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
Message-ID: <whC_bbk276g9vRJgDQ5GX8xaDbQJOLYvaNcrohMzxKg=.11c2464d-3b73-4eab-8547-a77a6e960ad5@github.com>

> Add PlatformUtil.isHeadless() method.
> Use that in tests to conditionally skip tests.
> 
> Fix JDK-8364203

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Exclude setup/teardown in case of headless platform

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1859/files
  - new: https://git.openjdk.org/jfx/pull/1859/files/ceec1c3e..0a7a7be9

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

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

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

From perini.davide at dpsoftware.org  Tue Jul 29 10:32:47 2025
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Tue, 29 Jul 2025 12:32:47 +0200
Subject: WARNING: A restricted method in java.lang.System has been called
Message-ID: <893df54f-f906-4119-8c39-2b3bd29f5116@dpsoftware.org>

Will this be fixed soon?

Thanks

```
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by 
com.sun.glass.utils.NativeLibLoader in module javafx.graphics 
(file:/C:/Users/sblantipodi/.m2/repository/org/openjfx/javafx-graphics/24/javafx-graphics-24-win.jar)
WARNING: Use --enable-native-access=javafx.graphics to avoid a warning 
for callers in this module
WARNING: Restricted methods will be blocked in a future release unless 
native access is enabled
```



From zelmidaoui at openjdk.org  Tue Jul 29 11:32:00 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 29 Jul 2025 11:32:00 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value [v2]
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: <TPpwDp6sbrXDs5oSZHYFL0MElFDbOgrAkvS92ShstME=.4e9513ea-1d84-48a4-b1ef-c76f0fe92c27@github.com>

> Fix for phantom disclosure nodes appearing when root is null

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Update TreeCellSkin.java

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1838/files
  - new: https://git.openjdk.org/jfx/pull/1838/files/1a013988..2d832143

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

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

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

From lkostyra at openjdk.org  Tue Jul 29 11:53:14 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 29 Jul 2025 11:53:14 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v8]
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <RkFskqtsQv-RREWkdc_ry1RuUGEjwfgBktZGszE4miY=.fadf827a-675d-4603-b2e9-6460364eb4b0@github.com>

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant latch wait on setupOnce

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1804/files
  - new: https://git.openjdk.org/jfx/pull/1804/files/90be8123..7b63d5b6

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

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

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

From kcr at openjdk.org  Tue Jul 29 11:58:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 11:58:02 GMT
Subject: RFR: 8351357: Add canary system test checking if Stage receives
 focus on show [v8]
In-Reply-To: <RkFskqtsQv-RREWkdc_ry1RuUGEjwfgBktZGszE4miY=.fadf827a-675d-4603-b2e9-6460364eb4b0@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
 <RkFskqtsQv-RREWkdc_ry1RuUGEjwfgBktZGszE4miY=.fadf827a-675d-4603-b2e9-6460364eb4b0@github.com>
Message-ID: <_ZU8SX9oXoQ-6q9vL6Ykzt3PrtRnqz-hF8HbrcNxcck=.d737bd4e-cf7c-414b-9fba-399f79bde122@github.com>

On Tue, 29 Jul 2025 11:53:14 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
>> 
>> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
>> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
>> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
>> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
>> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
>> 
>> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
>> 
>> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
>> 
>> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing...
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant latch wait on setupOnce

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1804#pullrequestreview-3067137784

From kevin.rushforth at oracle.com  Tue Jul 29 12:17:10 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 29 Jul 2025 05:17:10 -0700
Subject: WARNING: A restricted method in java.lang.System has been called
In-Reply-To: <893df54f-f906-4119-8c39-2b3bd29f5116@dpsoftware.org>
References: <893df54f-f906-4119-8c39-2b3bd29f5116@dpsoftware.org>
Message-ID: <d4ae18dd-3c6a-4254-b670-02dd0e1d125a@oracle.com>

This isn't a bug, but is the expected behavior of libraries or 
applications that use JNI or FFM native calls after JEP 472 [1]. 
Applications must now specify 
`--enable-native-access=<list-of-modules>`? as indicated in the JavaFX 
24 release notes [2]. See JDK-8347744 [3] for more information. Failure 
to do so will print a warning with JDK 24 and JDK 25, and will fail in 
the future.

--Kevin

[1] https://openjdk.org/jeps/472
[2] 
https://github.com/openjdk/jfx/blob/master/doc-files/release-notes-24.md#javafx-applications-must-use---enable-native-access
[3] https://bugs.openjdk.org/browse/JDK-8347744

On 7/29/2025 3:32 AM, Davide Perini wrote:
> Will this be fixed soon?
>
> Thanks
>
> ```
> WARNING: A restricted method in java.lang.System has been called
> WARNING: java.lang.System::load has been called by 
> com.sun.glass.utils.NativeLibLoader in module javafx.graphics 
> (file:/C:/Users/sblantipodi/.m2/repository/org/openjfx/javafx-graphics/24/javafx-graphics-24-win.jar)
> WARNING: Use --enable-native-access=javafx.graphics to avoid a warning 
> for callers in this module
> WARNING: Restricted methods will be blocked in a future release unless 
> native access is enabled
> ```
>
>


From kcr at openjdk.org  Tue Jul 29 12:30:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 12:30:04 GMT
Subject: RFR: 8364203: Ignore native mac tests on headless [v2]
In-Reply-To: <whC_bbk276g9vRJgDQ5GX8xaDbQJOLYvaNcrohMzxKg=.11c2464d-3b73-4eab-8547-a77a6e960ad5@github.com>
References: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
 <whC_bbk276g9vRJgDQ5GX8xaDbQJOLYvaNcrohMzxKg=.11c2464d-3b73-4eab-8547-a77a6e960ad5@github.com>
Message-ID: <7J9kneb-kePN0eUvef9C-BRHfLCeXO5dZQhLQMtOjFM=.36a37ec0-ba11-4840-b57a-470db960b072@github.com>

On Tue, 29 Jul 2025 07:12:52 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Add PlatformUtil.isHeadless() method.
>> Use that in tests to conditionally skip tests.
>> 
>> Fix JDK-8364203
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude setup/teardown in case of headless platform

LGTM. I verified that the test is still run normally and skipped when running headless glass.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1859#pullrequestreview-3067273998

From kcr at openjdk.org  Tue Jul 29 12:52:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 12:52:08 GMT
Subject: [jfx25u] Integrated: Merge jfx:jfx25
In-Reply-To: <0iwFxuji0aO2fYZp7Ji7tVuC3RhOrOXOGjXkNPhHSY8=.dfc32502-3f49-45d2-873e-9d5a36471eaa@github.com>
References: <0iwFxuji0aO2fYZp7Ji7tVuC3RhOrOXOGjXkNPhHSY8=.dfc32502-3f49-45d2-873e-9d5a36471eaa@github.com>
Message-ID: <5tHSyZMA4aH7OGwkLv26K2vFreYdK8uqj8PllJVr--s=.9875daae-8229-4687-8c47-a2d511f268f0@github.com>

On Tue, 29 Jul 2025 12:42:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of `jfx:jfx25` into `jfx25u:master`.

This pull request has now been integrated.

Changeset: dd83b798
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx25u/commit/dd83b798293680712eb28b42a6af44d105774db7
Stats:     685 lines in 26 files changed: 324 ins; 264 del; 97 mod

Merge

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

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

From kcr at openjdk.org  Tue Jul 29 12:52:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 12:52:08 GMT
Subject: [jfx25u] Integrated: Merge jfx:jfx25
Message-ID: <0iwFxuji0aO2fYZp7Ji7tVuC3RhOrOXOGjXkNPhHSY8=.dfc32502-3f49-45d2-873e-9d5a36471eaa@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-07-29
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos
 - 8362896: Change JavaFX release version to 25.0.1 in jfx25u

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx25u/pull/3/files
  Stats: 271 lines in 4 files changed: 1 ins; 256 del; 14 mod
  Patch: https://git.openjdk.org/jfx25u/pull/3.diff
  Fetch: git fetch https://git.openjdk.org/jfx25u.git pull/3/head:pull/3

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

From jvos at openjdk.org  Tue Jul 29 13:50:03 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 29 Jul 2025 13:50:03 GMT
Subject: Integrated: 8364203: Ignore native mac tests on headless
In-Reply-To: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
References: <RkxlYA9_ukf-5ljAMaGZJmORXYyz2jYZEKpVGxQFO1Q=.fedd369e-2c6d-4719-b2d6-b96c74a78301@github.com>
Message-ID: <Zv19-IcmVBNwTNAvBQVO_yC_VMqBXZeXdsEwBC7GUAA=.873c0abe-4d1c-49f0-b272-626465e53816@github.com>

On Mon, 28 Jul 2025 20:41:46 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Add PlatformUtil.isHeadless() method.
> Use that in tests to conditionally skip tests.
> 
> Fix JDK-8364203

This pull request has now been integrated.

Changeset: 9ba9ec6a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9ba9ec6ae408d8959320a056a421b7212712ba8a
Stats:     13 lines in 2 files changed: 8 ins; 0 del; 5 mod

8364203: Ignore native mac tests on headless

Reviewed-by: kcr

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

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

From kevin.rushforth at oracle.com  Tue Jul 29 13:58:14 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 29 Jul 2025 06:58:14 -0700
Subject: JDK24 WARNING: Please consider reporting this to the maintainers
 of class com.sun.marlin.OffHeapArray
In-Reply-To: <16293249-7d78-48b3-8498-8a9d4062b736@oracle.com>
References: <26111975-94af-44bc-8749-327972b0efbe@dpsoftware.org>
 <16293249-7d78-48b3-8498-8a9d4062b736@oracle.com>
Message-ID: <85125483-2101-47d4-af62-def134d9eba2@oracle.com>

Redirecting this to openjfx-dev which is a more relevant mailing list.

-- Kevin

On 7/29/2025 6:50 AM, Kevin Rushforth wrote:
> Thanks for the report. This has been fixed in JavaFX 25 by JDK-8334137 
> [1].
>
> Thanks.
>
> -- Kevin
>
> [1] https://bugs.openjdk.org/browse/JDK-8334137
>
> On 7/29/2025 6:06 AM, Davide Perini wrote:
>> Using JDK 24.0.2 and JavaFX 24 I get a lot of warnings:
>>
>> WARNING: A terminally deprecated method in sun.misc.Unsafe has been 
>> called
>> WARNING: sun.misc.Unsafe::allocateMemory has been called by 
>> com.sun.marlin.OffHeapArray 
>> (file:/C:/Users/sblantipodi/.m2/repository/org/openjfx/javafx-graphics/24/javafx-graphics-24-win.jar)
>> WARNING: Please consider reporting this to the maintainers of class 
>> com.sun.marlin.OffHeapArray
>> WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future 
>> release
>>
>> Reporting them :)
>


From angorya at openjdk.org  Tue Jul 29 14:35:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 14:35:05 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value [v2]
In-Reply-To: <TPpwDp6sbrXDs5oSZHYFL0MElFDbOgrAkvS92ShstME=.4e9513ea-1d84-48a4-b1ef-c76f0fe92c27@github.com>
References: <zQ9ZkqhcgKv-M5ggKOWOjYlZiUVG8jWAPVSOiFch_kI=.a5543325-c16a-455e-b37f-0dbfca2b8f15@github.com>
 <TPpwDp6sbrXDs5oSZHYFL0MElFDbOgrAkvS92ShstME=.4e9513ea-1d84-48a4-b1ef-c76f0fe92c27@github.com>
Message-ID: <Ibz-plqacKJ5K_lrdFI4tovPb184VIX5oNHWibk7llY=.63b3c046-6bb7-47c0-9ea4-d0176be780f0@github.com>

On Tue, 29 Jul 2025 11:32:00 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:
> 
>   Update TreeCellSkin.java

verified the fix on macOS 15.5 M1.

you may want to remove unnecessary newline in L362.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1838#pullrequestreview-3067883646

From mfox at openjdk.org  Tue Jul 29 14:50:20 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 29 Jul 2025 14:50:20 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update the
 window size
Message-ID: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>

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.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into macmadmax
 - Re-enabled system test
 - Fixed position of maximized transparent windows
 - Merge remote-tracking branch 'upstream/master' into macmadmax
 - Correct restore/maximize notifications, minor cleanup.
 - Cleaned up events when maximizing and restoring the window

Changes: https://git.openjdk.org/jfx/pull/1860/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355990
  Stats: 67 lines in 5 files changed: 20 ins; 36 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1860.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1860/head:pull/1860

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

From angorya at openjdk.org  Tue Jul 29 14:57:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 14:57:07 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <PVhrMOMbQNvZdS8RlPT3WbXk3YhGy1nfH1PCTjcozr4=.5765c53c-38a1-4681-a0a7-f9327acdaf5f@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

> Is this unit-testable?
> Any minimal test case?

Github ate my previous response!  Restoring from memory.

The bug came out of testing JDK-8364049.  I could not create a headless unit test: it looks like the focus subsystem is involved which is not easily reproducible with a headless test.  I don't want to create a headful test for this particular scenario.

For the record, the test I tried to write:


    @Test
    public void testNPE_8364088() {
        BorderPane bp = new BorderPane();
        Button b = new Button("Create Schema Overflow");
        bp.setTop(new HBox(new ToolBar(b)));
        Stage stage = new Stage();
        stage.setScene(new Scene(bp, 600, 400));
        stage.setTitle(getClass().getSimpleName());
        stage.show();

        runLater(() -> {
            b.requestFocus();
            runLater(() -> {
                stage.setWidth(50);
                runLater(() -> {
                    stage.setWidth(40);
                    System.out.println(stage.getWidth());
                    stage.hide();
                });
            });
        });
    }
    
    private static void runLater(Runnable r) {
        AtomicInteger counter = new AtomicInteger(10);
        Platform.runLater(new Runnable() {
            @Override
            public void run() {
                if (counter.decrementAndGet() > 0) {
                    Platform.runLater(this);
                } else {
                    r.run();
                }
            }
        });
    }

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

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3132918888

From angorya at openjdk.org  Tue Jul 29 15:33:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 15:33:04 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: <TWpJVBP75dSHgFFM44KNDpwH5QHtG-tClnMDyKOUxnE=.b9fd0cfa-05f0-4506-bf73-5bacd46ea364@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

Marked as reviewed by angorya (Reviewer).

Thank you for the explanations!  The current master threw an exception navigating the menus in the monkey tester, this PR works as expected with all kinds of `Menu/MenuItem`s.

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

PR Review: https://git.openjdk.org/jfx/pull/1858#pullrequestreview-3068104836
PR Comment: https://git.openjdk.org/jfx/pull/1858#issuecomment-3133047453

From zelmidaoui at openjdk.org  Tue Jul 29 15:55:02 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 29 Jul 2025 15:55:02 GMT
Subject: RFR: 8341286: TreeView: visual artifacts when setting new root
 with null value [v3]
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: <JS-rZBKWCypwr_PJaXCKLQYvubRSIh2g60861ADDzK0=.11a4bd2c-e4e9-41fb-a9fb-1a5ae52256ea@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1838/files
  - new: https://git.openjdk.org/jfx/pull/1838/files/2d832143..95997e00

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

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

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

From angorya at openjdk.org  Tue Jul 29 15:55:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 15:55:03 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: <kKXdO32Ip-hMKF9LvJimGnU2BOtl2sDMykgi5QWJb0Q=.3fdd5f1b-3cf7-4135-92bc-18d195a498b7@github.com>

On Tue, 29 Jul 2025 15:51:50 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

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1838#pullrequestreview-3068180462

From mstrauss at openjdk.org  Tue Jul 29 17:46:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 29 Jul 2025 17:46:17 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <o0d1OuLnmq1hg9Sfoq1gpiyBe_ASumdTveX8g3YbCZA=.da71dfb1-c2d3-4b64-bf67-1ece945595a1@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

Marked as reviewed by mstrauss (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1857#pullrequestreview-3068567204

From angorya at openjdk.org  Tue Jul 29 18:36:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 18:36:05 GMT
Subject: Integrated: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <VA7QnNiRD21qjoHABIcGiHanvWNxorg_dKp-RksEcTU=.70d05fdc-10e3-4ce6-b828-4ca89ababac0@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

This pull request has now been integrated.

Changeset: 450ca6da
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/450ca6da16c5299d9792d01009a4400daa87ce6a
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8364088: ToolBarSkin: NPE in select()

Reviewed-by: kizune, mstrauss

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

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

From angorya at openjdk.org  Tue Jul 29 18:36:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 18:36:06 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <9MJwidfGjTH13VUOVRc36-czdbdzVm5ZnkzScnyGXDo=.b23ffbee-d607-43aa-bea1-b316e44eefb4@github.com>

On Fri, 25 Jul 2025 17:13:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

@mstr2 could you also take a look at this please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3133616505

From angorya at openjdk.org  Tue Jul 29 18:41:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 18:41:02 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <uw6eogkXQCfAgvHhf-vq3isphx3MOs4J87pIX5mRC6Y=.c8296c6e-7cad-41bd-9db3-3e27e674ae4b@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

@kevinrushforth I think we should backport this to 25, along with #1856 . what do you think?
is this the right command: `/ backport :jfx25` ?

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

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3133630637

From angorya at openjdk.org  Tue Jul 29 18:46:44 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 18:46:44 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v2]
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8364049.toolbar
 - snap length

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1856/files
  - new: https://git.openjdk.org/jfx/pull/1856/files/c69f29ff..aa802f4d

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

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

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

From kcr at openjdk.org  Tue Jul 29 20:16:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 20:16:06 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <1Cjl6uAsi8w-Z7UAOfsn9CP6XOQ05pstR8RRIp7qJcA=.2c06dd13-98f9-4483-93a4-99afdc3fb55b@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

How likely is this bug to occur? It's a safe enough fix that I don't object to backporting it if you think it's worth doing. As for the syntax, yes, you have it right.

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

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3133912617

From angorya at openjdk.org  Tue Jul 29 20:44:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 20:44:06 GMT
Subject: RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
References: <HeX3VQZm_EHyHd8lDpQ7nJHammg0sBIg-aKyTvsdE5Y=.b5d0f81a-3bb7-4e06-b5f3-ced09614bd35@github.com>
Message-ID: <QkPcIsZZCNwYgyZ5m5VJrj5rCNIghQKkwuanxd7s9K0=.fd78afd1-9265-42bf-bc9a-f220c9f51b5b@github.com>

On Fri, 25 Jul 2025 22:32:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar, looks like a corner case.

I just really dislike these small issues (and I too like to add random stuff to the toolbars).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1857#issuecomment-3134010011

From angorya at openjdk.org  Tue Jul 29 20:49:32 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 20:49:32 GMT
Subject: [jfx25] RFR: 8364088: ToolBarSkin: NPE in select()
Message-ID: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>

Fixed an NPE in the ToolBar.

-------------

Commit messages:
 - Backport 450ca6da16c5299d9792d01009a4400daa87ce6a

Changes: https://git.openjdk.org/jfx/pull/1861/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1861&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364088
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1861.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1861/head:pull/1861

PR: https://git.openjdk.org/jfx/pull/1861

From angorya at openjdk.org  Tue Jul 29 21:02:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 21:02:26 GMT
Subject: [jfx25] Integrated: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
References: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
Message-ID: <V-CSFz3qOviWMdNELKasnuZJeMR5i5rm9iyu2VhYSBs=.8fcafb2d-104f-429a-8e47-fd0b09241a87@github.com>

On Tue, 29 Jul 2025 20:45:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar.

This pull request has now been integrated.

Changeset: a0c0920d
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a0c0920d92eeb6608c80bf3779def90adfcca756
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8364088: ToolBarSkin: NPE in select()

Reviewed-by: kcr
Backport-of: 450ca6da16c5299d9792d01009a4400daa87ce6a

-------------

PR: https://git.openjdk.org/jfx/pull/1861

From angorya at openjdk.org  Tue Jul 29 21:02:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 29 Jul 2025 21:02:26 GMT
Subject: [jfx25] RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
References: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
Message-ID: <CQzANoX_yXhmc4bIfaPhVBbVMt64KvZBTyeCS_4e3FY=.c211b2c0-222a-4a73-bb64-552d86a0e706@github.com>

On Tue, 29 Jul 2025 20:45:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar.

thanks for a quick review!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1861#issuecomment-3134054753

From kcr at openjdk.org  Tue Jul 29 21:02:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 21:02:26 GMT
Subject: [jfx25] RFR: 8364088: ToolBarSkin: NPE in select()
In-Reply-To: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
References: <WRpajmN3G06nLDuxZTaNnxehMHrbqNBqGU_STSfysk4=.61c6bbb7-fc6e-4d10-ada7-71bef5a77322@github.com>
Message-ID: <RmBZjMx-6Xd2-lHjvxe20NH9pjVokwHh9-DZUG0bvyY=.69c95495-541f-465b-a587-d8b4117ccea0@github.com>

On Tue, 29 Jul 2025 20:45:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixed an NPE in the ToolBar.

OK for jfx25

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1861#pullrequestreview-3069203061

From almatvee at openjdk.org  Tue Jul 29 21:18:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 29 Jul 2025 21:18:14 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: <cplOAui5d2UHzok5niwtqlk2qj9YRX4g-u-CtFP_b30=.0a4217bf-e08f-4dbb-93d1-c3b7cca3b303@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.

8361648: Update Glib to 2.84.3 [v3]
- Fixed whitespace.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1862#issuecomment-3134096735

From almatvee at openjdk.org  Tue Jul 29 21:18:14 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 29 Jul 2025 21:18:14 GMT
Subject: RFR: 8361648: Update Glib to 2.84.3
Message-ID: <-NGdD-X_IMIhPVQVZrud1MSg584DQ-3DKPvKwMByJ4M=.5d56a582-a1f3-4514-8045-4406e9ac3779@github.com>

- GLib updated to 2.84.3.
- Tested on all platforms.
- No other changes are done.

-------------

Commit messages:
 - 8361648: Update Glib to 2.84.3 [v3]
 - 8361648: Update Glib to 2.84.3 [v2]
 - 8361648: Update Glib to 2.84.3

Changes: https://git.openjdk.org/jfx/pull/1862/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1862&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/jfx/pull/1862.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1862/head:pull/1862

PR: https://git.openjdk.org/jfx/pull/1862

From kcr at openjdk.org  Tue Jul 29 22:20:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 29 Jul 2025 22:20:59 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: <7qLkZqOvApdJknPslVTEDVJkCmB07DznrciSwmdiTmk=.fcb8bce7-1bcf-46c9-b0a8-8ebae8e64d5a@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.

Reviewers: @arapte @tiainen

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1862#issuecomment-3134231362

From lkostyra at openjdk.org  Wed Jul 30 07:02:05 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 30 Jul 2025 07:02:05 GMT
Subject: Integrated: 8351357: Add canary system test checking if Stage receives
 focus on show
In-Reply-To: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
References: <PpSwaupPs1pO2ubXxz8TiHob_XrM2rUiLZ--zPChWnM=.b1db480b-e968-42e1-9dc8-1b8a1f80e44b@github.com>
Message-ID: <gzzKupCrSQfGKAmiIMpx45GqQlF-N1_WifOTOZdnS5k=.3ebb31af-9d4a-47d8-93fb-120f6a5cf9d4@github.com>

On Tue, 13 May 2025 09:10:27 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Originally this issue was supposed to resolve problems with some system tests (`MenuDoubleShortcutTest`, `TextAreaBehaviorTest` and others) failing on my Windows machine. In the process of figuring this out I found out the problem is Windows `::SetForegroundWindow()` API refusing to give focus to JFX Stage upon calling `Stage.show()`.
> 
> The problem happened only when running system tests via Gradle, and with more investigation it turned out the culprit is actually running tests via a Gradle Daemon, which is the default behavior. According to [SetForegroundWindow API remarks](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow) there is a list of conditions a process must meet to be granted a privilege of receiving focus, which is supposed to prevent focus stealing. While we do meet the required conditions, we don't meet "one of" additional conditions listed in the reference:
> - Gradle daemon is a background process, so tests started by it do not meet `The calling process is the foreground process.` and `The calling process was started by the foreground process.` conditions
> - We most probably run the tests from the terminal, so `There is currently no foreground window, and thus no foreground process.` condition fails - the foreground window is the Terminal itself.
> - Each test has fresh-started JFX stage so `The calling process received the last input event.` condition cannot be met and would require either Robot workarounds or manual interaction before each test case.
> - There is no debugger involved in the process (at least most of the time) so `Either the foreground process or the calling process is being debugged.` is also not met.
> 
> As such, Windows refuses to grant JFX Stage focus, which fails some system tests relying on it.
> 
> While we cannot remedy these conditions in-code (outside of hacky solutions I found with `AttachThreadInput` API which I am not a fan of) the only solution seems to be running the tests on Windows via either `gradle --no-daemon` or by setting `org.gradle.daemon=false` property somewhere in `gradle.properties`.
> 
> In the process of debugging this problem I wrote a canary test to detect whether a Stage receives focus right after calling `show()`. I ran this test on all (accessible to me) platforms (Windows, Linux, macOS) - on both Linux and macOS the test passes regardless of whether the Gradle deamon is used or not. On my Windows machine (Win 11 24H2) it fails when testing through Gradle Daemon (am...

This pull request has now been integrated.

Changeset: 5dd5085b
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5dd5085bf20a4a000c9e0590e19535b62c32091c
Stats:     224 lines in 1 file changed: 224 ins; 0 del; 0 mod

8351357: Add canary system test checking if Stage receives focus on show

Reviewed-by: kcr, mfox

-------------

PR: https://git.openjdk.org/jfx/pull/1804

From arapte at openjdk.org  Wed Jul 30 10:00:56 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 30 Jul 2025 10:00:56 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v12]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <XJaWnwrnkIhbLD_MU1yhZuo5JB7iifv9s_dG-tpYq7U=.e131dc4a-866f-49da-a2fa-f2e7cd5dacf1@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:

 - nir: review comments
 - lukasz: addJSL-mtl-d3d12

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/1a9a0a41..bf7141a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=10-11

  Stats: 264 lines in 20 files changed: 69 ins; 77 del; 118 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  Wed Jul 30 10:04:17 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 30 Jul 2025 10:04:17 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
Message-ID: <Yn7zn6G67_qZiCPtMHBkdEparUnK5nJTEqO38xb5238=.2f9faa6e-2b15-47ef-b968-4b133e31786b@github.com>

On Tue, 22 Jul 2025 17:00:25 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 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/df483ca3...1a9a0a41

@lukostyra The addJSL is changed as you suggested.
@nlisker  Almost all the comments are addressed except a few, especially changing switch statements.

Please take a look

-------------

PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-3065899492

From arapte at openjdk.org  Wed Jul 30 10:04:18 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 30 Jul 2025 10:04:18 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <4Z8B4GLICMzbgXOUKYcoihvXsy7fCOabt2luf3fVop4=.5bdab030-e3f0-462c-93d3-13a3d6642a83@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <-1ZxF_cahMQ4vH7dyPmQCUilVw09o9oGHmJJ3lDOi-c=.13e8bd5d-d92b-4000-ae4a-256b51a85361@github.com>
 <4Z8B4GLICMzbgXOUKYcoihvXsy7fCOabt2luf3fVop4=.5bdab030-e3f0-462c-93d3-13a3d6642a83@github.com>
Message-ID: <hmhLyKokWpusJ2wH7jnpE7RcTIfteYMqaoAhxXHRW0E=.f03532e8-ea2d-43bb-85ea-2d0063686816@github.com>

On Fri, 25 Jul 2025 11:44:02 GMT, Lukasz Kostyra <lkostyra 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/df483ca3...1a9a0a41
>
> build.gradle line 2680:
> 
>> 2678:     // Prism JSL
>> 2679:     outPkg = IS_WINDOWS ? "com/sun/prism/d3d/hlsl" : (IS_MAC ? "com/sun/prism/mtl/msl" : "")
>> 2680:     addJSL(project, "Prism", outPkg, null) { sourceDir, destinationDir ->
> 
> I'm not quite sure if this is the best way to do it when counting in other platforms. While this used to work well on Windows with ES2 and D3D being the only backends, and it works well on Mac with ES2-MTL transition, it would unfortunately fall apart when mixing in D3D12.
> 
> On D3D12 branch JSLC generates two types of shaders at once - HLSL and HLSL6. With this change, on Windows both shaders would end up in `com/sun/prism/d3d/hlsl` when they should be separated. I think we should look through this and unify the way `addJSL` is called so that it functions better for multiple shader types. This would also be helpful when eventually merging direct3d12 to this code.
> 
> I think a better approach (you can source this from `direct3d12` branch [right here - added L1710 and L2808](https://github.com/openjdk/jfx-sandbox/commit/380fc8ea06a0a3187460013b254f93df4d683b32)) would be to have a generic package prefix `com/sun/prism` here and add shader-specific suffixes inside `addJSL` compile targets. Those targets would also be enabled-disabled based on current build platform (ex. HLSL/HLSL6 are both enabled by IS_WINDOWS property, whereas MSL would be enabled by IS_MAC property).
> 
> Let me know what you think of this approach and would it work with your backend.

This seems better.
Thanks for the link to changes, it works well with metal and d3d(9).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2238781284

From arapte at openjdk.org  Wed Jul 30 10:04:32 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 30 Jul 2025 10:04:32 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: <Us5jKuTu-einh5W5vg-_vJuMzDyepZorCQvI8Jalas4=.d64d9a3a-c5b6-4dcd-863b-8fb2977b0e2b@github.com>

On Fri, 25 Jul 2025 15:27:47 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/df483ca3...1a9a0a41
>
> build.gradle line 2705:
> 
>> 2703:                 exec {
>> 2704:                     commandLine("${metalCompiler}")
>> 2705:                     args += [ "-std=macos-metal2.4" ]
> 
> Should this version number be moved to the properties file with the other versions? Is it expected to be updated? Metal 4 was released recently, and Metal 3 was released a few years ago. Are we not going to end up with a version that's going to be "old" by the time it's released?

Yes, moving to build.properties seems good idea. done.
macos-metal2.4 is required to support macos 12, so changing this version should be done only in unavoidable circumstances or may be when support for macos 12 is over.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Is the copyright of 2021 needed if the file was introduced in 2025? Other files are also like that, but not all.

Yes, 2021 is needed. As the files were available in public sandbox repo since then.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 52:
> 
>> 50: import static java.util.Map.entry;
>> 51: 
>> 52: public class MSLBackend extends SLBackend {
> 
> Since this is a new class, can we have a bit of class docs to explain what it is and what it relates to? Same for the other classes where you deem it not trivial.

Yes, there are several internal classes that are missing doc. added a line for this class, but shall leave other internal classes as is, we would need a separate task to update such classes across all pipelines.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 64:
> 
>> 62: 
>> 63:     private String shaderFunctionName;
>> 64:     private String textureSamplerName;
> 
> This variable is assigned but never read (unused). Is it needed for anything?

Removed it. must be residue from a trial.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 182:
> 
>> 180:     protected String getQualifier(Qualifier q) {
>> 181:         String qual = QUAL_MAP.get(q.toString());
>> 182:         return (qual != null) ? qual : q.toString();
> 
> All these "get or else" methods can use `Map::getOrDefault`:
> 
> return QUAL_MAP.getOrDefault(q.toString(), q.toString());
> 
> And if `toString` is expensive, it can be stored in a local variable first.

Changed to :

    @Override
    protected String getQualifier(Qualifier q) {
        String qualifier = q.toString();
        return QUAL_MAP.getOrDefault(qualifier, qualifier);
    }

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 256:
> 
>> 254:         Variable var = d.getVariable();
>> 255:         Qualifier qual = var.getQualifier();
>> 256:         if (qual == Qualifier.CONST) { // example. const int i = 10;
> 
> Using a switch expression here on the enum will be cleaner. First, the `else` at the end can't be reached unless `qual == null`. If it's at all possible for it to be `null`, it should be explicitly expressed (via `case null -> ...`). Second, if other enum constants are added later (is it possible even?), we *should* get a compiler error and not go to the `else` blindly.
> 
> I would also extract the content of each branch to its own private method, especially when there're a lot of comments that could go on it:
> 
> case null -> visitVarDecl(d) // if can be null
> case CONST -> handleConst()
> case PARAM -> handleParam()

Yes, null is possible for regular file local, function local variables.
new methods seem for case block seems overkill. This class is used at build time.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 317:
> 
>> 315:         String shaderType = isPrismShader ? "PRISM" : "DECORA";
>> 316: 
>> 317:         if (fragmentShaderHeader == null) {
> 
> Looks like `fragmentShaderHeader` is only used once and then retained in memory just to check later on if it was initialized  and written. Perhaps a boolean flag would make it clearer? In that case the builder is used and discarded with the appropriately-named flag conveying a meaning better than "string builder == null", such as `wasHeaderWritten`.
> 
> I would also extract the content of the `if` to its own method, but it's just my style to break up long methods.

Yes, fragmentShaderHeader is used only once. I extracted the if block to another method `writeFragmentShaderHeader()` with using multiline string.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 359:
> 
>> 357: 
>> 358:             if (objCHeader.length() == 0) {
>> 359:                 objCHeader.append("#ifndef " + shaderType + "_SHADER_COMMON_H\n" +
> 
> Is `objHeader` supposed to have this content initialized only once? Doesn't `shaderType` change in later calls?
> It's also never cleared, is it supposed to retain all its content?

shaderType changes in following calls.
The objHeader is initialized once with the content above, and then it gets appended for every shader and written to the file after parsing every shader. It is supposed to retain all the content till all decora or prism shaders are parsed.

> modules/javafx.graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw/MSLBackend.java line 511:
> 
>> 509:         texSamplerMap = new HashMap<>();
>> 510:         helperFunctions = new ArrayList<>();
>> 511:         uniformNames = new ArrayList<>();
> 
> You should be able to initialize these at the declaration site and make them final. Here you can call `clear` to reset the content. Perhaps it's better than recreating the data structure?
> 
> Alternatively, you can encapsulate all the variables and methods that are used per-shader in a single inner class and create a new instance per shader for the duration of handling that shader. This approach provides better separation and encapsulation and tends to be less error prone.

Changed the variable to initialize with declaration and use clear().

> modules/javafx.graphics/src/main/java/com/sun/prism/GraphicsPipeline.java line 52:
> 
>> 50:          */
>> 51:         GLSL,
>> 52:         /**
> 
> An empty line between the constants can help with readability.

We tried to keep minimal changes to common files. The enum did not use new line before, so would like to avoid it.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 50:
> 
>> 48: import java.nio.ByteBuffer;
>> 49: 
>> 50: public class MTLContext extends BaseShaderContext {
> 
> Looks like all the fields here can be private. I don't see them used outside of this class.

We have similar fields declared as public in other internal classes. Even D3DContext has similar properties declared as public. It would be good to keep these similar. We can make such changes as a cleanup on a wider level.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 97:
> 
>> 95:     static {
>> 96:         final String shaderLibName = "msl/jfxshaders.metallib";
>> 97:         final Class clazz = MTLContext.class;
> 
> Raw type -> `Class<MTLContext>`

Changed.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 232:
> 
>> 230:             }
>> 231:             MTLShader.setTexture(texUnit, tex, linear, wrapMode);
>> 232:         }
> 
> Maybe this is cleaner, and the removal of the default branch is safer.
> 
>         if (tex == null) return;
>         boolean linear = tex.getLinearFiltering();
>         int wrapMode = switch (tex.getWrapMode()) {
>             case CLAMP_NOT_NEEDED -> MTL_SAMPLER_ADDR_MODE_NOP;
>             case CLAMP_TO_EDGE, CLAMP_TO_EDGE_SIMULATED, CLAMP_TO_ZERO_SIMULATED -> MTL_SAMPLER_ADDR_MODE_CLAMP_TO_EDGE;
>             case CLAMP_TO_ZERO -> MTL_SAMPLER_ADDR_MODE_CLAMP_TO_ZERO;
>             case REPEAT, REPEAT_SIMULATED -> MTL_SAMPLER_ADDR_MODE_REPEAT;
>         };
>         MTLShader.setTexture(texUnit, tex, linear, wrapMode);
> 
> Can the texture legally be `null` and this method still called with it? Looks odd to call `updateTexture` with a `null` texture.

In case of es2, d3d, calling with null texture is valid: Calling updateTexture with null texture and with a valid texUnit means to reset that texUnit texture. However it is not required to in case of metal hence else block is no-op

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 247:
> 
>> 245:         } else {
>> 246:             scratchTx = scratchTx.mul(xform).mul(perspectiveTransform);
>> 247:         }
> 
> Looks like `mul` already does the short-circuiting identity check, so no need for the if-else:
> `scratchTx.set(projViewTx).mul(xform).mul(getPerspectiveTransformNoClone());`

The current code seems easy to read, and offers understanding what happens if identity. If changed it would get lost

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 258:
> 
>> 256:     protected void updateWorldTransform(BaseTransform xform) {
>> 257:         worldTx.setIdentity();
>> 258:         if ((xform != null) && (!xform.isIdentity())) {
> 
> Redundant identity check.

The function is exactly similar to that of ES2Context. It would be good to keep code similar for ease of debugging in case of issues.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLContext.java line 485:
> 
>> 483: 
>> 484:     private void updateRawMatrix(GeneralTransform3D src) {
>> 485:         rawMatrix[0]  = (float)src.get(0); // Scale X
> 
> Is there a meaningful loss of precision here?

In all pipelines, the native side requires a float value. So, this is just more of the same and safe.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLGraphics.java line 32:
> 
>> 30: import com.sun.prism.paint.Color;
>> 31: 
>> 32: public class MTLGraphics extends BaseShaderGraphics {
> 
> Doesn't look like the class needs to be public. Same for all other classes in this package. I suggest minimizing visibility to avoid leaking the class outside of its scope and also for better readability context.

Changed this and all other applicable classes.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 32:
> 
>> 30: 
>> 31: class MTLMesh extends BaseMesh {
>> 32:     static int count = 0;
> 
> Do we use a new line after a class declaration?

changed.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLMesh.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     static class MTLMeshDisposerRecord implements Disposer.Record {
> 
> Can be private.

changed this and other internal classes.

> 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.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPhongMaterial.java line 37:
> 
>> 35: import com.sun.prism.impl.Disposer;
>> 36: 
>> 37: class MTLPhongMaterial extends BasePhongMaterial implements PhongMaterial {
> 
> The superclass already implements the interface, so it's redundant here.

yes, corrected the signature

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLPipeline.java line 139:
> 
>> 137:             default:
>> 138:                 return false;
>> 139:         }
> 
> Can be like above.
> 
> Also, can Metal really support SM3? Isn't it a D3D-only model?

Yes, SM3 is specific to D3D, but it is used by ES2 as well.
There is no SM3 like concept for es2 or mtl. So same SM3 is reused.

> 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

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLRenderTarget.java line 1:
> 
>> 1: /*
> 
> Why is this interface needed if it's implemented only in 1 class and the return value from the method is always 0?

The interface is used in D3D and ES2 but not in case of Metal. Would like to keep it for symmetry.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 44:
> 
>> 42: import com.sun.prism.impl.TextureResourcePool;
>> 43: import com.sun.prism.impl.ps.BaseShaderFactory;
>> 44: import com.sun.prism.mtl.MTLContext;
> 
> Unused import

yes, un-required.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 170:
> 
>> 168:             allocw = w;
>> 169:             alloch = h;
>> 170:         }
> 
> If you prefer:
> 
>         int allocw = PrismSettings.forcePow2 ? nextPowerOfTwo(w, Integer.MAX_VALUE) : w;
>         int alloch = PrismSettings.forcePow2 ? nextPowerOfTwo(h, Integer.MAX_VALUE) : h;

if-else seems good for multiple statements.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 176:
> 
>> 174:         int bpp = formatHint.getBytesPerPixelUnit();
>> 175:         if (allocw >= (Integer.MAX_VALUE / alloch / bpp)) {
>> 176:             throw new RuntimeException("Illegal texture dimensions (" + allocw + "x" + alloch + ")");
> 
> Is a `RuntimeException` necessary here? Can we not recover?

Yes, the size is not supported and same exception is thrown from other pipelines.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 64:
> 
>> 62:     public static Shader createShader(MTLContext ctx, String fragFuncName, Map<String, Integer> samplers,
>> 63:                                       Map<String, Integer> params, int maxTexCoordIndex,
>> 64:                                       boolean isPixcoordUsed, boolean isPerVertexColorUsed) {
> 
> All 4 are unused.

Yes, but we have similar method signature in D3D as well. Let's keep these for maintaining similarity.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 67:
> 
>> 65:         if (shaderMap.containsKey(fragFuncName)) {
>> 66:             return shaderMap.get(fragFuncName);
>> 67:         } else {
> 
> `else` is not required because `if` returns. Up to you.
> 
> Can also use `Map::getOrDefault` if you want to extract the shader creation into a method.

Shall keep if-else.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLShader.java line 79:
> 
>> 77:         } else {
>> 78:             return new MTLShader(ctx, fragFuncName);
>> 79:         }
> 
> Can use `Map::getOrDefault`.

if else block seems easy on eyes.

> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLVramPool.java line 54:
> 
>> 52:     @Override
>> 53:     public long estimateRTTextureSize(int width, int height, boolean hasDepth) {
>> 54:         // REMIND: need to deal with size of depth buffer, etc.
> 
> Is this comment supposed to go in?

Yes, It is carried from other pipeline.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2238918320
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2238963008
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239028225
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239034503
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239521920
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241975027
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239576859
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239836593
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239852923
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239860795
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2239961492
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240049769
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240067008
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240074327
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240091921
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240110474
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240267443
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240270064
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240296571
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240386496
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240402281
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240459275
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2240619553
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2242141227
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241505629
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241526419
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241528735
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241593787
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241603494
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241611456
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2241935257

From arapte at openjdk.org  Wed Jul 30 10:12:12 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 30 Jul 2025 10:12:12 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: <wXenY9dDj2sWaJF4DsFadI12pVm1hPoScGzgSHzXdCU=.444df669-b867-4134-8db0-4673198e23c1@github.com>

On Fri, 25 Jul 2025 18:49:12 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/17925b6e...1a9a0a41
>
> modules/javafx.graphics/src/main/java/com/sun/prism/mtl/MTLResourceFactory.java line 103:
> 
>> 101:             return createShader(pixelShaderName, samplers, params, maxTexCoordIndex,
>> 102:                                 isPixcoordUsed, isPerVertexColorUsed);
>> 103:         } catch (Exception e) {
> 
> `e` is unused and can be `_` if this is correct (e.g., no `e.printStackTrace()`). Same in other places.

Added `e.printStackTrace()`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2242158909

From kcr at openjdk.org  Wed Jul 30 15:06:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 30 Jul 2025 15:06:01 GMT
Subject: RFR: 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: <bZ58NMh2pG_9YXPCGb7BqrA4ln6li4Nm_tt_GPIh1As=.4fb2edb0-69e7-48da-9ca6-1570b2ea5701@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.

@beldenfox It might be better to close [JDK-8179980](https://bugs.openjdk.org/browse/JDK-8179980) as a duplicate of this bug (JDK-8355990) rather than add it as a separate issue, since it is a natural step when fixing the underlying product bug to re-enable any skipped tests.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1860#issuecomment-3136751033

From mstrauss at openjdk.org  Wed Jul 30 16:37:08 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 30 Jul 2025 16:37:08 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v2]
In-Reply-To: <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>
Message-ID: <y6CpiQ2Q_7mrefwKqsMBnLAxtE7YAOOKD1uKtauouaQ=.c061f708-f1cf-43be-b228-36a023130585@github.com>

On Tue, 29 Jul 2025 18:46:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8364049.toolbar
>  - snap length

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 692:

> 690:      */
> 691:     private int getOverflowNodeIndex(double length) {
> 692:         if (getSkinnable().getOrientation() == Orientation.VERTICAL) {

Snapping the input argument of a method like `getOverflowNodeIndex` doesn't seem right to me, because the length is computed incorrectly in the first place. Have you considered fixing the snapping in `getToolbarLength`? This also solves the problem.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1856#discussion_r2243271568

From angorya at openjdk.org  Wed Jul 30 17:46:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 17:46:05 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v2]
In-Reply-To: <y6CpiQ2Q_7mrefwKqsMBnLAxtE7YAOOKD1uKtauouaQ=.c061f708-f1cf-43be-b228-36a023130585@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>
 <y6CpiQ2Q_7mrefwKqsMBnLAxtE7YAOOKD1uKtauouaQ=.c061f708-f1cf-43be-b228-36a023130585@github.com>
Message-ID: <6qdCnfm4QpVQB3ktvLIku13l0yFK5YJXuDtUCH-CpwE=.81d3a4c4-1850-4747-a14c-08c5ea22018e@github.com>

On Wed, 30 Jul 2025 16:34:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8364049.toolbar
>>  - snap length
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 692:
> 
>> 690:      */
>> 691:     private int getOverflowNodeIndex(double length) {
>> 692:         if (getSkinnable().getOrientation() == Orientation.VERTICAL) {
> 
> Snapping the input argument of a method like `getOverflowNodeIndex` doesn't seem right to me, because the length is computed incorrectly in the first place. Have you considered fixing the snapping in `getToolbarLength`? This also solves the problem.

Yes, but I wanted to do a very localized fix, to be included in jfx25.  There are many places where we should be more careful with snapping mentioned in description, and I suspect even more elsewhere.

I am still not sure what would be the best approach to address them all.  We could probably create an umbrella task and fix individual controls and containers (maybe even start with containers, in continuation of John's work with HBox and VBox).

I think this PR is still good, because a) it provides a fix for the specific issue and b) minimizes regression, but I agree with you that a comprehensive fix is needed.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1856#discussion_r2243445856

From mstrauss at openjdk.org  Wed Jul 30 18:09:01 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 30 Jul 2025 18:09:01 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v2]
In-Reply-To: <6qdCnfm4QpVQB3ktvLIku13l0yFK5YJXuDtUCH-CpwE=.81d3a4c4-1850-4747-a14c-08c5ea22018e@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>
 <y6CpiQ2Q_7mrefwKqsMBnLAxtE7YAOOKD1uKtauouaQ=.c061f708-f1cf-43be-b228-36a023130585@github.com>
 <6qdCnfm4QpVQB3ktvLIku13l0yFK5YJXuDtUCH-CpwE=.81d3a4c4-1850-4747-a14c-08c5ea22018e@github.com>
Message-ID: <KELjA2Nlw6p1nxBGndDavMMiCeeDuO6SWYQCzlSR04A=.c1bcba2c-64be-416d-a184-e866a2e59f0f@github.com>

On Wed, 30 Jul 2025 17:42:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 692:
>> 
>>> 690:      */
>>> 691:     private int getOverflowNodeIndex(double length) {
>>> 692:         if (getSkinnable().getOrientation() == Orientation.VERTICAL) {
>> 
>> Snapping the input argument of a method like `getOverflowNodeIndex` doesn't seem right to me, because the length is computed incorrectly in the first place. Have you considered fixing the snapping in `getToolbarLength`? This also solves the problem.
>
> Yes, but I wanted to do a very localized fix, to be included in jfx25.  There are many places where we should be more careful with snapping mentioned in description, and I suspect even more elsewhere.
> 
> I am still not sure what would be the best approach to address them all.  We could probably create an umbrella task and fix individual controls and containers (maybe even start with containers, in continuation of John's work with HBox and VBox).
> 
> I think this PR is still good, because a) it provides a fix for the specific issue and b) minimizes regression, but I agree with you that a comprehensive fix is needed.
> 
> What do you think?

I understand that you want this to be a localized fix. I'm just proposing to change `getToolbarLength` instead, which is even less changed code than your change in `getOverflowNodeIndex`, and seems to be addressing the source of the incorrect length instead.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1856#discussion_r2243493210

From angorya at openjdk.org  Wed Jul 30 18:52:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 18:52:20 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v3]
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  get toolbar length

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1856/files
  - new: https://git.openjdk.org/jfx/pull/1856/files/aa802f4d..32171e47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1856.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1856/head:pull/1856

PR: https://git.openjdk.org/jfx/pull/1856

From angorya at openjdk.org  Wed Jul 30 18:52:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 18:52:20 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v2]
In-Reply-To: <KELjA2Nlw6p1nxBGndDavMMiCeeDuO6SWYQCzlSR04A=.c1bcba2c-64be-416d-a184-e866a2e59f0f@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <cnmo1qKw4hWVpz4Hfyv96k5ESrt9sx5nzWRNXRYgxT8=.edf93ef6-1418-433c-bb3b-2940ad0736f8@github.com>
 <y6CpiQ2Q_7mrefwKqsMBnLAxtE7YAOOKD1uKtauouaQ=.c061f708-f1cf-43be-b228-36a023130585@github.com>
 <6qdCnfm4QpVQB3ktvLIku13l0yFK5YJXuDtUCH-CpwE=.81d3a4c4-1850-4747-a14c-08c5ea22018e@github.com>
 <KELjA2Nlw6p1nxBGndDavMMiCeeDuO6SWYQCzlSR04A=.c1bcba2c-64be-416d-a184-e866a2e59f0f@github.com>
Message-ID: <M0i5Xcg_HxpeOlm4Z6ZZWX5ygzDasYAsljRaYC9Nx8U=.f59bb4f6-4174-45c2-883c-e94923949c32@github.com>

On Wed, 30 Jul 2025 18:06:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Yes, but I wanted to do a very localized fix, to be included in jfx25.  There are many places where we should be more careful with snapping mentioned in description, and I suspect even more elsewhere.
>> 
>> I am still not sure what would be the best approach to address them all.  We could probably create an umbrella task and fix individual controls and containers (maybe even start with containers, in continuation of John's work with HBox and VBox).
>> 
>> I think this PR is still good, because a) it provides a fix for the specific issue and b) minimizes regression, but I agree with you that a comprehensive fix is needed.
>> 
>> What do you think?
>
> I understand that you want this to be a localized fix. I'm just proposing to change `getToolbarLength` instead, which is even less changed code than your change in `getOverflowNodeIndex`, and seems to be addressing the source of the incorrect length instead.

Upon closer inspection, your suggestion is better: even though the change would impact more code paths including the layout, the actual value produced gets fed into the same `getOverflowNodeIndex()` function.

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1856#discussion_r2243592592

From angorya at openjdk.org  Wed Jul 30 19:16:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 19:16:09 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v12]
In-Reply-To: <XJaWnwrnkIhbLD_MU1yhZuo5JB7iifv9s_dG-tpYq7U=.e131dc4a-866f-49da-a2fa-f2e7cd5dacf1@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <XJaWnwrnkIhbLD_MU1yhZuo5JB7iifv9s_dG-tpYq7U=.e131dc4a-866f-49da-a2fa-f2e7cd5dacf1@github.com>
Message-ID: <Zm7QXLSw7FgPyY33o4pZbsqatpbFWJjKEJCYlzKPOzk=.d7980314-cebd-450c-a394-a69329caa892@github.com>

On Wed, 30 Jul 2025 10:00:56 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:
> 
>  - nir: review comments
>  - lukasz: addJSL-mtl-d3d12

You may want to use some other mechanism to mark the comments you've addressed (rather than resolving the conversation).  

I began to use the upvote emoji for that purpose.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3137534312

From angorya at openjdk.org  Wed Jul 30 19:16:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 19:16:10 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <yiuKrNJdaiuQnttLjIgL2ozohkEuiOoIW8-h2Fv-XJw=.f384216f-e51f-43bb-9bd7-ac6ac2d0c92b@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>
Message-ID: <4QcTf_Qd_f4suDyxtg65qg0c10IUbH8aigNo55SMpzw=.29dae76a-21eb-4db0-8c07-ead9c4fa7c21@github.com>

On Fri, 25 Jul 2025 22:09:41 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> all right, so we probably want to leave the project config as is, and this manual change is a one-off.  Do you mind listing the changes here for future reference?
>
> I just looked at which .java files are not on the classpath and pulled those source folders in:
> <img width="227" height="234" alt="image" src="https://github.com/user-attachments/assets/a81ef455-cc97-4b75-be96-cbd3de5bb266" />

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?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2243634990

From mstrauss at openjdk.org  Wed Jul 30 19:22:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 30 Jul 2025 19:22:02 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v3]
In-Reply-To: <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
Message-ID: <cWa3floNzAJOinrpO8QqnjNUCyVZH2-Zvfq6MBtYUdY=.3084f087-3bbf-43b4-8922-f0cbcaa714ba@github.com>

On Wed, 30 Jul 2025 18:52:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get toolbar length

I think it should be possible to create a unit test here. What should be asserted is that the overflow menu doesn't depend on various scale factors.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3137550938

From angorya at openjdk.org  Wed Jul 30 21:16:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 21:16:03 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v3]
In-Reply-To: <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
Message-ID: <XEkRTsicTKQWg8gaabTvzLFIYsKXq_REIFAeOwWlHH8=.b3f0d810-5c60-442f-9f65-cb261f9edafd@github.com>

On Wed, 30 Jul 2025 18:52:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get toolbar length

I can't get it to fail with a unit test, and I don't want a headful test here.

Here is a test which passes in master though it should fail (a part of ToolbarTest):


    @Test
    public void noOverflowAtScales() {
        // typical windows scales
        double[] scales = {
            1.0,
            1.25,
            1.5,
            1.75,
            2.0,
            2.25
        };

        Button b = new Button("Create Schema");
        b.setFont(Font.font("System", 13));
        toolBar.getItems().add(b);

        BorderPane bp = new BorderPane();
        bp.setTop(new HBox(toolBar));

        stage = new Stage();
        stage.setScene(new Scene(bp, 600, 600));
        stage.show();
        tk.firePulse();

        toolBar.setOrientation(Orientation.HORIZONTAL);
        tk.firePulse();
        for (double scale : scales) {
            toolBar.setScaleX(scale);
            toolBar.setScaleY(scale);
            
            double w = bp.prefWidth(-1);
            bp.resize(w, 100);
            
            tk.firePulse();
            tk.firePulse();
            assertOverflowNotShown();
            System.out.println(toolBar.getScaleX());
        }

        toolBar.setOrientation(Orientation.VERTICAL);
        tk.firePulse();
        for (double scale : scales) {
            toolBar.setScaleX(scale);
            toolBar.setScaleY(scale);
            tk.firePulse();
            assertOverflowNotShown();
        }
    }

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3137832092

From angorya at openjdk.org  Wed Jul 30 21:41:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 30 Jul 2025 21:41:59 GMT
Subject: RFR: 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: <m7OY4-NId8uGJFOmxbMKZzVboFMxUV_kAc4LCFyvzro=.17e507a8-c54a-4a75-b310-122894bf24dc@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.

modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1047:

> 1045:         int eventType = com_sun_glass_events_WindowEvent_RESTORE;
> 1046: 
> 1047:         if ((maximize == JNI_TRUE) && (isZoomed == JNI_FALSE)) {

changing this code to K&R style messes up the diff alignment...  could we retain the original style?

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()` ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2243908044
PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2243913600

From andy.goryachev at oracle.com  Wed Jul 30 22:00:05 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Jul 2025 22:00:05 +0000
Subject: RFR: 8343956: Focus delegation API [v3]
In-Reply-To: <MDPBYj5kDYqu8d7g23inVVx8a50D8k-sgbydk-YZ3YY=.50bcab5d-2687-4477-8124-1105bf105f3c@github.com>
References: <lhli744pFE2g6mxtL2KDQVvgJN-D4fhp655bLt_ssfw=.073da563-b29e-4081-a25c-ee10d5622f7a@github.com>
 <APvnZbdYKf76szcxnog4E8d-Ktde-kvUm1T7jJJJzNM=.d60b1919-cbdc-4a78-a201-b754f6d95cee@github.com>
 <MDPBYj5kDYqu8d7g23inVVx8a50D8k-sgbydk-YZ3YY=.50bcab5d-2687-4477-8124-1105bf105f3c@github.com>
Message-ID: <CY8PR10MB7265F4F2C8D2E41FD47FE14FE524A@CY8PR10MB7265.namprd10.prod.outlook.com>

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.

What do you think?

-andy


References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md

[1] https://github.com/openjdk/jfx/pull/1555



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <mstrauss at openjdk.org>
Date: Wednesday, July 16, 2025 at 23:33
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
On Mon, 14 Jul 2025 18:36:48 GMT, Martin Fox <mfox at openjdk.org> wrote:

> In this PR setting hoistFocus on a control only updates the flag in the control itself. What if the control?s skin introduces sub-nodes? I would assume that setting hoistFocus on a control would automatically set that flag on the control?s entire skin. Is that correct? If so what are the mechanics of making that happen?

The `hoistFocus` flag only applies to the node on which it is set, and not to its descendants. Consider a control that uses a sub-control in its skin. If the sub-control also delegates focus to one of its own descendants, then those descendants individually get to decide whether to hoist focus to the sub-control; and if so, the sub-control will further hoist focus to the outer control.

Automatically setting this flag precludes the option to have sub-nodes that _don't_ hoist focus. Consider a Button: it has an optional sub-node (`graphic`) that is independently focusable and doesn't hoist focus. A custom button could conceivably have both: a delegate (maybe a text field), as well as an independently focusable sub-node.

> It seems hoistFocus is serving two roles. One is an optimization so that requestFocus knows whether it should walk the scene graph looking for a focus-scope node. For that use the flag should be propagated through descendants in the graph. But it?s also being proposed as a hoisting barrier e.g. when it?s _not_ set it prevents focus from hoisting upward even if there's a focus-scope node higher up in the graph. But a barrier applies just to a single node and should not be propagated. So I?m having a difficult time figuring out when and how this flag should be propagated through the tree. But I?m no expert on skins so maybe I?m assuming this is more complicated than it actually is.

`hoistFocus` is not an optimization, it's semantically relevant in the way I described.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2212398078
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250730/f6a82bab/attachment.htm>

From andy.goryachev at oracle.com  Wed Jul 30 23:02:03 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 30 Jul 2025 23:02:03 +0000
Subject: JavaFX TextInputControl private access yet supposed to be
 overrided problem
In-Reply-To: <PAXP251MB06713AADDBF3395A8206AA668859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>
References: <PAXP251MB06713AADDBF3395A8206AA668859A@PAXP251MB0671.EURP251.PROD.OUTLOOK.COM>
Message-ID: <CY8PR10MB7265F8A8239399437453A84CE524A@CY8PR10MB7265.namprd10.prod.outlook.com>

Dear Tom:

Anything not public or protected is considered an implementation detail, inaccessible to the application by design.  There are many reasons for hiding the implementation detail, for example, any changes or bug fixes that do not change the public APIs can be done without breaking the existing applications.

The important question is - what is the exact functionality you are looking for?  What is your use case?  If there is something that can't be done with the use of public APIs, we might consider adding new APIs.  See, for instance, https://bugs.openjdk.org/browse/JDK-8300569

And yes, TextInputControlFromatterAccessor is a typo.  Good news: it's beyond the event horizon formed by the public APIs, and thus has no effect on the outside world.  You are absolutely right, we should rename it.

Thanks!
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of tom L <tom_L64 at hotmail.com>
Date: Friday, July 25, 2025 at 11:11
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: JavaFX TextInputControl private access yet supposed to be overrided problem
Hello.
I have this problem where a lot of methods and utility in TextInputControl have package private access while at the same time are expected to be used/overriden by children.
For example,
```
    String filterInput(String text) {
        // This method should be overridden by child classes.
        // It is overridden in TextField and TextArea as needed.
        return text;
    }
```
This method is clearly supposed to be overriden, and I am making a hex editor, requiring me to create my own text field, but I can't override it.
It is the same for other methods, also including utility methods, like for example, with the same name :
```
    static String filterInput(String txt, boolean stripNewlines, boolean stripTabs)
```
In order to do what I want, I am no choice but to copy paste half the code of this class, since even if I override the only method that uses filterInput, public void replaceText, there are a lot of package private stuff inside (mainly getFormatterAccessor), so I am ended up with trying to copy paste the whole class.

On another note, since I am talking about formatter accessor, this inner class in TextInputControl has a typos in it: TextInputControlFromatterAccessor.

Is it possible to fix this?
Thank you in advance.

Best regards,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250730/7816353d/attachment-0001.htm>

From mfox at openjdk.org  Wed Jul 30 23:15:05 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 30 Jul 2025 23:15:05 GMT
Subject: RFR: 8354943: [Linux] Simplify and update glass gtk backend:
 window sizing, positioning, and state management issues [v50]
In-Reply-To: <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
References: <z8t13n3erJ0tOXgbJjrdOimkOJH5UZ8hqaKrJ4WUIXU=.fd0156a8-03a5-4962-8ef5-90fe2411299a@github.com>
 <OSTMJz87V44oFQZmmN8n1Q2IITwA4WtJhdB9I5V-n3U=.f9c5168b-634a-4497-a692-e8bf2f3213c6@github.com>
Message-ID: <se8YL2ra15Jb_Enc4d-NpFsZfb6ZX8IEQ-FO3LAOiTc=.80e317f0-d531-4a89-8797-b6c87158ae14@github.com>

On Sun, 27 Jul 2025 13:44:56 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 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

I ran all the new tests on Windows 11 and wrote up some notes. I still need to track down some failures in StageAttributesTest.testIconifiedStage and also in StageOwnershipTest related to fullscreen windows.

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.

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).

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.

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.

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.

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.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1789#pullrequestreview-3073480556
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2243963289
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2243970112
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2244003104
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2244016882
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2243985162
PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2243987440

From mstrauss at openjdk.org  Thu Jul 31 01:03:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 31 Jul 2025 01:03:00 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v3]
In-Reply-To: <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
Message-ID: <zFUVZ5TMMvyLcu2GYQQB89RSROCydPpvJJqCdQ4URs8=.052fe19c-b5bd-47ac-bd1f-b7e88bd9653d@github.com>

On Wed, 30 Jul 2025 18:52:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get toolbar length

Here's a test that fails without, and passes with the fix:


    @Test
    public void overflowMenuNotShowingWithDifferentRenderScales() {
        double[] renderScales = {
            1.0,
            1.25,
            1.5,
            1.75,
            2.0,
            2.25
        };

        var rect = new Rectangle(100, 100);
        var toolBar = new ToolBar(rect);
        toolBar.setSkin(new ToolBarSkin(toolBar));

        for (var orientation : Orientation.values()) {
            toolBar.setOrientation(orientation);

            for (double scale : renderScales) {
                Stage stage = new Stage();
                stage.renderScaleXProperty().bind(DoubleConstant.valueOf(scale));
                stage.renderScaleYProperty().bind(DoubleConstant.valueOf(scale));
                stage.setScene(new Scene(new HBox(toolBar), 600, 600));
                stage.show();
                assertOverflowNotShown(toolBar);
                stage.close();
            }
        }
    }

    private void assertOverflowNotShown(ToolBar toolBar) {
        Pane overflowButton = (Pane)toolBar.queryAccessibleAttribute(AccessibleAttribute.OVERFLOW_BUTTON);
        assertNotNull(overflowButton);
        assertFalse(overflowButton.isVisible());
    }


I suggest to place this test in `ToolBarSkinTest` (not in `ToolBarTest`), because it tests the implementation of the skin and not the implementation of the control.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3138252523

From mstrauss at openjdk.org  Thu Jul 31 01:23:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 31 Jul 2025 01:23:07 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: <FGxyepzaU9Hyj6Hv6w23QPGqw6y5ahfRGTbpK75dFmw=.e513f335-212d-49b4-9983-8cf06d0f0583@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):_
> 
> 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

From jhendrikx at openjdk.org  Thu Jul 31 01:54:04 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 31 Jul 2025 01:54:04 GMT
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: <izqCGQ7v5Jgy2KEcZJtvX9oXFKvMnHZ2lFBkoh_7WE8=.4a094838-3efc-45c8-ac9e-8e9b8237c3fa@github.com>

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

From arapte at openjdk.org  Thu Jul 31 10:16:50 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 31 Jul 2025 10:16:50 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v13]
In-Reply-To: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
Message-ID: <wT39QfwE1XmaNCayNuI-_1aAiBVZ5RGKJ12xI601vJQ=.8bf3ecf6-b6dc-4db2-8981-75b444ce4f98@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 followup

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1824/files
  - new: https://git.openjdk.org/jfx/pull/1824/files/bf7141a7..db244a02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1824&range=11-12

  Stats: 113 lines in 8 files changed: 9 ins; 42 del; 62 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 mfox at openjdk.org  Thu Jul 31 15:05:20 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 31 Jul 2025 15:05:20 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size [v2]
In-Reply-To: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
Message-ID: <jMoMh_IM3I9XsY3NSj71qlR4nBb0_W3rJvdSjGDzIbY=.5fc2629e-2e7b-4cc2-a2d9-ea528541533c@github.com>

> 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)

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1860/files
  - new: https://git.openjdk.org/jfx/pull/1860/files/14d2aa65..f05649bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1860&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1860&range=00-01

  Stats: 17 lines in 2 files changed: 8 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1860.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1860/head:pull/1860

PR: https://git.openjdk.org/jfx/pull/1860

From angorya at openjdk.org  Thu Jul 31 16:02:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 16:02:05 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v4]
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <BzZcsZtfXmwMk17MGbSJQrHsz2o57xBHjRjXCtn-5ok=.223cb829-f0e5-4502-ae67-62fe35302192@github.com>

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1856/files
  - new: https://git.openjdk.org/jfx/pull/1856/files/32171e47..f4b19191

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=02-03

  Stats: 56 lines in 1 file changed: 51 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1856.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1856/head:pull/1856

PR: https://git.openjdk.org/jfx/pull/1856

From angorya at openjdk.org  Thu Jul 31 16:02:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 16:02:06 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v3]
In-Reply-To: <zFUVZ5TMMvyLcu2GYQQB89RSROCydPpvJJqCdQ4URs8=.052fe19c-b5bd-47ac-bd1f-b7e88bd9653d@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <i8giljgjADrWtEsGva_sNsk_RKHznZY2v3w1ISW1mZQ=.7c8793ec-cad0-4053-91ec-c375c4ae7976@github.com>
 <zFUVZ5TMMvyLcu2GYQQB89RSROCydPpvJJqCdQ4URs8=.052fe19c-b5bd-47ac-bd1f-b7e88bd9653d@github.com>
Message-ID: <9hjsR3yXAs8Th_Keh1Hl8bWvx_iAvyVt-NVl3T31sqU=.a8f7a5c8-0024-4bc6-bcf8-61088afd1555@github.com>

On Thu, 31 Jul 2025 01:00:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Here's a test

Many thanks!  The key difference seems to be the binding of the scale properties.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3140501179

From mstrauss at openjdk.org  Thu Jul 31 17:14:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 31 Jul 2025 17:14:00 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v4]
In-Reply-To: <BzZcsZtfXmwMk17MGbSJQrHsz2o57xBHjRjXCtn-5ok=.223cb829-f0e5-4502-ae67-62fe35302192@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <BzZcsZtfXmwMk17MGbSJQrHsz2o57xBHjRjXCtn-5ok=.223cb829-f0e5-4502-ae67-62fe35302192@github.com>
Message-ID: <k4du5TyiE-v3WJR3xkvVXdyNUEyrL24BDtEIwvhyvHI=.343472e6-3ddc-4ae0-9159-63483053f3a3@github.com>

On Thu, 31 Jul 2025 16:02:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1856#pullrequestreview-3076272381

From angorya at openjdk.org  Thu Jul 31 17:39:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 17:39:01 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
In-Reply-To: <vRcXufP_KXcXJH-8y0YgaJflTi7u_ACW1X6JscinZXM=.a97c24d0-2634-4b91-b00b-8c822877bd1a@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <vRcXufP_KXcXJH-8y0YgaJflTi7u_ACW1X6JscinZXM=.a97c24d0-2634-4b91-b00b-8c822877bd1a@github.com>
Message-ID: <CaQqqFYyZ4AyIc5bU-jZkNd0InoPvmGQ5iad4RrPq5k=.cc1efcb2-fa74-4802-b2bf-e24f6d39234b@github.com>

On Mon, 28 Jul 2025 13:10:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> @arapte Can you review this?

@kevinrushforth please take a look

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1856#issuecomment-3140819996

From kcr at openjdk.org  Thu Jul 31 19:07:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 31 Jul 2025 19:07:02 GMT
Subject: RFR: 8364049: ToolBar shows overflow menu with fractional scale
 [v4]
In-Reply-To: <BzZcsZtfXmwMk17MGbSJQrHsz2o57xBHjRjXCtn-5ok=.223cb829-f0e5-4502-ae67-62fe35302192@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
 <BzZcsZtfXmwMk17MGbSJQrHsz2o57xBHjRjXCtn-5ok=.223cb829-f0e5-4502-ae67-62fe35302192@github.com>
Message-ID: <PWQY_4YkD-8gp_uLnBg1FMrIHTiIOno-IHRjNtTLU9Q=.8bb49c0d-c761-4f28-8619-f9b8e219f0a9@github.com>

On Thu, 31 Jul 2025 16:02:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>> 
>> ---
>> 
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>> 
>> 
>>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>>             for (Node node : toolbar.getItems()) {
>>                 if (!node.isManaged()) continue;
>>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>>             }
>>             prefWidth -= getSpacing();
>>         } else {
>> 
>> 
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>> 
>> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
>> 
>> 
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>> 
>> 
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>> 
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>> 
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test

Looks good. I ran both the test case attached to the bug report and the new unit test. As expected they fail without the fix and pass with the fix.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1856#pullrequestreview-3076597829

From angorya at openjdk.org  Thu Jul 31 19:25:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 19:25:01 GMT
Subject: Integrated: 8364049: ToolBar shows overflow menu with fractional scale
In-Reply-To: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
References: <w3PTjPAtdPueE4ONLxhcDbbL8qhV2iMPE9d0p35kR5s=.7d19cd89-c164-4d45-919c-ad3050077843@github.com>
Message-ID: <glBhrtIpjvCk7P2Lgmp5cBht0-8urXKifCu_tS4CUPc=.d6f8775e-4db3-4828-a7da-ea3407007383@github.com>

On Fri, 25 Jul 2025 17:13:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values.  The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
> 
> ---
> 
> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere.  Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
> 
> 
>         if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>             for (Node node : toolbar.getItems()) {
>                 if (!node.isManaged()) continue;
>                 prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>             }
>             prefWidth -= getSpacing();
>         } else {
> 
> 
> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value.  In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
> 
> Another, related, topic is how to properly snap the values in the computation.  I would say ideally it should be done like this:
> 
> 
> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
> 
> 
> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
> 
> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
> 
> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.

This pull request has now been integrated.

Changeset: 4e334cb1
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4e334cb1ebbb370086d0a58bbe1d9a30d6665066
Stats:     60 lines in 2 files changed: 51 ins; 3 del; 6 mod

8364049: ToolBar shows overflow menu with fractional scale

Reviewed-by: mstrauss, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1856

From angorya at openjdk.org  Thu Jul 31 19:35:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 19:35:47 GMT
Subject: [jfx25] RFR: 8364049: ToolBar shows overflow menu with fractional
 scale
Message-ID: <2HUvBMP5STZWLZJ0Jbq2CN6xe9cBuLNCeViO168cmUU=.7eef2bbc-fab6-494c-bfef-915f4c52fe10@github.com>

A clean backport of #1856 .

This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values. The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.

-------------

Commit messages:
 - Backport 4e334cb1ebbb370086d0a58bbe1d9a30d6665066

Changes: https://git.openjdk.org/jfx/pull/1863/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364049
  Stats: 60 lines in 2 files changed: 51 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1863.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1863/head:pull/1863

PR: https://git.openjdk.org/jfx/pull/1863

From kcr at openjdk.org  Thu Jul 31 20:59:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 31 Jul 2025 20:59:05 GMT
Subject: [jfx25] RFR: 8364049: ToolBar shows overflow menu with fractional
 scale
In-Reply-To: <2HUvBMP5STZWLZJ0Jbq2CN6xe9cBuLNCeViO168cmUU=.7eef2bbc-fab6-494c-bfef-915f4c52fe10@github.com>
References: <2HUvBMP5STZWLZJ0Jbq2CN6xe9cBuLNCeViO168cmUU=.7eef2bbc-fab6-494c-bfef-915f4c52fe10@github.com>
Message-ID: <SppWcBz7eLVClJtfrEtLOxF97mXqwhiFVrLPItvdxWw=.88887fc2-880e-4276-a286-7b928a0773c7@github.com>

On Thu, 31 Jul 2025 19:27:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A clean backport of #1856 .
> 
> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values. The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.

LGTM. This is a clean backport to jfx25 of a safe, targeted fix.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1863#pullrequestreview-3076854664

From angorya at openjdk.org  Thu Jul 31 20:59:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 20:59:05 GMT
Subject: [jfx25] Integrated: 8364049: ToolBar shows overflow menu with
 fractional scale
In-Reply-To: <2HUvBMP5STZWLZJ0Jbq2CN6xe9cBuLNCeViO168cmUU=.7eef2bbc-fab6-494c-bfef-915f4c52fe10@github.com>
References: <2HUvBMP5STZWLZJ0Jbq2CN6xe9cBuLNCeViO168cmUU=.7eef2bbc-fab6-494c-bfef-915f4c52fe10@github.com>
Message-ID: <Vz4bMJSCBZHaoNFWIKDdd0f2coifwlgD0HowCUc48D4=.912084ff-4653-4b98-b92d-b3b58492f4a3@github.com>

On Thu, 31 Jul 2025 19:27:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> A clean backport of #1856 .
> 
> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values. The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.

This pull request has now been integrated.

Changeset: 4f694cb4
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4f694cb443c408c79176472fdf994b5ddcf1a8ae
Stats:     60 lines in 2 files changed: 51 ins; 3 del; 6 mod

8364049: ToolBar shows overflow menu with fractional scale

Reviewed-by: kcr
Backport-of: 4e334cb1ebbb370086d0a58bbe1d9a30d6665066

-------------

PR: https://git.openjdk.org/jfx/pull/1863

From angorya at openjdk.org  Thu Jul 31 21:04:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 21:04:03 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: <Iju33XpnACS0D6ZHuJf-VxQ6sU-Y0QoNvltt141mWP4=.d0a91591-d89d-441b-aec6-cd69e125d5d4@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).

My main concern with this PR is that we might get a minute performance improvement, while risking regression.  Would it be possible to get some measurements using a modern system?

What do you think?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1830#issuecomment-3141323662

From angorya at openjdk.org  Thu Jul 31 21:07:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 21:07:01 GMT
Subject: RFR: 8360886: Cmd + plus shortcut does not work reliably [v2]
In-Reply-To: <yQUgY-5Nbkn0v6KyBI2HUEr8XGLRF8GPtW_xuJ9AGpE=.8b212f89-47d6-4ee5-8f6e-42c7b5bdba4b@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>
Message-ID: <cqwwQsMn3Xj6t_zL_USW0xBvbySo9dB2gK1WvEGil2k=.79a4ad8e-db38-4c82-aa67-d2c580040298@github.com>

On Mon, 7 Jul 2025 16:59:13 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.
>
> 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.

Sorry, I've dropped the ball with the re-review.  lgtm.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1837#pullrequestreview-3076879921

From angorya at openjdk.org  Thu Jul 31 21:25:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 21:25:13 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v13]
In-Reply-To: <wT39QfwE1XmaNCayNuI-_1aAiBVZ5RGKJ12xI601vJQ=.8bf3ecf6-b6dc-4db2-8981-75b444ce4f98@github.com>
References: <iZ3FFjRQCTTdV-OxP8uooA5w90TEP5UwWKbu8hvdRV8=.70966f07-1c6a-4f32-af69-459de1a5270a@github.com>
 <wT39QfwE1XmaNCayNuI-_1aAiBVZ5RGKJ12xI601vJQ=.8bf3ecf6-b6dc-4db2-8981-75b444ce4f98@github.com>
Message-ID: <yUSUoUSZnYlLgOpmS5alCeyg1Iu1jSFq4YFemurbQjo=.e30ed9f4-6454-44fc-bd1d-3044655565e3@github.com>

On Thu, 31 Jul 2025 10:16: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 one additional commit since the last revision:
> 
>   nir: review followup

A number of files is missing `@Override` annotations, I've created [JDK-8364488](https://bugs.openjdk.org/browse/JDK-8364488) for those.

These files are not a part of my eclipse config normally (I could not get it configured to pick up the `../../build/libs/antlr4-4.7.2-complete.jar` correctly, eclipse complains about stull like

Description	Resource	Type	Path	Location
The package org.antlr.v4.runtime.atn is not accessible	JSLParser.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 3
The package org.antlr.v4.runtime.misc is not accessible	JSLLexer.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 10
The package org.antlr.v4.runtime.misc is not accessible	JSLParser.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 6
The package org.antlr.v4.runtime.tree is not accessible	JSLParser.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 7
The package org.antlr.v4.runtime is not accessible	JSLLexer.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 7
The package org.antlr.v4.runtime is not accessible	JSLParser.java	Java Problem	/graphics/build/gensrc/antlr/com/sun/scenario/effect/compiler	line 5


so there might be more warnings and errors, in addition to the unlikely argument type warnings in

Description	Resource	Type	Path	Location
Unlikely argument type String for contains(Object) on a Collection<Function>	MSLBackend.java	Java Problem	/graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw	line 216
Unlikely argument type String for contains(Object) on a Collection<Function>	MSLBackend.java	Java Problem	/graphics/src/jslc/java/com/sun/scenario/effect/compiler/backend/hw	line 238

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1824#issuecomment-3141374132

From angorya at openjdk.org  Thu Jul 31 23:01:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 31 Jul 2025 23:01:58 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: <VKjmfgJiqtBmkglOqPUz0rntBo3pZIczZOnomo7lhZQ=.05bfc6e8-ad27-4078-8285-49e14c942d1c@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)

Tested various scenarios on macOS 15.5 with the reproducer and the (updated) monkey tester from https://github.com/andy-goryachev-oracle/MonkeyTest , works as expected.

Finally, can remove the hack from

https://github.com/andy-goryachev/FxDock/blob/5d1128bd56a60d56ab743aa7c4f830bc248cc343/src/goryachev/fx/settings/WindowMonitor.java#L147

Many thanks!

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1860#pullrequestreview-3077116426

From kcr at openjdk.org  Thu Jul 31 23:16:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 31 Jul 2025 23:16:58 GMT
Subject: RFR: 8355990: [macOS] Restoring a maximized stage does not update
 the window size
In-Reply-To: <bZ58NMh2pG_9YXPCGb7BqrA4ln6li4Nm_tt_GPIh1As=.4fb2edb0-69e7-48da-9ca6-1570b2ea5701@github.com>
References: <oVuWKIQztm-ZOUwodBjXFA1VdHXLs8pZKrPWwJnwIec=.d498a61f-51bd-45e3-8429-0d93ba881e2a@github.com>
 <bZ58NMh2pG_9YXPCGb7BqrA4ln6li4Nm_tt_GPIh1As=.4fb2edb0-69e7-48da-9ca6-1570b2ea5701@github.com>
Message-ID: <Evk1r2MvuxD1T6om3GGOf8HXknp7BCvuGIeaZj6-CIo=.d9b433aa-4893-49fe-a3b4-b424f8b739d9@github.com>

On Wed, 30 Jul 2025 15:03:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @beldenfox It might be better to close [JDK-8179980](https://bugs.openjdk.org/browse/JDK-8179980) as a duplicate of this bug (JDK-8355990) rather than add it as a separate issue, since it is a natural step when fixing the underlying product bug to re-enable any skipped tests.

Thanks for closing [JDK-8179980](https://bugs.openjdk.org/browse/JDK-8179980) as a duplicate. Please remove it from the list of solved issues with `/issue remove 8179980` before you integrate.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1860#issuecomment-3141604003

From kcr at openjdk.org  Thu Jul 31 23:41:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 31 Jul 2025 23:41:07 GMT
Subject: RFR: 8271024: Implement macOS Metal Rendering Pipeline [v11]
In-Reply-To: <4QcTf_Qd_f4suDyxtg65qg0c10IUbH8aigNo55SMpzw=.29dae76a-21eb-4db0-8c07-ead9c4fa7c21@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>
Message-ID: <MoGhpjcRZa4WezxhTyvO1_wMll_ualOh8gd8yDRNHvI=.4fd170d2-6fa5-4ee6-88f4-394b5ce30144@github.com>

On Wed, 30 Jul 2025 19:10:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I just looked at which .java files are not on the classpath and pulled those source folders in:
>> <img width="227" height="234" alt="image" src="https://github.com/user-attachments/assets/a81ef455-cc97-4b75-be96-cbd3de5bb266" />
>
> 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?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2246510678