From jhendrikx at openjdk.org Sat Jun 1 04:56:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Jun 2024 04:56:08 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: References: Message-ID: <-Ng4nkcUTNo-aSKidSXd6s5TrfOnHkwKSQrIrENWtJA=.c2274189-ad03-4448-b36b-8fa082b899af@github.com> On Fri, 31 May 2024 16:54:58 GMT, Andy Goryachev wrote: >> The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). >> >> Made changes in `getPosX` of `TextRun` class to handle negative values. >> >> Tested the changes manually with the sample code present in the bug and using the MonkeyTester. > > modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 332: > >> 330: return x; >> 331: } >> 332: int prevIdx = (glyphIndex - 1)<<1; > > would it be possible to add a comment explaining why this code is doing what it's doing? specifically, the reason for the while() loop and Math.abs(). and perhaps mention that this happens on mac only. I think if this is specific to mac, and doesn't occur on other platforms that the supplied `positions` may be incorrect by the underlying `*GlyphLayout` code. Under Windows it will likely use the `DWGlyphLayout` to supply `positions`. On Mac this will be `CTGlyphLayout`. The more prudent course of action than seems to be to fix what is supplied by `CTGlyphLayout` instead of working around it in `TextRun`. I haven't checked it that extensively yet, but I think `positions` is not supposed to contain negative `x` values at all when not in compact mode. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1623146989 From mfox at openjdk.org Sat Jun 1 18:20:29 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 1 Jun 2024 18:20:29 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel Message-ID: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into fxpanelkeycode - An unrecognized key should produce KeyCode.UNDEFINED, not null. Changes: https://git.openjdk.org/jfx/pull/1470/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1470&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324232 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1470.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1470/head:pull/1470 PR: https://git.openjdk.org/jfx/pull/1470 From jhendrikx at openjdk.org Sat Jun 1 18:41:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 1 Jun 2024 18:41:06 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:15:56 GMT, Martin Fox wrote: > JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. Which key is it that causes this? There is a ticket https://bugs.openjdk.org/browse/JDK-8090319 that suggests completing the missing key codes is also an option. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1470#issuecomment-2143544040 From mfox at openjdk.org Sat Jun 1 19:04:06 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 1 Jun 2024 19:04:06 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:38:16 GMT, John Hendrikx wrote: > Which key is it that causes this? There is a ticket https://bugs.openjdk.org/browse/JDK-8090319 that suggests completing the missing key codes is also an option. The original bug report was for letter keys on layouts that don't generate Latin characters like Russian or Greek. On Windows AWT handles these keys by assigning a Latin key code (so shortcuts like Ctrl-A continue to work) and separately providing an extended key code based on the Unicode value. On Mac AWT is dropping the ball by not providing a Latin key code. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1470#issuecomment-2143550594 From mstrauss at openjdk.org Sun Jun 2 18:54:19 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 2 Jun 2024 18:54:19 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders Message-ID: This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. More specifically, the following types will now implement `Interpolatable`. - `Insets` - `Background` - `BackgroundFill` - `BackgroundImage` - `BackgroundPosition` - `BackgroundSize` - `Border` - `BorderImage` - `BorderStroke` - `BorderWidths` - `CornerRadii` - `ImagePattern` - `LinearGradient` - `RadialGradient` - `Stop` Note that this PR also changes the specification of `Interpolatable` to make users aware that they shouldn't assume any particular identity of the object returned from the `interpolate()` method. This allows the implementation to re-use objects and reduce the number of object allocations. ------------- Commit messages: - Add interpolation support for backgrounds and borders Changes: https://git.openjdk.org/jfx/pull/1471/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332895 Stats: 2867 lines in 42 files changed: 2470 ins; 72 del; 325 mod Patch: https://git.openjdk.org/jfx/pull/1471.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1471/head:pull/1471 PR: https://git.openjdk.org/jfx/pull/1471 From fkirmaier at openjdk.org Mon Jun 3 09:51:09 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Mon, 3 Jun 2024 09:51:09 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders In-Reply-To: References: Message-ID: On Sun, 2 Jun 2024 18:50:20 GMT, Michael Strau? wrote: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `ImagePattern` > - `LinearGradient` > - `RadialGradient` > - `Stop` > > Note that this PR also changes the specification of `Interpolatable` to make users aware that they shouldn't assume any particular identity of the object returned from the `interpolate()` method. This allows the implementation to re-use objects and reduce the number of object allocations. First, Thank you for working on these transitions! > Note that this PR also changes the specification of Interpolatable to make users aware that they shouldn't assume any particular identity of the object returned from the interpolate() method. This allows the implementation to re-use objects and reduce the number of object allocations. Can you elaborate on this? Are changes in the Region.background still trigger change events? If not, is there a mechanism to get them? Like Transform.onTransformChanged? Are the previous immutable objects like Background and Border now mutable? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2144762597 From mstrauss at openjdk.org Mon Jun 3 12:14:09 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 3 Jun 2024 12:14:09 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders In-Reply-To: References: Message-ID: <8jDV0NhcaBpLifnvIANzMWCLuUApRIOJ8JEnF7yYjoY=.77ef7c59-a837-4670-b47b-601a1782fe42@github.com> On Mon, 3 Jun 2024 09:48:40 GMT, Florian Kirmaier wrote: > Can you elaborate on this? Are changes in the Region.background still trigger change events? If not, is there a mechanism to get them? Like Transform.onTransformChanged? Are the previous immutable objects like Background and Border now mutable? I'm not entirely sure what you mean here, but nothing how backgrounds and borders work has changed. Both are still deeply immutable, what's new is that they implement `Interpolatable`. For example, if you want to change the background color of a region, you can't reassign `BackgroundFill.fill`. Instead, you will have to create a new `Background` instance that contains a new `BackgroundFill`, which contains the new color. This is what CSS does when it applies a new background color. This PR allows the CSS system to also create intermediate backgrounds that represent the transition from one color to the next. The `interpolate()` method may or may not return a new instance of the interpolatable object. For example, consider the current version of `Color.interpolate()`, which returns `this` for t<=0 and `endValue` for t>=1 (in other words, a new instance is not returned in all cases): @Override public Color interpolate(Color endValue, double t) { if (t <= 0.0) return this; if (t >= 1.0) return endValue; ... } However, the current specification of `Interpolatable.interpolate()` is a bit unclear on that: /* * The function calculates an interpolated value along the fraction * {@code t} between {@code 0.0} and {@code 1.0}. When {@code t} = 1.0, * {@code endVal} is returned. */ The updated specification is clearer: /** * Returns an intermediate value between the value of this {@code Interpolatable} and the specified * {@code endValue} using the linear interpolation factor {@code t}, ranging from 0 (inclusive) * to 1 (inclusive). *

* The returned value may not be a new instance; an implementation might also return one of the * two existing instances if the intermediate value would be equal to one of the existing values. * However, this is an optimization and applications should not assume any particular identity * of the returned value. *

* An implementation is not required to reject interpolation factors less than 0 or larger than 1, * but this specification gives no meaning to values returned outside of this range. For example, * an implementation might clamp the interpolation factor to [0..1], or it might continue the linear * interpolation outside of this range. */ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2145035539 From kpk at openjdk.org Tue Jun 4 05:29:05 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 4 Jun 2024 05:29:05 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: References: Message-ID: On Fri, 31 May 2024 17:21:56 GMT, Andy Goryachev wrote: > Seems to work with the example in the ticket and the TextArea in the Monkey Tester. No ill effects on Windows. (Did not test it on Linux) > I tested the issue on Linux. It is not reproducible. So this is specific to Mac only. > Could you come up with a unit test? I couldn't find a way to write unit test for this. I will explore more to find out if it is possible. Please let me know if you have any idea regarding this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1468#issuecomment-2146638068 From kpk at openjdk.org Tue Jun 4 05:35:13 2024 From: kpk at openjdk.org (Karthik P K) Date: Tue, 4 Jun 2024 05:35:13 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: <-Ng4nkcUTNo-aSKidSXd6s5TrfOnHkwKSQrIrENWtJA=.c2274189-ad03-4448-b36b-8fa082b899af@github.com> References: <-Ng4nkcUTNo-aSKidSXd6s5TrfOnHkwKSQrIrENWtJA=.c2274189-ad03-4448-b36b-8fa082b899af@github.com> Message-ID: On Sat, 1 Jun 2024 04:53:48 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 332: >> >>> 330: return x; >>> 331: } >>> 332: int prevIdx = (glyphIndex - 1)<<1; >> >> would it be possible to add a comment explaining why this code is doing what it's doing? specifically, the reason for the while() loop and Math.abs(). and perhaps mention that this happens on mac only. > > I think if this is specific to mac, and doesn't occur on other platforms that the supplied `positions` may be incorrect by the underlying `*GlyphLayout` code. Under Windows it will likely use the `DWGlyphLayout` to supply `positions`. On Mac this will be `CTGlyphLayout`. > > The more prudent course of action than seems to be to fix what is supplied by `CTGlyphLayout` instead of working around it in `TextRun`. > > I haven't checked it that extensively yet, but I think `positions` is not supposed to contain negative `x` values at all when not in compact mode. Yes the issue is specific to Mac only. Windows uses `DWGlyphLayout` for positions as you pointed out. Since the position obtained from the underlying platform itself is not correct Mac, looked like fixing it in either `TextRun` or in the native side does not make huge difference so went with this approach. However I will explore how we can fix it on the native side. If the `positions` is not supposed to contain negative value, it is an issue from Apple not in JavaFX. In this case should we actually fix the issue in JavaFX, as it becomes a workaround rather than a fix regardless of where we fix it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1625369735 From jhendrikx at openjdk.org Tue Jun 4 07:31:16 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 4 Jun 2024 07:31:16 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: References: <-Ng4nkcUTNo-aSKidSXd6s5TrfOnHkwKSQrIrENWtJA=.c2274189-ad03-4448-b36b-8fa082b899af@github.com> Message-ID: <1bZxC9Piz1ratwvYOqvR__F10760YD4QtsvXuXWqzBY=.a8a6ec76-8384-49f4-acf3-6e32ba963c08@github.com> On Tue, 4 Jun 2024 05:32:23 GMT, Karthik P K wrote: >> I think if this is specific to mac, and doesn't occur on other platforms that the supplied `positions` may be incorrect by the underlying `*GlyphLayout` code. Under Windows it will likely use the `DWGlyphLayout` to supply `positions`. On Mac this will be `CTGlyphLayout`. >> >> The more prudent course of action than seems to be to fix what is supplied by `CTGlyphLayout` instead of working around it in `TextRun`. >> >> I haven't checked it that extensively yet, but I think `positions` is not supposed to contain negative `x` values at all when not in compact mode. > > Yes the issue is specific to Mac only. Windows uses `DWGlyphLayout` for positions as you pointed out. > Since the position obtained from the underlying platform itself is not correct Mac, looked like fixing it in either `TextRun` or in the native side does not make huge difference so went with this approach. However I will explore how we can fix it on the native side. > > If the `positions` is not supposed to contain negative value, it is an issue from Apple not in JavaFX. In this case should we actually fix the issue in JavaFX, as it becomes a workaround rather than a fix regardless of where we fix it. The `*GlyphLayout` classes are adapters for a platform. Their job is to call native code, and to convert it to a standard format that JavaFX expects. The native code for Apple is probably perfectly fine, but it is not adapted to the standard format correctly for the case that you discovered. I'm suggesting therefore to change the `CTGlyphLayout` class to adapt/modify the `positions` array before it is given to JavaFX code that expects it to be in a specific format. `CTGlyphLayout` calls: run.shape(glyphCount, glyphs, positions, indices); It should not be too hard to fix `positions` passed here to be in the correct format so `TextRun` can remain unchanged. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1625493122 From mhanl at openjdk.org Tue Jun 4 12:36:35 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Jun 2024 12:36:35 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 17:47:22 GMT, Andy Goryachev wrote: > you are right: I see the focus rectangle jitter at 175% scale on win 11 (w/o the fix), so it must be a different issue. At this scale, it merely shows a thinner line, perhaps that's why I did not notice it earlier. Yeah exactly, it looks like when the focus rect is on the border of the window, it will sometimes disappear (probably jitter 'out' of the window). When there is some padding inbetween, the focus rect looks like it is jittering instead. Probably the same root cause. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2147422638 From mhanl at openjdk.org Tue Jun 4 12:39:23 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Jun 2024 12:39:23 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: <60CS4SSlEWCDETy3ndI17fezDpDVAJGGVZBL9dsJTC0=.deeb2333-a8e9-46a2-92d0-8c97b4ea49ac@github.com> On Tue, 28 May 2024 16:48:39 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test for changing the stylesheet and always process CSS for that matter > > tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 134: > >> 132: >> 133: @Test >> 134: void testSmallShowDelayTooltip() { > > what is the reason for removing 'public' keyword? JUnit 5 does not require you to keep the methods public. It was mostly done for better encapsulation, you can read more here, where also one of the JUnit Team responded. :) https://stackoverflow.com/questions/55215949/why-junit-5-default-access-modifier-changed-to-package-private ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1625927230 From mhanl at openjdk.org Tue Jun 4 12:42:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 4 Jun 2024 12:42:13 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 28 May 2024 16:51:11 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test for changing the stylesheet and always process CSS for that matter > > modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 493: > >> 491: scene.setUserAgentStylesheet(ownerScene.getUserAgentStylesheet()); >> 492: } >> 493: scene.getStylesheets().setAll(ownerScene.getStylesheets()); > > so if the application decides to set a particular style sheet on the tooltip scene, it will be ignored? Should it be addAll()? And if yes, should it check against duplicate entries? Yes, but I did not change this behaviour, as this method is always called right before showing. While this a bit weird, this is out of scope for at least this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1625931951 From mmack at openjdk.org Tue Jun 4 16:28:47 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 4 Jun 2024 16:28:47 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? wrote: > This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; I attempted to test this with the sample app in [JDK-8249737](https://bugs.openjdk.org/browse/JDK-8249737) and [Microsoft.Windows.Simulator](https://stackoverflow.com/questions/40274660/windows-10-how-do-i-test-touch-events-without-a-touchscreen) using the simulator's "Basic touch mode". The "Too many touch points reported" exception seems to be thrown consistently with `const bool isDirect = true;` (original before #394) and `const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0;` (this PR) I didn't see the exception with `const bool isDirect = IsTouchEvent();` (#394) and `const bool isDirect = false` (which is probably what IsTouchEvent() returns here). Not sure what this simulator actually sends, but someone more knowledgeable might want to have a look at what's happening. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2147933056 From mstrauss at openjdk.org Tue Jun 4 16:31:49 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 4 Jun 2024 16:31:49 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `ImagePattern` > - `LinearGradient` > - `RadialGradient` > - `Stop` > > Note that this PR also changes the specification of `Interpolatable` to make users aware that they shouldn't assume any particular identity of the object returned from the `interpolate()` method. This allows the implementation to re-use objects and reduce the number of object allocations. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - clean up imports - add since tags ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1471/files - new: https://git.openjdk.org/jfx/pull/1471/files/25bcb1df..bb84c57d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1471&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1471&range=00-01 Stats: 87 lines in 16 files changed: 79 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1471.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1471/head:pull/1471 PR: https://git.openjdk.org/jfx/pull/1471 From fkirmaier at openjdk.org Tue Jun 4 16:31:59 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Tue, 4 Jun 2024 16:31:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders In-Reply-To: References: Message-ID: On Sun, 2 Jun 2024 18:50:20 GMT, Michael Strau? wrote: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `ImagePattern` > - `LinearGradient` > - `RadialGradient` > - `Stop` > > Note that this PR also changes the specification of `Interpolatable` to make users aware that they shouldn't assume any particular identity of the object returned from the `interpolate()` method. This allows the implementation to re-use objects and reduce the number of object allocations. Ok, great! Thank you for the feedback. I feared some magic was happening, but based on your response, this looks good! As far as I understand this, this is just command sense and, in my opinion, doesn't have to be documented. It's somewhat confusing and irrelevant. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2147504885 From jvos at openjdk.org Tue Jun 4 16:37:07 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 16:37:07 GMT Subject: [jfx21u] RFR: 8331748: Update libxml2 to 2.12.6 Message-ID: 8331748: Update libxml2 to 2.12.6 ------------- Commit messages: - Backport 97b1402501983f121f75c24a510f466837fa2ecc Changes: https://git.openjdk.org/jfx21u/pull/58/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=58&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331748 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod Patch: https://git.openjdk.org/jfx21u/pull/58.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/58/head:pull/58 PR: https://git.openjdk.org/jfx21u/pull/58 From jvos at openjdk.org Tue Jun 4 16:43:31 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 16:43:31 GMT Subject: [jfx21u] RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Message-ID: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 ------------- Commit messages: - Backport d7ab55184f757a614f9fc8f191c3c5794a16cc88 Changes: https://git.openjdk.org/jfx21u/pull/59/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=59&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332328 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx21u/pull/59.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/59/head:pull/59 PR: https://git.openjdk.org/jfx21u/pull/59 From jvos at openjdk.org Tue Jun 4 16:49:24 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 16:49:24 GMT Subject: [jfx17u] RFR: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Message-ID: <3EC5jYD1qKaXrv3zuSu_NJ2hT2Q9fxOYs8nyfvo965c=.9bdf6074-a47e-4059-9f83-5a92c71c4ec7@github.com> 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 ------------- Commit messages: - Backport d7ab55184f757a614f9fc8f191c3c5794a16cc88 Changes: https://git.openjdk.org/jfx17u/pull/191/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332328 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/191.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/191/head:pull/191 PR: https://git.openjdk.org/jfx17u/pull/191 From jvos at openjdk.org Tue Jun 4 16:52:38 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 16:52:38 GMT Subject: [jfx17u] RFR: 8331748: Update libxml2 to 2.12.6 Message-ID: <7k1UIl8czLp7-licTRhVfeYNj1kXCJ_Qy4jfeiKKGC0=.50df9bd6-01ff-41fe-90c3-09a8fd3617a5@github.com> 8331748: Update libxml2 to 2.12.6 ------------- Commit messages: - Backport 97b1402501983f121f75c24a510f466837fa2ecc Changes: https://git.openjdk.org/jfx17u/pull/190/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331748 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod Patch: https://git.openjdk.org/jfx17u/pull/190.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/190/head:pull/190 PR: https://git.openjdk.org/jfx17u/pull/190 From jvos at openjdk.org Tue Jun 4 17:20:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:20:09 GMT Subject: [jfx21u] Integrated: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 14:35:28 GMT, Johan Vos wrote: > 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 This pull request has now been integrated. Changeset: 20866584 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/20866584cda10fd15a019047dc992e663ee48af0 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Upgrade GHA Linux build platform to Ubuntu 24.04 Backport-of: d7ab55184f757a614f9fc8f191c3c5794a16cc88 ------------- PR: https://git.openjdk.org/jfx21u/pull/59 From jvos at openjdk.org Tue Jun 4 17:22:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:22:11 GMT Subject: [jfx17u] Integrated: 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 In-Reply-To: <3EC5jYD1qKaXrv3zuSu_NJ2hT2Q9fxOYs8nyfvo965c=.9bdf6074-a47e-4059-9f83-5a92c71c4ec7@github.com> References: <3EC5jYD1qKaXrv3zuSu_NJ2hT2Q9fxOYs8nyfvo965c=.9bdf6074-a47e-4059-9f83-5a92c71c4ec7@github.com> Message-ID: On Tue, 4 Jun 2024 14:36:16 GMT, Johan Vos wrote: > 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 This pull request has now been integrated. Changeset: 3a7cad84 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/3a7cad84a3cbc5b63093975bcda440485023836e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8332328: [GHA] GitHub Actions build fails on Linux: unable to find gcc-13 Upgrade GHA Linux build platform to Ubuntu 24.04 Backport-of: d7ab55184f757a614f9fc8f191c3c5794a16cc88 ------------- PR: https://git.openjdk.org/jfx17u/pull/191 From jvos at openjdk.org Tue Jun 4 17:31:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:31:10 GMT Subject: [jfx21u] Integrated: 8331748: Update libxml2 to 2.12.6 In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 14:19:52 GMT, Johan Vos wrote: > 8331748: Update libxml2 to 2.12.6 This pull request has now been integrated. Changeset: f8e75ca6 Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/f8e75ca6b9fc2005285f76fe958c589cb9a328c3 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod 8331748: Update libxml2 to 2.12.6 Backport-of: 97b1402501983f121f75c24a510f466837fa2ecc ------------- PR: https://git.openjdk.org/jfx21u/pull/58 From jvos at openjdk.org Tue Jun 4 17:36:03 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:36:03 GMT Subject: [jfx17u] Integrated: 8331748: Update libxml2 to 2.12.6 In-Reply-To: <7k1UIl8czLp7-licTRhVfeYNj1kXCJ_Qy4jfeiKKGC0=.50df9bd6-01ff-41fe-90c3-09a8fd3617a5@github.com> References: <7k1UIl8czLp7-licTRhVfeYNj1kXCJ_Qy4jfeiKKGC0=.50df9bd6-01ff-41fe-90c3-09a8fd3617a5@github.com> Message-ID: <0IfnKCr66KxetiwCBJjAZvsjyiOJTQp__tcT5Sh3TOM=.5b78f9fc-c722-47bb-8765-ee0856de7852@github.com> On Tue, 4 Jun 2024 14:18:04 GMT, Johan Vos wrote: > 8331748: Update libxml2 to 2.12.6 This pull request has now been integrated. Changeset: 1dfcbed2 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/1dfcbed2f5586c3efceed4c95ebec3d23ee99573 Stats: 24912 lines in 115 files changed: 8485 ins; 11207 del; 5220 mod 8331748: Update libxml2 to 2.12.6 Backport-of: 97b1402501983f121f75c24a510f466837fa2ecc ------------- PR: https://git.openjdk.org/jfx17u/pull/190 From jvos at openjdk.org Tue Jun 4 17:43:18 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:43:18 GMT Subject: [jfx17u] RFR: 8332539: Update libxml2 to 2.12.7 Message-ID: <94ut8zZtl_FY-ZlN1JdKYRKFdbdvnsEA5i1Xin6KpjI=.ebe5c081-940b-4b10-9d1c-186b521b89ce@github.com> 8332539: Update libxml2 to 2.12.7 ------------- Commit messages: - Backport dedcf1d236b5429dcf3c42f5fd1095b28d5da063 Changes: https://git.openjdk.org/jfx17u/pull/192/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=192&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332539 Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod Patch: https://git.openjdk.org/jfx17u/pull/192.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/192/head:pull/192 PR: https://git.openjdk.org/jfx17u/pull/192 From jvos at openjdk.org Tue Jun 4 17:44:27 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:44:27 GMT Subject: [jfx21u] RFR: 8332539: Update libxml2 to 2.12.7 Message-ID: 8332539: Update libxml2 to 2.12.7 ------------- Commit messages: - Backport dedcf1d236b5429dcf3c42f5fd1095b28d5da063 Changes: https://git.openjdk.org/jfx21u/pull/60/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=60&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332539 Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod Patch: https://git.openjdk.org/jfx21u/pull/60.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/60/head:pull/60 PR: https://git.openjdk.org/jfx21u/pull/60 From jvos at openjdk.org Tue Jun 4 17:54:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:54:09 GMT Subject: [jfx17u] Integrated: 8332539: Update libxml2 to 2.12.7 In-Reply-To: <94ut8zZtl_FY-ZlN1JdKYRKFdbdvnsEA5i1Xin6KpjI=.ebe5c081-940b-4b10-9d1c-186b521b89ce@github.com> References: <94ut8zZtl_FY-ZlN1JdKYRKFdbdvnsEA5i1Xin6KpjI=.ebe5c081-940b-4b10-9d1c-186b521b89ce@github.com> Message-ID: On Tue, 4 Jun 2024 17:39:07 GMT, Johan Vos wrote: > 8332539: Update libxml2 to 2.12.7 This pull request has now been integrated. Changeset: 14575c54 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/14575c54a2b665384bbf4d81a1e2672912691562 Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod 8332539: Update libxml2 to 2.12.7 Backport-of: dedcf1d236b5429dcf3c42f5fd1095b28d5da063 ------------- PR: https://git.openjdk.org/jfx17u/pull/192 From jvos at openjdk.org Tue Jun 4 17:56:08 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 4 Jun 2024 17:56:08 GMT Subject: [jfx21u] Integrated: 8332539: Update libxml2 to 2.12.7 In-Reply-To: References: Message-ID: <5v2m3eEHXdla6WLdfPLe91lbEmbMyylMPPdjKxrYVjw=.877f78f9-547f-4cbe-8e08-37ab638987a0@github.com> On Tue, 4 Jun 2024 17:39:04 GMT, Johan Vos wrote: > 8332539: Update libxml2 to 2.12.7 This pull request has now been integrated. Changeset: 1d2bc14d Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/1d2bc14df14d09a921194b273249e394fb1012ff Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod 8332539: Update libxml2 to 2.12.7 Backport-of: dedcf1d236b5429dcf3c42f5fd1095b28d5da063 ------------- PR: https://git.openjdk.org/jfx21u/pull/60 From kcr at openjdk.org Tue Jun 4 20:23:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Jun 2024 20:23:08 GMT Subject: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v6] In-Reply-To: References: Message-ID: On Tue, 14 May 2024 13:37:32 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8323511: Adjust javadoc of the getViewportLength() > > Ok, I've updated the CSR accrodingly together with Eduard. @FlorianKirmaier This is ready for you to `/integrate` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2148351286 From kcr at openjdk.org Tue Jun 4 20:49:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Jun 2024 20:49:03 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: References: Message-ID: <0DsPTNpLGdTQR603Iscp4K79eMJQvyBygZh6CzoSrgY=.22060bf4-bd01-4326-99b4-874029421a60@github.com> On Tue, 4 Jun 2024 16:31:49 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `ImagePattern` >> - `LinearGradient` >> - `RadialGradient` >> - `Stop` >> >> Note that this PR also changes the specification of `Interpolatable` to make users aware that they shouldn't assume any particular identity of the object returned from the `interpolate()` method. This allows the implementation to re-use objects and reduce the number of object allocations. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - clean up imports > - add since tags This seems like a reasonable enhancement. I'll review it (not immediately, though). @nlisker would you be willing to be the second reviewer? A couple general comments: 1. Since you propose interpolating objects that aren't simple sets of floating-point fields, the overridden interpolate method should specify the behavior of the fields that are not. For example, different types of Paint are sometimes interpolatable and sometimes return either the start or end; some fields of BackgroundImage are interpolatable and others (notably the image itself) return either the start or the end; and so forth. 2. I spotted at least one place where you override equals, but not hashCode, so you'll need to provide an override for that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2148388868 From kcr at openjdk.org Tue Jun 4 20:54:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 4 Jun 2024 20:54:11 GMT Subject: RFR: 8311895: CSS Transitions [v22] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 15:09:38 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). >> >> ### Future enhancements >> CSS transition support for backgrounds and borders: #1471 >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up 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 62 commits: > > - Merge branch 'refs/heads/master' into feature/css-transitions > - document css parser limitation > - documentation change > - added documentation > - address review comments > - Merge branch 'refs/heads/master' into feature/css-transitions > - extract magic string to named constant > - use existing property in test > - fixed documentation > - Merge branch 'master' into feature/css-transitions > - ... and 52 more: https://git.openjdk.org/jfx/compare/cf09d6f1...10c06a97 It looks like this is getting close to being ready, and would be a good feature to get into JavaFX 23. I'll take a look at the specification changes in the PR, and review the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2148395938 From angorya at openjdk.org Tue Jun 4 23:03:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 4 Jun 2024 23:03:28 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding Message-ID: Changing certain ScrollBar, ScrollPane, and TextArea sizes from `em` to `px` in modena.css to make them independent of the font size *in that control*. After the change, the UI still looks good which can be tested by scaling default font size in a fairly wide range: .root { -fx-font-size:100%; } Using CSS Playground tool in the Monkey Tester at 50% and 200% font size: ![Screenshot 2024-05-31 at 14 48 41](https://github.com/openjdk/jfx/assets/107069028/c41e1500-ccfe-4aa6-b47a-42571f60b335) ![Screenshot 2024-05-31 at 14 49 34](https://github.com/openjdk/jfx/assets/107069028/78270097-4ce3-4c3e-8600-aba8d368495c) ------------- Commit messages: - 8314683 TextArea: scroll bar size and content padding Changes: https://git.openjdk.org/jfx/pull/1469/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314683 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1469.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1469/head:pull/1469 PR: https://git.openjdk.org/jfx/pull/1469 From fkirmaier at openjdk.org Wed Jun 5 07:24:35 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 5 Jun 2024 07:24:35 GMT Subject: RFR: 8277848: Binding and Unbinding to List leads to memory leak [v10] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'openjdk:master' into JDK-8277848-list-binding-leak - JDK-8277848 Removed print statements - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak # Conflicts: # modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java # modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java # modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak - JDK-8277848 Added tests to ensure no premature garbage collection is happening. - JDK-8277848 Added 3 more tests to verify that a bug discussed in the PR does not appear. - JDK-8277848 Added the 3 requests whitespaces - JDK-8277848 Further optimization based code review. This Bugfix should now event improve the performance - JDK-8277848 Added missing change - JDK-8277848 Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty. ------------- Changes: https://git.openjdk.org/jfx/pull/689/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=689&range=09 Stats: 244 lines in 6 files changed: 183 ins; 24 del; 37 mod Patch: https://git.openjdk.org/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/689/head:pull/689 PR: https://git.openjdk.org/jfx/pull/689 From fkirmaier at openjdk.org Wed Jun 5 07:33:14 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 5 Jun 2024 07:33:14 GMT Subject: RFR: 8277848: Binding and Unbinding to List leads to memory leak [v10] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 07:24:35 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'openjdk:master' into JDK-8277848-list-binding-leak > - JDK-8277848 > Removed print statements > - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak > > # Conflicts: > # modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java > # modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java > # modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java > - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak > - JDK-8277848 > Added tests to ensure no premature garbage collection is happening. > - JDK-8277848 > Added 3 more tests to verify that a bug discussed in the PR does not appear. > - JDK-8277848 > Added the 3 requests whitespaces > - JDK-8277848 > Further optimization based code review. > This Bugfix should now event improve the performance > - JDK-8277848 > Added missing change > - JDK-8277848 > Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty. Reopened, rebased with master, I still think this fixes a big problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/689#issuecomment-2149079501 From fkirmaier at openjdk.org Wed Jun 5 07:41:10 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 5 Jun 2024 07:41:10 GMT Subject: Integrated: 8323511: Scrollbar Click jumps inconsistent amount of pixels In-Reply-To: References: Message-ID: <5ZWMw8l11iJ2V4GYa14tJqQvCVnxvMPvtZkTP7AZjUM=.3b8be46d-9299-442b-a174-d050f5ac0c8e@github.com> On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier wrote: > As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is much more consistent. > > This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194 This pull request has now been integrated. Changeset: a39652b3 Author: Florian Kirmaier URL: https://git.openjdk.org/jfx/commit/a39652b3e72dd40dc2a24e06490d6b365f69bbe3 Stats: 122 lines in 4 files changed: 86 ins; 32 del; 4 mod 8323511: Scrollbar Click jumps inconsistent amount of pixels Co-authored-by: Eduard Sedov Reviewed-by: angorya, kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1326 From lkostyra at openjdk.org Wed Jun 5 13:25:07 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 5 Jun 2024 13:25:07 GMT Subject: Integrated: 8332748: Grammatical errors in animation API docs In-Reply-To: <0ezeLqz9ZUvQSjaHZna9gJUgr0E0KjO1fzeOVW9Oe64=.e8c1b2cf-79f8-4db5-8451-b7f376f4fe65@github.com> References: <0ezeLqz9ZUvQSjaHZna9gJUgr0E0KjO1fzeOVW9Oe64=.e8c1b2cf-79f8-4db5-8451-b7f376f4fe65@github.com> Message-ID: On Wed, 29 May 2024 06:53:40 GMT, Lukasz Kostyra wrote: > Checked code and fixed the gramatical error in Transition files: s/interval/intervals > > Fill and Stroke Transition had correct grammatical form already, so those were untouched. I couldn't find any other instances of this error in our javadoc documentation. This pull request has now been integrated. Changeset: 3e768dc7 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/3e768dc78e68b8e2a9d39b72581ef2b1da0597b1 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod 8332748: Grammatical errors in animation API docs Reviewed-by: nlisker, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1466 From kcr at openjdk.org Wed Jun 5 14:51:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 14:51:05 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding In-Reply-To: References: Message-ID: On Fri, 31 May 2024 21:50:08 GMT, Andy Goryachev wrote: > Changing certain ScrollBar, ScrollPane, and TextArea sizes from `em` to `px` in modena.css to make them independent of the font size *in that control*. > > After the change, the UI still looks good which can be tested by scaling default font size in a fairly wide range: > > > .root { -fx-font-size:100%; } > > > Using CSS Playground tool in the Monkey Tester at 50% and 200% font size: > > ![Screenshot 2024-05-31 at 14 48 41](https://github.com/openjdk/jfx/assets/107069028/c41e1500-ccfe-4aa6-b47a-42571f60b335) > > ![Screenshot 2024-05-31 at 14 49 34](https://github.com/openjdk/jfx/assets/107069028/78270097-4ce3-4c3e-8600-aba8d368495c) This PR presupposes that the scroll bar size and content padding _should_ be changed to be independent of the font size. Since the current choice was a deliberate decision, the issue should be changed to an Enhancement, and we need to consider the possible drawbacks of such a change. @andy-goryachev-oracle Wait for me to review this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150255521 PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150257958 From angorya at openjdk.org Wed Jun 5 14:55:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jun 2024 14:55:00 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding In-Reply-To: References: Message-ID: <6t0S2vJBoPiFKTVg_v5L4Dj3hmh0V7AVf3vLtYTcgo8=.d7ec26ca-bc60-431f-8787-e2c641cc520e@github.com> On Wed, 5 Jun 2024 14:47:55 GMT, Kevin Rushforth wrote: > This PR presupposes that the scroll bar size and content padding _should_ be changed to be independent of the font size I disagree. The size of the UI elements enveloping a content area should not depend on the font size of the font used in that particular content area. It should depend on the base font size, yes - i.e. it should scale with the scaling of the base font. BTW, no other Control exhibits this behavior, as far as I know. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150273865 From kcr at openjdk.org Wed Jun 5 15:11:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 15:11:03 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding In-Reply-To: <6t0S2vJBoPiFKTVg_v5L4Dj3hmh0V7AVf3vLtYTcgo8=.d7ec26ca-bc60-431f-8787-e2c641cc520e@github.com> References: <6t0S2vJBoPiFKTVg_v5L4Dj3hmh0V7AVf3vLtYTcgo8=.d7ec26ca-bc60-431f-8787-e2c641cc520e@github.com> Message-ID: On Wed, 5 Jun 2024 14:52:37 GMT, Andy Goryachev wrote: > > This PR presupposes that the scroll bar size and content padding _should_ be changed to be independent of the font size > > I disagree. The size of the UI elements enveloping a content area should not depend on the font size of the font used in that particular content area. It should depend on the base font size, yes - i.e. it should scale with the scaling of the base font. If I understand what you are saying, this change will make the size of the scroll bars and content padding be relative to the size of the root? In that case, yes this seems like a Bug (so no need to change the issue type). Can you update the issue title (in JBS and in this PR) to make this more clear? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150314228 From angorya at openjdk.org Wed Jun 5 15:34:05 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 5 Jun 2024 15:34:05 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding In-Reply-To: References: Message-ID: On Fri, 31 May 2024 21:50:08 GMT, Andy Goryachev wrote: > Changing certain ScrollBar, ScrollPane, and TextArea sizes from `em` to `px` in modena.css to make them independent of the font size *in that control*. > > After the change, the UI still looks good which can be tested by scaling default font size in a fairly wide range: > > > .root { -fx-font-size:100%; } > > > Using CSS Playground tool in the Monkey Tester at 50% and 200% font size: > > ![Screenshot 2024-05-31 at 14 48 41](https://github.com/openjdk/jfx/assets/107069028/c41e1500-ccfe-4aa6-b47a-42571f60b335) > > ![Screenshot 2024-05-31 at 14 49 34](https://github.com/openjdk/jfx/assets/107069028/78270097-4ce3-4c3e-8600-aba8d368495c) I must clarify: ideally, the size of all the UI elements *should* depend on the base font size, but currently does not (and I don't know exactly how to make it so). And apparently I am wrong about saying that only TextArea has the issue. Here is a screenshot of an app with the root font size set at 50%, and combo box at 200%: ![Screenshot 2024-06-05 at 08 29 21](https://github.com/openjdk/jfx/assets/107069028/99cc0666-e286-4464-9adc-c31be351a4c6) It does not look right either, the UI elements should not get scaled in my opinion, only the text. I'd rather have a consistent size of UI elements in an application. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150364599 From kcr at openjdk.org Wed Jun 5 16:39:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 16:39:04 GMT Subject: RFR: 8314683: TextArea: scroll bar size and content padding In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 15:31:05 GMT, Andy Goryachev wrote: > It does not look right either, the UI elements should not get scaled in my opinion, only the text. I'd rather have a consistent size of UI elements in an application. This will need further discussion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1469#issuecomment-2150496832 From kcr at openjdk.org Wed Jun 5 17:13:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 17:13:06 GMT Subject: RFR: 8330304: MenuBar: Invisible Menu works incorrectly with keyboard arrows [v2] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 15:17:19 GMT, Andy Goryachev wrote: >> The root cause is that the skin used two fields to store one entity (`focusedMenu` and `focusedMenuIndex`), causing mismatch when invisible menu(s) are present. >> >> The fix involves using a single index variable. >> >> Also wanted to note that in theory, `openMenu` and `openMenuButton` can also be replaced with a single boolean, but I decided not to change these in order to keep the amount of diffs to a minimum. > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments The fix looks good. I also verified that it fixes the problem, and that the new test passes with the fix and fails without the fix. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1467#pullrequestreview-2099793415 From kcr at openjdk.org Wed Jun 5 19:13:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 19:13:10 GMT Subject: RFR: 8311895: CSS Transitions [v22] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 15:09:38 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). >> >> ### Future enhancements >> CSS transition support for backgrounds and borders: #1471 >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up 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 62 commits: > > - Merge branch 'refs/heads/master' into feature/css-transitions > - document css parser limitation > - documentation change > - added documentation > - address review comments > - Merge branch 'refs/heads/master' into feature/css-transitions > - extract magic string to named constant > - use existing property in test > - fixed documentation > - Merge branch 'master' into feature/css-transitions > - ... and 52 more: https://git.openjdk.org/jfx/compare/cf09d6f1...10c06a97 The docs look good. I left one comment on the doc images and one question on the cssref.html changes. In parallel, I'll look at the CSR. modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 704: > 702: > 703: transition‑property > 704: [ none | all | <custom‑ident># ] Why is there a literal `#` after `` (and others below)? It shows up when viewing the doc. ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2097400072 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1628176431 From kcr at openjdk.org Wed Jun 5 19:13:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 19:13:11 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: On Sat, 25 May 2024 20:49:08 GMT, Nir Lisker wrote: >> I've included the images that are also used in the CSS reference documentation. Now there are two copies of these images in two different `doc-files` folders, but I guess that's okay. > > I think it's fine. Another option is to link to the part of the reference where they are. I would prefer to keep them in one place (scene) and link to the ones there (`../scene/doc-files/`). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1626611212 From kcr at openjdk.org Wed Jun 5 20:30:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 20:30:08 GMT Subject: RFR: 8277848: Binding and Unbinding to List leads to memory leak [v10] In-Reply-To: References: Message-ID: <6qCRw8u9djEX5p17Cp-QR4ynP_zSzxdmgcxTSJ6o2lM=.d6637582-cc2b-4d6e-84f4-e56ad77234a1@github.com> On Wed, 5 Jun 2024 07:29:58 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge branch 'openjdk:master' into JDK-8277848-list-binding-leak >> - JDK-8277848 >> Removed print statements >> - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak >> >> # Conflicts: >> # modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java >> # modules/javafx.base/src/main/java/javafx/beans/property/SetPropertyBase.java >> # modules/javafx.base/src/test/java/test/javafx/beans/property/SetPropertyBaseTest.java >> - Merge remote-tracking branch 'origjfx/master' into JDK-8277848-list-binding-leak >> - JDK-8277848 >> Added tests to ensure no premature garbage collection is happening. >> - JDK-8277848 >> Added 3 more tests to verify that a bug discussed in the PR does not appear. >> - JDK-8277848 >> Added the 3 requests whitespaces >> - JDK-8277848 >> Further optimization based code review. >> This Bugfix should now event improve the performance >> - JDK-8277848 >> Added missing change >> - JDK-8277848 >> Fixed memoryleak, when binding and unbinding a ListProperty. The same was fixed for SetProperty and MapProperty. > > Reopened, rebased with master, > I still think this fixes a big problem. @FlorianKirmaier You haven't answered @hjohn 's valid concerns. Until you do, I don't see the current version of this PR going anywhere. ------------- PR Comment: https://git.openjdk.org/jfx/pull/689#issuecomment-2150908626 From mstrauss at openjdk.org Wed Jun 5 21:49:56 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jun 2024 21:49:56 GMT Subject: RFR: 8311895: CSS Transitions [v22] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 17:43:46 GMT, Kevin Rushforth 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 62 commits: >> >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - document css parser limitation >> - documentation change >> - added documentation >> - address review comments >> - Merge branch 'refs/heads/master' into feature/css-transitions >> - extract magic string to named constant >> - use existing property in test >> - fixed documentation >> - Merge branch 'master' into feature/css-transitions >> - ... and 52 more: https://git.openjdk.org/jfx/compare/cf09d6f1...10c06a97 > > modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 704: > >> 702: >> 703: transition‑property >> 704: [ none | all | <custom‑ident># ] > > Why is there a literal `#` after `` (and others below)? It shows up when viewing the doc. The `#` indicates that one or more of the preceding entity can appear in a comma-separated list. Contrast that with `*` (used in other places in cssref.html), which indicates that zero or more of the preceding entity can appear (but doesn't prescribe a comma-separated list). See: https://www.w3.org/TR/css-values-4/#component-multipliers ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1628479243 From mstrauss at openjdk.org Wed Jun 5 21:59:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jun 2024 21:59:13 GMT Subject: RFR: 8311895: CSS Transitions [v23] In-Reply-To: References: Message-ID: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> > Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). > > ### Future enhancements > CSS transition support for backgrounds and borders: #1471 > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: link to easing function images in scene ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/10c06a97..29f43ed6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=22 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=21-22 Stats: 92 lines in 5 files changed: 0 ins; 88 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From kcr at openjdk.org Wed Jun 5 22:05:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 22:05:54 GMT Subject: RFR: 8311895: CSS Transitions [v22] In-Reply-To: References: Message-ID: On Wed, 5 Jun 2024 21:47:21 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 704: >> >>> 702: >>> 703: transition‑property >>> 704: [ none | all | <custom‑ident># ] >> >> Why is there a literal `#` after `` (and others below)? It shows up when viewing the doc. > > The `#` indicates that one or more of the preceding entity can appear in a comma-separated list. > Contrast that with `*` (used in other places in cssref.html), which indicates that zero or more of the preceding entity can appear (but doesn't prescribe a comma-separated list). > > See: https://www.w3.org/TR/css-values-4/#component-multipliers Thanks. That makes sense then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1628491779 From kcr at openjdk.org Wed Jun 5 22:42:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 22:42:49 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v7] In-Reply-To: References: Message-ID: On Mon, 27 May 2024 19:41:18 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Clarify in Javadoc The fix looks good. I left one comment on the docs, but otherwise OK. The test fails for me on Linux. Adding a sleep(500) before the assert checks fixes it (there is no reliable way to ensure certain operations without a sleep). I left inline comments. I also left one question regarding the per-test cleanup method. modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 295: > 293: * Set the width and height of this Window to match the size of the content > 294: * of this Window's Scene. > 295: * This request might be ignored if the Window is not allowed to do so, e.g. a {@link Stage} Maybe add a `

` tag here? Also, I recommend spelling out`for example,` (and adding a missing comma). tests/system/src/test/java/test/javafx/stage/SizeToSceneTest.java line 64: > 62: @AfterEach > 63: void afterEach() { > 64: Util.runAndWait(() -> mainStage.hide()); Do you need to check for `mainStage != null`? tests/system/src/test/java/test/javafx/stage/SizeToSceneTest.java line 67: > 65: } > 66: > 67: private static void assertStageScreenBounds() { I recommend adding `Util.sleep(500);` here. tests/system/src/test/java/test/javafx/stage/SizeToSceneTest.java line 75: > 73: } > 74: > 75: private static void assertStageSceneBounds() { I recommend adding `Util.sleep(500);` here. ------------- PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2100228766 PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1628399428 PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1628402170 PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1628460133 PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1628460259 From kcr at openjdk.org Wed Jun 5 22:42:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 5 Jun 2024 22:42:50 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v3] In-Reply-To: References: <16tHtx97hXBO0ouOygAIlrJvp12xtFkiuk4yWpTAfDw=.81eaabda-6c47-47f6-950b-464b35a61ee7@github.com> Message-ID: On Thu, 23 May 2024 13:48:48 GMT, Marius Hanl wrote: >> The fix looks good. The spec changes (updated javadocs) look good. Can you create the CSR for the spec change? >> >> I have a couple overall comments: >> >> * I wanted to verify different orders of operation, so I wrote a (manual) test program and attached it to the JBS bug. It covers the following cases: >> * set ; sizeToScene ; show >> * sizeToScene ; set ; show >> * show ; set ; sizeToScene >> * show ; sizeToScene ; set >> >> I verified that the first 3 are broken today. All cases work with your fix. I think it might be a good idea to add automated tests for the different orderings. >> >> * Please merge the latest master. Note that the calls to Util.shutdown in the tests must be fixed after this is done or they will no longer compile. > >> * I wanted to verify different orders of operation, so I wrote a (manual) test program > > I'm retesting and writing tests right now and reproduced one usecase out of my head that indeed 'fails' now. > Take the following code: > > Button button = new Button(); > button.setMinSize(440, 440); > > Scene scene = new Scene(button); > stage.setTitle("JavaFX test stage!"); > stage.setScene(scene); > > stage.setWidth(50); > stage.setHeight(50); > > stage.setFullScreen(true); > stage.sizeToScene(); > stage.setFullScreen(false); > > stage.show(); > > > With my logic, the `sizeToScene()` flag is not remembered, so the scene is not adjusted in the `sizeToScene` style after I 'go out' of fullscreen mode. > > If I do instead: > > stage.sizeToScene(); > stage.setFullScreen(true); > stage.setFullScreen(false); > > > The flag is remembered and the scene has the size of the button. Not sure what the expectation is here, but we could fix this problem by still remembering the flag if called. @Maran23 Can you create the CSR? The updated docs (with the small suggestion I made) look ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2151077735 From mstrauss at openjdk.org Wed Jun 5 23:05:50 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 5 Jun 2024 23:05:50 GMT Subject: RFR: 8311895: CSS Transitions [v17] In-Reply-To: References: Message-ID: <0wtlAA8xCJhwpU8QQP3Yu_d5qVdDQZpmpk3pWJTLjyU=.4a6546be-86ea-491c-8f2e-166a1016246e@github.com> On Tue, 4 Jun 2024 21:14:54 GMT, Kevin Rushforth wrote: >> I think it's fine. Another option is to link to the part of the reference where they are. > > I would prefer to keep them in one place (scene) and link to the ones there (`../scene/doc-files/`). I've linked to the files in `scene/doc-files/`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1628544278 From fkirmaier at openjdk.org Thu Jun 6 09:25:51 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 6 Jun 2024 09:25:51 GMT Subject: RFR: 8277848: Binding and Unbinding to List leads to memory leak [v8] In-Reply-To: <2wNSIfztUFGk7iqm9l_lctMsPGC-5ypKBWXoZG7Huuo=.4ea75cd4-5e0c-435a-a75c-64f296fd6a49@github.com> References: <2wNSIfztUFGk7iqm9l_lctMsPGC-5ypKBWXoZG7Huuo=.4ea75cd4-5e0c-435a-a75c-64f296fd6a49@github.com> Message-ID: <4wFkyPL33Z1rSJt9aW7NMcgetMChQobMX645VoQeih8=.0b364f84-d932-46de-a4d1-012bd60b7f8d@github.com> On Fri, 13 Jan 2023 12:35:12 GMT, John Hendrikx wrote: > Option 1 breaks the second example and leads to new problems; those new problems are even harder to debug than a simple memory leak, as all the elaborate tests all over the JavaFX code base that rely on System.gc() clearly show. I've written a library (https://github.com/Sandec/JMemoryBuddy) and integrated to the JFX projects, to make these tests reliable and understandable. Imo all tests using System.gc() directly should be refactored, because without some tricks it's not really deterministic. WeakReferences is a highly discussed topic. Lazy evaluation is also not without problems. I personally feel confident with using WeakReferences, especially after ensuring it's behavior with unit test. @hjohn made an own version of this PR, with this version my tests are included and green, so im fine with it too. [Link to PR](https://github.com/openjdk/jfx/pull/1004) It's important that normal Properties and CollectionProperties behave somehow similar. Thats why this (or hjohn) PR is important. This Version just fixes the bug, and ensures it behaves the same as other properties. In the end someone has to decide which version is better. But it would be great if one of them would move forward. In the end someone has to decide which PR is moved forward. ------------- PR Comment: https://git.openjdk.org/jfx/pull/689#issuecomment-2151816660 From kpk at openjdk.org Thu Jun 6 14:15:09 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 6 Jun 2024 14:15:09 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: References: Message-ID: > The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). > > Made changes in `getPosX` of `TextRun` class to handle negative values. > > Tested the changes manually with the sample code present in the bug and using the MonkeyTester. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fixing the issue in CTGlyphLayout class ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1468/files - new: https://git.openjdk.org/jfx/pull/1468/files/25def304..2798cc84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1468&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1468&range=00-01 Stats: 21 lines in 2 files changed: 14 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1468.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1468/head:pull/1468 PR: https://git.openjdk.org/jfx/pull/1468 From kpk at openjdk.org Thu Jun 6 14:15:09 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 6 Jun 2024 14:15:09 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: References: Message-ID: On Fri, 31 May 2024 14:39:00 GMT, Karthik P K wrote: > The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). > > Made changes in `getPosX` of `TextRun` class to handle negative values. > > Tested the changes manually with the sample code present in the bug and using the MonkeyTester. Fixed the issue in `CTGlyphLayout`. @andy-goryachev-oracle , @hjohn please re review ------------- PR Comment: https://git.openjdk.org/jfx/pull/1468#issuecomment-2152646725 From angorya at openjdk.org Thu Jun 6 14:46:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jun 2024 14:46:53 GMT Subject: Integrated: 8330304: MenuBar: Invisible Menu works incorrectly with keyboard arrows In-Reply-To: References: Message-ID: <1u7b48S07_l5hkUQ3QFw1Japd6YbSIhN9tzpTgHbOvo=.4a041b5b-20d6-4a27-9c74-ff170a4e30ef@github.com> On Thu, 30 May 2024 15:36:37 GMT, Andy Goryachev wrote: > The root cause is that the skin used two fields to store one entity (`focusedMenu` and `focusedMenuIndex`), causing mismatch when invisible menu(s) are present. > > The fix involves using a single index variable. > > Also wanted to note that in theory, `openMenu` and `openMenuButton` can also be replaced with a single boolean, but I decided not to change these in order to keep the amount of diffs to a minimum. This pull request has now been integrated. Changeset: 4a33d5ef Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/4a33d5ef13c7bc72900fa6769fe4779ccec5bc98 Stats: 84 lines in 3 files changed: 68 ins; 9 del; 7 mod 8330304: MenuBar: Invisible Menu works incorrectly with keyboard arrows Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1467 From angorya at openjdk.org Thu Jun 6 15:08:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jun 2024 15:08:53 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 14:15:09 GMT, Karthik P K wrote: >> The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). >> >> Made changes in `getPosX` of `TextRun` class to handle negative values. >> >> Tested the changes manually with the sample code present in the bug and using the MonkeyTester. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fixing the issue in CTGlyphLayout class modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java line 159: > 157: } > 158: /* JDK-8330559 - Mac specific issue. > 159: * When traling spces are present in the text containing LTR and RTL spelling: "trailing spaces" modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java line 161: > 159: * When traling spces are present in the text containing LTR and RTL > 160: * text together, negative position values are returned for spaces from > 161: * the native side. Since TextRun expects positive value relative to the should we limit the scope of the change to mac only (PlatformUtil.isMac()?) since CTGlyphLayout is common code? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1629708148 PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1629711705 From kcr at openjdk.org Thu Jun 6 15:23:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 6 Jun 2024 15:23:51 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 14:59:04 GMT, Andy Goryachev wrote: >> Karthik P K has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing the issue in CTGlyphLayout class > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java line 161: > >> 159: * When traling spces are present in the text containing LTR and RTL >> 160: * text together, negative position values are returned for spaces from >> 161: * the native side. Since TextRun expects positive value relative to the > > should we limit the scope of the change to mac only (PlatformUtil.isMac()?) since CTGlyphLayout is common code? CTGlyphLayout is not common code. It is mac only (so no need to mention mac) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1629745180 From angorya at openjdk.org Thu Jun 6 15:38:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jun 2024 15:38:00 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: References: Message-ID: <3-eLdxrhVT3kA_N3o4o-3wl6M_67Y10VSMQCiz4oTRU=.556d5f83-11ea-4ea2-8ffe-f5cea8208741@github.com> On Thu, 6 Jun 2024 15:21:15 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java line 161: >> >>> 159: * When traling spces are present in the text containing LTR and RTL >>> 160: * text together, negative position values are returned for spaces from >>> 161: * the native side. Since TextRun expects positive value relative to the >> >> should we limit the scope of the change to mac only (PlatformUtil.isMac()?) since CTGlyphLayout is common code? > > CTGlyphLayout is not common code. It is mac only (so no need to mention mac) I see, PrismFontFactory:164 getNativeFactoryName(). It would be nice to place platform-specific code in a package bearing the platform name, or at least mention this in a class-level comment, but I guess it's too late. It means the scope is already limited to macOS, we are good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1629765619 From kpk at openjdk.org Thu Jun 6 16:46:39 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 6 Jun 2024 16:46:39 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v3] In-Reply-To: References: Message-ID: <0I68B2CucfMd8N08W-KurP2n8z6h63z-epyyQN_Yya8=.07885e2a-ad0a-49fe-8f66-cf6e77ed31e8@github.com> > The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). > > Made changes in `getPosX` of `TextRun` class to handle negative values. > > Tested the changes manually with the sample code present in the bug and using the MonkeyTester. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Typo fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1468/files - new: https://git.openjdk.org/jfx/pull/1468/files/2798cc84..148a109a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1468&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1468&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1468.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1468/head:pull/1468 PR: https://git.openjdk.org/jfx/pull/1468 From angorya at openjdk.org Thu Jun 6 16:56:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jun 2024 16:56:50 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v3] In-Reply-To: <0I68B2CucfMd8N08W-KurP2n8z6h63z-epyyQN_Yya8=.07885e2a-ad0a-49fe-8f66-cf6e77ed31e8@github.com> References: <0I68B2CucfMd8N08W-KurP2n8z6h63z-epyyQN_Yya8=.07885e2a-ad0a-49fe-8f66-cf6e77ed31e8@github.com> Message-ID: On Thu, 6 Jun 2024 16:46:39 GMT, Karthik P K wrote: >> The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). >> >> Made changes in `getPosX` of `TextRun` class to handle negative values. >> >> Tested the changes manually with the sample code present in the bug and using the MonkeyTester. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Typo fix Found another problem: the offset of the whole string appears to be incorrect after the fix: ![Screenshot 2024-06-06 at 09 50 35](https://github.com/openjdk/jfx/assets/107069028/1b1162ed-51d6-4fa1-ae90-12225ed00b82) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1468#issuecomment-2152985278 From sykora at openjdk.org Thu Jun 6 18:07:11 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 6 Jun 2024 18:07:11 GMT Subject: RFR: 8333147: update maven classifier syntax to recent gradle version Message-ID: Replaces the deprecated `classifier` property with `archiveClassifier`. The property was removed with the release of Gradle 8.0: https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#abstractarchivetask_api_cleanup ------------- Commit messages: - fix 8333147 Changes: https://git.openjdk.org/jfx/pull/1472/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1472&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333147 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1472.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1472/head:pull/1472 PR: https://git.openjdk.org/jfx/pull/1472 From openjdk at laurinmurer.ch Thu Jun 6 19:04:57 2024 From: openjdk at laurinmurer.ch (Laurin Murer) Date: Thu, 6 Jun 2024 21:04:57 +0200 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 Message-ID: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> Following up on JDK-8289521 from 2022 and JavaFX 18, I still can't publish an app containing JavaFX Web 21 to Apples App Store. They rejected it because my app uses or references the following non-public or deprecated APIs: Contents/runtime/Contents/Home/lib/libjfxwebkit.dylib Symbols: ? _cache_simulate_memory_warning_event "The use of non-public or deprecated APIs is not permitted on the App Store, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms.? (Quote from Apple) Does anyone have an idea how to fix this? From jhendrikx at openjdk.org Thu Jun 6 20:27:16 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 6 Jun 2024 20:27:16 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: <3-eLdxrhVT3kA_N3o4o-3wl6M_67Y10VSMQCiz4oTRU=.556d5f83-11ea-4ea2-8ffe-f5cea8208741@github.com> References: <3-eLdxrhVT3kA_N3o4o-3wl6M_67Y10VSMQCiz4oTRU=.556d5f83-11ea-4ea2-8ffe-f5cea8208741@github.com> Message-ID: <7lT6S2M4vRMk-gxjW0SK7755IPCo6U2BhTdpxOn5sdM=.0d608cb4-9106-43a4-abae-8fd8c8443f2c@github.com> On Thu, 6 Jun 2024 15:35:07 GMT, Andy Goryachev wrote: >> CTGlyphLayout is not common code. It is mac only (so no need to mention mac) > > I see, PrismFontFactory:164 getNativeFactoryName(). > It would be nice to place platform-specific code in a package bearing the platform name, or at least mention this in a class-level comment, but I guess it's too late. > > It means the scope is already limited to macOS, we are good. I'm having some doubts about the solution still. It is mentioned that this problem can occur in text containing both LTR and RTL text together, however, as far as I can see, a `TextRun` never contains a mix of text directions. Can you clarify this? Also in RTL text, I'm guessing "trailing" spaces are in fact what we call leading spaces in LTR text, ie. trailing spaces in a RTL text sample would be: ` ???` I'm guessing that CT (Core Text) returns the positions of all the trailing spaces as negative values, not just the first, and the first glyph (seen from the left) with an offset of 0. Since the CT framework can also handle alignments, but FX is not making use of this, I think all calculations are done with the standard left alignment. It would make sense for spaces that "fall off" the left end (because they're "trailing") to have negative values. Similarly, if you did LTR text for `cat ` with a right alignment, all glyphs would have negative values, except the two trailing spaces that would have positive values. So I'm curious to see what happens if you have more than one trailing space (eg. ` ???`) and what `CTRunGetPositions` returns then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1630186928 From mik3hall at gmail.com Thu Jun 6 21:03:10 2024 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 6 Jun 2024 16:03:10 -0500 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> Message-ID: <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> Try a newer/older version of JavaFX? I?m not sure which version I cloned jfx off of GitHub but if I search the directory mentioned in the bug report I find no references to the problem symbol. > On Jun 6, 2024, at 2:04?PM, Laurin Murer wrote: > > Following up on JDK-8289521 from 2022 and JavaFX 18, I still can't publish an app containing JavaFX Web 21 to Apples App Store. > > They rejected it because my app uses or references the following non-public or deprecated APIs: > > Contents/runtime/Contents/Home/lib/libjfxwebkit.dylib > Symbols: > ? _cache_simulate_memory_warning_event > > "The use of non-public or deprecated APIs is not permitted on the App Store, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms.? (Quote from Apple) > > Does anyone have an idea how to fix this? From mik3hall at gmail.com Thu Jun 6 21:12:02 2024 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 6 Jun 2024 16:12:02 -0500 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> Message-ID: Nevermind. Found it. Needed to strip the leading _ jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm extern "C" void cache_simulate_memory_warning_event(uint64_t); void MemoryPressureHandler::platformReleaseMemory(Critical critical) { if (critical == Critical::Yes && (!isUnderMemoryPressure() || m_isSimulatingMemoryPressure)) { // libcache listens to OS memory notifications, but for process suspension // or memory pressure simulation, we need to prod it manually: cache_simulate_memory_warning_event(DISPATCH_MEMORYPRESSURE_CRITICAL); } } Maybe someone else can suggest how you change that to avoid the non-public warning. Or you could maybe no-op the references and apparently take some risk in low memory situations. > On Jun 6, 2024, at 4:03?PM, Michael Hall wrote: > > Try a newer/older version of JavaFX? > I?m not sure which version I cloned jfx off of GitHub but if I search the directory mentioned in the bug report I find no references to the problem symbol. > >> On Jun 6, 2024, at 2:04?PM, Laurin Murer wrote: >> >> Following up on JDK-8289521 from 2022 and JavaFX 18, I still can't publish an app containing JavaFX Web 21 to Apples App Store. >> >> They rejected it because my app uses or references the following non-public or deprecated APIs: >> >> Contents/runtime/Contents/Home/lib/libjfxwebkit.dylib >> Symbols: >> ? _cache_simulate_memory_warning_event >> >> "The use of non-public or deprecated APIs is not permitted on the App Store, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms.? (Quote from Apple) >> >> Does anyone have an idea how to fix this? > From mik3hall at gmail.com Thu Jun 6 23:30:47 2024 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 6 Jun 2024 18:30:47 -0500 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> Message-ID: <3FAEE9C1-5B9D-461D-9192-19002111559B@gmail.com> Just noticed? /* * Copyright (C) 2011-2017 Apple Inc. All Rights Reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. In the source below. So Apple itself is the source of the problem. Possibly this is why there has been no JavaFX progress. Curious, can you change and build the GitHub jfx project and distribute it with an application? The above appears to allow this. https://opensource.apple.com/source/WTF/WTF-7605.2.8.0.1/wtf/cocoa/MemoryPressureHandlerCocoa.mm.auto.html > On Jun 6, 2024, at 4:12?PM, Michael Hall wrote: > > Nevermind. Found it. Needed to strip the leading _ > > jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Thu Jun 6 23:41:14 2024 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 6 Jun 2024 18:41:14 -0500 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: <3FAEE9C1-5B9D-461D-9192-19002111559B@gmail.com> References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> <3FAEE9C1-5B9D-461D-9192-19002111559B@gmail.com> Message-ID: <87CF02DC-2C8F-4508-BA70-6BC4E7879777@gmail.com> Odd, but searching shows this used in a different places and nowhere does it appear anyone has made any changes to the symbol referencing code. It seems like some applications should of used this same code as-is. Sort of strange. I?m done with what digging I think I?m going to do. GL. > On Jun 6, 2024, at 6:30?PM, Michael Hall wrote: > > Just noticed? > > /* > * Copyright (C) 2011-2017 Apple Inc. All Rights Reserved. > * From angorya at openjdk.org Thu Jun 6 23:50:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 6 Jun 2024 23:50:16 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: <7lT6S2M4vRMk-gxjW0SK7755IPCo6U2BhTdpxOn5sdM=.0d608cb4-9106-43a4-abae-8fd8c8443f2c@github.com> References: <3-eLdxrhVT3kA_N3o4o-3wl6M_67Y10VSMQCiz4oTRU=.556d5f83-11ea-4ea2-8ffe-f5cea8208741@github.com> <7lT6S2M4vRMk-gxjW0SK7755IPCo6U2BhTdpxOn5sdM=.0d608cb4-9106-43a4-abae-8fd8c8443f2c@github.com> Message-ID: On Thu, 6 Jun 2024 20:24:07 GMT, John Hendrikx wrote: >> I see, PrismFontFactory:164 getNativeFactoryName(). >> It would be nice to place platform-specific code in a package bearing the platform name, or at least mention this in a class-level comment, but I guess it's too late. >> >> It means the scope is already limited to macOS, we are good. > > I'm having some doubts about the solution still. It is mentioned that this problem can occur in text containing both LTR and RTL text together, however, as far as I can see, a `TextRun` never contains a mix of text directions. Can you clarify this? > > Also in RTL text, I'm guessing "trailing" spaces are in fact what we call leading spaces in LTR text, ie. trailing spaces in a RTL text sample would be: ` ???` > > I'm guessing that CT (Core Text) returns the positions of all the trailing spaces as negative values, not just the first, and the first glyph (seen from the left) with an offset of 0. Since the CT framework can also handle alignments, but FX is not making use of this, I think all calculations are done with the standard left alignment. It would make sense for spaces that "fall off" the left end (because they're "trailing") to have negative values. Similarly, if you did LTR text for `cat ` with a right alignment, all glyphs would have negative values, except the two trailing spaces that would have positive values. > > So I'm curious to see what happens if you have more than one trailing space (eg. ` ???`) and what `CTRunGetPositions` returns then. Yes, I am also curious about the exact meaning of these negative values. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1630411969 From kpk at openjdk.org Fri Jun 7 07:54:20 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 7 Jun 2024 07:54:20 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v3] In-Reply-To: References: <0I68B2CucfMd8N08W-KurP2n8z6h63z-epyyQN_Yya8=.07885e2a-ad0a-49fe-8f66-cf6e77ed31e8@github.com> Message-ID: On Thu, 6 Jun 2024 16:53:47 GMT, Andy Goryachev wrote: > The code to reproduce was > > ``` > flow = new TextFlow( > t("Arabic:", Color.RED), > t(" ", Color.YELLOW), > t("???????", Color.GREEN), > new Text("\n"), > t("Hebrew: ", Color.BLUE), > t("?????", Color.BLACK)); > ``` I can see issue with this example. I have to check this case. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1468#issuecomment-2154291068 From kpk at openjdk.org Fri Jun 7 07:54:21 2024 From: kpk at openjdk.org (Karthik P K) Date: Fri, 7 Jun 2024 07:54:21 GMT Subject: RFR: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode [v2] In-Reply-To: References: <3-eLdxrhVT3kA_N3o4o-3wl6M_67Y10VSMQCiz4oTRU=.556d5f83-11ea-4ea2-8ffe-f5cea8208741@github.com> <7lT6S2M4vRMk-gxjW0SK7755IPCo6U2BhTdpxOn5sdM=.0d608cb4-9106-43a4-abae-8fd8c8443f2c@github.com> Message-ID: On Thu, 6 Jun 2024 23:47:44 GMT, Andy Goryachev wrote: >> I'm having some doubts about the solution still. It is mentioned that this problem can occur in text containing both LTR and RTL text together, however, as far as I can see, a `TextRun` never contains a mix of text directions. Can you clarify this? >> >> Also in RTL text, I'm guessing "trailing" spaces are in fact what we call leading spaces in LTR text, ie. trailing spaces in a RTL text sample would be: ` ???` >> >> I'm guessing that CT (Core Text) returns the positions of all the trailing spaces as negative values, not just the first, and the first glyph (seen from the left) with an offset of 0. Since the CT framework can also handle alignments, but FX is not making use of this, I think all calculations are done with the standard left alignment. It would make sense for spaces that "fall off" the left end (because they're "trailing") to have negative values. Similarly, if you did LTR text for `cat ` with a right alignment, all glyphs would have negative values, except the two trailing spaces that would have positive values. >> >> So I'm curious to see what happens if you have more than one trailing space (eg. ` ???`) and what `CTRunGetPositions` returns then. > > Yes, I am also curious about the exact meaning of these negative values. > I'm having some doubts about the solution still. It is mentioned that this problem can occur in text containing both LTR and RTL text together, however, as far as I can see, a `TextRun` never contains a mix of text directions. Can you clarify this? > LTR and RTL text will not be together in a TextRun but negative value will not be obtained for spaces in all the cases. For example: In the the case where Text nodes are present in TextFlow like shown below, none of the spaces will have negative value. In fact `CTGlyphLayout` class will not be called at all. flow = new TextFlow( t("Arabic", Color.RED), t(" ", Color.YELLOW), t("Arabic", Color.RED)); If we consider cases like flow = new TextFlow( t("???????", Color.GREEN), t(" ", Color.YELLOW) or flow = new TextFlow( t(" ", Color.YELLOW), t("???????", Color.GREEN) all the spaces will have negative value obtained from the native function `CTRunGetPositionsPtr` using `CTGlyphLayout` class. To make all the negative value positive, I'm adding the least value to all the positions so that lowest value becomes 0 and rest of the positions are shifted by the same offset. > Since the CT framework can also handle alignments, but FX is not making use of this, I think all calculations are done with the standard left alignment. It would make sense for spaces that "fall off" the left end (because they're "trailing") to have negative values. Similarly, if you did LTR text for `cat ` with a right alignment, all glyphs would have negative values, except the two trailing spaces that would have positive values. > I need to check this case. All the testing I have done is by changing the node orientation of scene to RTL mode with above mentioned cases. Did not change text alignments separately. > So I'm curious to see what happens if you have more than one trailing space (eg. ` ???`) and what `CTRunGetPositions` returns then. For this arabic text with scene node orientation set to RTL and default text alignment, trailing spaces get negative values. If the space is added in leading side, then I see positive values. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1630794483 From tsayao at openjdk.org Fri Jun 7 09:54:19 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 7 Jun 2024 09:54:19 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 Can someone kindly review it? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2154496026 From tsayao at openjdk.org Fri Jun 7 09:57:24 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 7 Jun 2024 09:57:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 19:10:17 GMT, Glavo 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 94 commits: >> >> - Merge branch 'master' into new_ime >> - Add signals to avoid warnings >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Add check for jview >> - - Fix comment path >> - - Fix double keyrelease >> - - Use a work-around to relative positioning (until wayland is not officially supported) >> - Unref pango attr list >> - Merge branch 'master' into new_ime >> - Account the case of !filtered >> - Fix change of focus when on preedit + add filter on key release >> - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 > > I've built this PR and made it available to some HMCL users (https://github.com/HMCL-dev/HMCL/discussions/3050). > > I will also report back to you once I receive feedback. @Glavo did you get any feedback? I can provide a build with this PR included, if that's getting on the way. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2154501300 From kcr at openjdk.org Fri Jun 7 12:04:19 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Jun 2024 12:04:19 GMT Subject: RFR: 8333147: update maven classifier syntax to recent gradle version In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 17:35:54 GMT, Joeri Sykora wrote: > Replaces the deprecated `classifier` property with `archiveClassifier`. The property was removed with the release of Gradle 8.0: https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#abstractarchivetask_api_cleanup Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1472#pullrequestreview-2104373748 From kevin.rushforth at oracle.com Fri Jun 7 12:10:20 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 7 Jun 2024 05:10:20 -0700 Subject: Result: New OpenJFX Reviewer: John Hendrikx Message-ID: <72eda936-db09-4043-83b8-bbf7dfd8c648@oracle.com> Voting for John Hendrikx [1] to OpenJFX Reviewer [2] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#jhendrikx [2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-May/047150.html From sykora at openjdk.org Fri Jun 7 12:39:18 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 7 Jun 2024 12:39:18 GMT Subject: Integrated: 8333147: update maven classifier syntax to recent gradle version In-Reply-To: References: Message-ID: On Thu, 6 Jun 2024 17:35:54 GMT, Joeri Sykora wrote: > Replaces the deprecated `classifier` property with `archiveClassifier`. The property was removed with the release of Gradle 8.0: https://docs.gradle.org/8.0/userguide/upgrading_version_7.html#abstractarchivetask_api_cleanup This pull request has now been integrated. Changeset: c8b96e4e Author: Joeri Sykora Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c8b96e4e6da18b4ab1331bb3a5b48cf1b8b3e2e6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8333147: update maven classifier syntax to recent gradle version Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1472 From mik3hall at gmail.com Fri Jun 7 15:48:04 2024 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 7 Jun 2024 10:48:04 -0500 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: <87CF02DC-2C8F-4508-BA70-6BC4E7879777@gmail.com> References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> <3FAEE9C1-5B9D-461D-9192-19002111559B@gmail.com> <87CF02DC-2C8F-4508-BA70-6BC4E7879777@gmail.com> Message-ID: Sorry, I did a little more digging on this. My best guess is that Apple is rejecting this because they think you are using a non-public API of their own. The OpenJFX version of MemoryPressureHandlerCocoa.mm matches what appears to be the current WebKit version. [1] Older versions appear somewhat different. Including this? #if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED >= 101000 [2][3] [3] seems to show where this code was actually introduced with the above included. It might be that for a Cocoa version it was thought that this compiler directive wasn?t needed but it actually still is? Anyhow, adding something similar now might achieve a no-op that would get past them flagging this as an error. ?locate? on my machine doesn?t seem to show the libcache.dylib mentioned anywhere other than Xcode and other developer locations. [1] https://github.com/WebKit/webkit/blob/main/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm [2] https://opensource.apple.com/source/WebCore/WebCore-7601.5.17/platform/cocoa/MemoryPressureHandlerCocoa.mm.auto.html [3] https://fossies.org/diffs/WebKit/r174650_vs_r189384/Source/WebCore/platform/cocoa/MemoryPressureHandlerCocoa.mm-diff.html > On Jun 6, 2024, at 6:41?PM, Michael Hall wrote: > > Odd, but searching shows this used in a different places and nowhere does it appear anyone has made any changes to the symbol referencing code. > It seems like some applications should of used this same code as-is. > Sort of strange. > I?m done with what digging I think I?m going to do. > > GL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jun 7 16:04:30 2024 From: duke at openjdk.org (Glavo) Date: Fri, 7 Jun 2024 16:04:30 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 19:10:17 GMT, Glavo 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 94 commits: >> >> - Merge branch 'master' into new_ime >> - Add signals to avoid warnings >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Add check for jview >> - - Fix comment path >> - - Fix double keyrelease >> - - Use a work-around to relative positioning (until wayland is not officially supported) >> - Unref pango attr list >> - Merge branch 'master' into new_ime >> - Account the case of !filtered >> - Fix change of focus when on preedit + add filter on key release >> - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 > > I've built this PR and made it available to some HMCL users (https://github.com/HMCL-dev/HMCL/discussions/3050). > > I will also report back to you once I receive feedback. > @Glavo did you get any feedback? > > I can provide a build with this PR included, if that's getting on the way. We have some users who tried it and they said it worked fine. I'm planning on doing some more testing in the next couple of days. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2155123139 From mfox at openjdk.org Fri Jun 7 18:33:26 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 7 Jun 2024 18:33:26 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space Message-ID: When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. ------------- Commit messages: - Color space is two words. - Merge remote-tracking branch 'upstream/master' into colormgmt - Merge remote-tracking branch 'upstream/master' into colormgmt - Merge remote-tracking branch 'upstream/master' into colormgmt - Robot code is now executed inside autorelease pool - Cleaned up SRGBTest - Merge remote-tracking branch 'upstream/master' into colormgmt - We don't need to manually release the color space. - Merge remote-tracking branch 'upstream/master' into colormgmt - Correctly rounding when converting color components to bytes - ... and 9 more: https://git.openjdk.org/jfx/compare/4a33d5ef...ae06f5a4 Changes: https://git.openjdk.org/jfx/pull/1473/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325445 Stats: 292 lines in 8 files changed: 285 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1473.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1473/head:pull/1473 PR: https://git.openjdk.org/jfx/pull/1473 From kcr at openjdk.org Fri Jun 7 22:56:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 7 Jun 2024 22:56:15 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space In-Reply-To: References: Message-ID: <3YpyUIMwF2WzuPnq6VUClF1xvotEJW0ibQe3_2vl1eU=.c4437a75-cec7-409b-9219-2f31bd80938a@github.com> On Fri, 7 Jun 2024 18:29:00 GMT, Martin Fox wrote: > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. Reviewers: @kevinrushforth @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1473#issuecomment-2155669522 From duke at openjdk.org Sat Jun 8 09:13:25 2024 From: duke at openjdk.org (Glavo) Date: Sat, 8 Jun 2024 09:13:25 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v21] In-Reply-To: <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com> References: <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com> Message-ID: On Mon, 27 May 2024 09:25:24 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - ... and 85 more: https://git.openjdk.org/jfx/compare/94aa2b68...8c152c80 I also tested it on GNOME and KDE and it worked just fine, I didn?t face any issues. I have provided it to some Linux x86-64/ARM64/LoongArch64 users and they have not had any issues so far. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2155886018 From ristovaher1213 at gmail.com Sat Jun 8 19:51:49 2024 From: ristovaher1213 at gmail.com (Risto Vaher) Date: Sat, 8 Jun 2024 22:51:49 +0300 Subject: JavaFX 3D Feature request: Ability to set texture wrap mode for PhongMaterial Message-ID: Hi, sometimes it is useful to clamp texture coordinates that exceed the normal 0-1 range, however currently the default behaviour is to repeat them and there is no way to configure it. It would be useful to have a TextureWrap property in the PhongMaterial class that would have options like REPEAT, CLAMP, MIRRORED_REPEAT, but the first 2 would be enough. I am currently trying to replicate the rendering of a custom engine that clamps texture coordinates using the JavaFX 3D api however currently it doesn't seem like it's possible. Alternative would be to have some sort of a Texture class that is part of the PhongMaterial which would have that property instead, it could also have additional properties like texture filtering mode (as right now there is no way to configure that either). -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Sat Jun 8 20:00:24 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 8 Jun 2024 22:00:24 +0200 Subject: JavaFX on Windows ARM Message-ID: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> Hello there, with the latest releases of ARM hardware with Windows I just wanted to ask whether there are any plans on officially supporting JavaFX for Windows on ARM. There are also now GitHub runners for Windows and Linux that run on ARM (see https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), so things have definitely gotten easier with regards to actually realizing a CI/CD pipeline. From crschnick at xpipe.io Sat Jun 8 20:15:18 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Sat, 8 Jun 2024 22:15:18 +0200 Subject: Toolkit Window Decorations In-Reply-To: References: Message-ID: <0d224f45-12b7-4921-ae83-85b7eb157388@xpipe.io> I totally agree with the need for better decoration support. I think many JavaFX application developers would agree that one big area where JavaFX is lacking are window decorations, or the lack thereof. Nowadays there are many reasons for having better support/integration for window decorations: - On Windows, decorations are always in white, even if the system appearance is set to dark. Also if the application is displaying in dark mode while the OS is still in light (all the other way around), the window decorations also do not match up with the application style on other systems like macOS. It would be very useful to have control over the decorations color scheme. Maybe being able to bind a ColorScheme to some kind of native window decorations property would help here. - Having better custom decorations would also be helpful. Especially when looking into the future on Linux as described here - Some way to merge the native decorations with the UI as you see in many modern application nowadays would also be nice, but this is not that important as the other points in my opinion On 23/05/2024 13:16, Thiago Milczarek Say?o wrote: > Hi, > > At some point we will need "Client Side" decorations on JavaFX to > support modern gnome desktop on Linux as they moved to have client > side decorations on everything. > Mutter (the gnome compositor) does not even support "server side" > decorations. On Wayland it's an extension for KDE only. > > Currently, even on Xorg it's a bit hacky when JavaFX needs to set > total window size (with decorations). It caused too many problems. > > Having controls on the titlebar?is a nice?feature to have, as seen on > many applications (tabs, hamburger menus, buttons). > > I'm not exactly sure on how it should be done. Maybe a Scene property > that enables its contents to be wrapped in a decoration control? > Would it break applications that walk through the scene graph? > > Should it look like Modena and have a JavaFX "identity", or should it > try to look like the platform it's in? > > On Wayland, it would be possible to use a subcompositor to place the > decoration behind, but I think it would be better if the decoration > was part of the Scene. It would be less problematic on the variety of > compositors (Mutter, Kwin, Sway, etc). > > > -- Thiago > > > From johan.vos at gluonhq.com Sun Jun 9 09:51:25 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 9 Jun 2024 11:51:25 +0200 Subject: JavaFX on Windows ARM In-Reply-To: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> References: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> Message-ID: Hi Christopher, The question about Windows. AArch64 increasingly pops up. We did some local tests, and the basis modules builds out-of-the-box, but media and web modules require more work. It's definitely helpful that there are GA runners for it now -- although the GA is just a basic check. It would be good to know if someone is compiling media/webkit for Win/AArch64. - Johan On Sat, Jun 8, 2024 at 10:01?PM Christopher Schnick wrote: > Hello there, > > with the latest releases of ARM hardware with Windows I just wanted to > ask whether there are any plans on officially supporting JavaFX for > Windows on ARM. > > There are also now GitHub runners for Windows and Linux that run on ARM > (see > > https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), > > so things have definitely gotten easier with regards to actually > realizing a CI/CD pipeline. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Sun Jun 9 12:56:32 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 9 Jun 2024 12:56:32 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: References: Message-ID: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: - Merge branch 'refs/heads/master' into new_ime - Merge branch 'refs/heads/master' into new_ime - Merge branch 'master' into new_ime - Add signals to avoid warnings - Merge branch 'master' into new_ime # Conflicts: # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp - Add check for jview - - Fix comment path - - Fix double keyrelease - - Use a work-around to relative positioning (until wayland is not officially supported) - Unref pango attr list - Merge branch 'master' into new_ime - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=21 Stats: 448 lines in 7 files changed: 62 ins; 265 del; 121 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Jun 9 13:12:44 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 9 Jun 2024 13:12:44 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v14] In-Reply-To: References: Message-ID: <33srjwey90heIukzArpnKZDRLl66pHE5rzR65p7SX38=.845d578e-01a7-4c14-b077-9078aaaa0dc1@github.com> > Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'refs/heads/master' into egl - Merge branch 'refs/heads/master' into egl - Merge branch 'refs/heads/master' into egl - Use prismES2EGLX11 as build name - Merge branch 'master' into egl - Prefer EGL over GLX - Merge branch 'master' into egl - Merge branch 'master' into egl # Conflicts: # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c - Use EGL instead of GLX ------------- Changes: https://git.openjdk.org/jfx/pull/1381/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=13 Stats: 2441 lines in 36 files changed: 1857 ins; 489 del; 95 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381 From tsayao at openjdk.org Sun Jun 9 16:24:25 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 9 Jun 2024 16:24:25 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec I did an updated build of this branch [here](https://github.com/tsayao/jfx/releases/download/test-ime/jfx_23_linux_ime.zip) (for testing only). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2156686317 From nlisker at gmail.com Sun Jun 9 20:39:09 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 9 Jun 2024 23:39:09 +0300 Subject: JavaFX 3D Feature request: Ability to set texture wrap mode for PhongMaterial In-Reply-To: References: Message-ID: Hi Risto, There is some work on this already here: https://github.com/openjdk/jfx/pull/1281. I didn't have time to continue with it, so it was auto-closed. To answer your points specifically: Hi, sometimes it is useful to clamp texture coordinates that exceed the > normal 0-1 range, however currently the default behaviour is to repeat them > and there is no way to configure it. > It would be useful to have a TextureWrap property in the PhongMaterial > class that would have options like REPEAT, CLAMP, MIRRORED_REPEAT, but the > first 2 would be enough. I think you're talking about two options that are different, yet similar. There's texture addressing [1] and texture wrapping [2] (showing links for D3D). Wrapping mode is a render state and is performed before texture addressing, which is a sampler state. I am currently trying to replicate the rendering of a custom engine that > clamps texture coordinates using the JavaFX 3D api however currently it > doesn't seem like it's possible. > You might have a way of doing that with the mesh's texture coordinates. Also have a look at the FXyz library [3] and this SO question [4]. Alternative would be to have some sort of a Texture class that is part of > the PhongMaterial which would have that property instead, it could also > have additional properties like texture filtering mode (as right now there > is no way to configure that either). Texture filtering is the first thing that is implemented in the above PR. Bilinear and nearest-point are available for mag and min filters; mipmap isn't really working for reasons I couldn't determine. You can try it out; see my results from August last year [5]. The next step in that PR is figuring out what configuration options go into this class (more can be added later, and it should probably be an interface instead of a class anyway). We don't want to cram too many unrelated things into it, making it a kitchen sink class, so I suggested starting conservatively. We also need a unified API for the different current and (possible) future piplines (D3D9, D3D11, OpenGL, Metal, Vulkan), but I did some of that research already and the piplines agree rather nicely [6], so I'm more confident on that front. Specifically, finding out if render states and sampler states both belong there together because this configuration class is applied *per map* (diffuse, specular, emissive, normal), not *per material*. By the way, filtering is also a sampler state, like addressing, so at the very least addressing can be added there. - Nir [1] https://learn.microsoft.com/en-us/windows/win32/direct3d9/texture-addressing-modes [2] https://learn.microsoft.com/en-us/windows/win32/direct3d9/texture-wrapping [3] https://github.com/FXyz/FXyz [4] https://stackoverflow.com/questions/49130485/javafx-shape3d-texturing-dont-strectch-the-image [5] https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/042181.html [6] https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/042136.html On Sat, Jun 8, 2024 at 10:52?PM Risto Vaher wrote: > Hi, sometimes it is useful to clamp texture coordinates that exceed the > normal 0-1 range, however currently the default behaviour is to repeat them > and there is no way to configure it. > It would be useful to have a TextureWrap property in the PhongMaterial > class that would have options like REPEAT, CLAMP, MIRRORED_REPEAT, but the > first 2 would be enough. > I am currently trying to replicate the rendering of a custom engine that > clamps texture coordinates using the JavaFX 3D api however currently it > doesn't seem like it's possible. > > Alternative would be to have some sort of a Texture class that is part of > the PhongMaterial which would have that property instead, it could also > have additional properties like texture filtering mode (as right now there > is no way to configure that either). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Jun 9 22:15:06 2024 From: philip.race at oracle.com (Philip Race) Date: Sun, 9 Jun 2024 15:15:06 -0700 Subject: JavaFX on Windows ARM In-Reply-To: References: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> Message-ID: <26220f6b-2cda-43c0-a9f4-82e9b26c8960@oracle.com> Since we at Oracle don't have or produce Windows ARM JDK binaries, I don't see a road to anyone here being able to work on it for the forseeable future. -phil. On 6/9/24 2:51 AM, Johan Vos wrote: > Hi Christopher, > > The question about Windows. AArch64 increasingly pops up. We did some > local tests, and the basis modules builds out-of-the-box, but media > and web modules require more work. > It's definitely helpful that there are GA runners for it now -- > although the GA is just a basic check. > It would be good to know if someone is compiling media/webkit for > Win/AArch64. > > - Johan > > > On Sat, Jun 8, 2024 at 10:01?PM Christopher Schnick > wrote: > > Hello there, > > with the latest releases of ARM hardware with Windows I just > wanted to > ask whether there are any plans on officially supporting JavaFX for > Windows on ARM. > > There are also now GitHub runners for Windows and Linux that run > on ARM > (see > https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), > > so things have definitely gotten easier with regards to actually > realizing a CI/CD pipeline. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crschnick at xpipe.io Sun Jun 9 22:25:00 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Mon, 10 Jun 2024 00:25:00 +0200 Subject: JavaFX on Windows ARM In-Reply-To: <26220f6b-2cda-43c0-a9f4-82e9b26c8960@oracle.com> References: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> <26220f6b-2cda-43c0-a9f4-82e9b26c8960@oracle.com> Message-ID: <7bf11808-3284-4e1b-ab58-89f1a76590db@xpipe.io> Is there a rough timeline that you can provide from Oracle's side for this? Assuming that it even is on the horizon. Because as you rightly say, this is the primary building block that everything depends on. I also don't know what the status is for other vendors right now. On 10/06/2024 00:15, Philip Race wrote: > Since we at Oracle don't have or produce Windows ARM JDK binaries, > I don't see a road to anyone here being able to work on it for the > forseeable future. > > -phil. > > On 6/9/24 2:51 AM, Johan Vos wrote: >> Hi Christopher, >> >> The question about Windows. AArch64 increasingly pops up. We did some >> local tests, and the basis modules builds out-of-the-box, but media >> and web modules require more work. >> It's definitely helpful that there are GA runners for it now -- >> although the GA is just a basic check. >> It would be good to know if someone is compiling media/webkit for >> Win/AArch64. >> >> - Johan >> >> >> On Sat, Jun 8, 2024 at 10:01?PM Christopher Schnick >> wrote: >> >> Hello there, >> >> with the latest releases of ARM hardware with Windows I just >> wanted to >> ask whether there are any plans on officially supporting JavaFX for >> Windows on ARM. >> >> There are also now GitHub runners for Windows and Linux that run >> on ARM >> (see >> https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), >> >> so things have definitely gotten easier with regards to actually >> realizing a CI/CD pipeline. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jun 10 00:14:24 2024 From: duke at openjdk.org (=?UTF-8?B?R8OhYm9y?= =?UTF-8?B?IA==?= =?UTF-8?B?UGludMOpcg==?=) Date: Mon, 10 Jun 2024 00:14:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v21] In-Reply-To: <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com> References: <25Sx4vlpR8treQXteqIY5Y29pvbekVmxhzoa5c5ojLE=.bab9f182-6c73-4460-80c9-ed5c7dfe50bc@github.com> Message-ID: On Mon, 27 May 2024 09:25:24 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - ... and 85 more: https://git.openjdk.org/jfx/compare/94aa2b68...8c152c80 IME user here for Japanese. Thanks for this improvement. I am eager to try it with Japanese on Ubuntu 24.04/ibus/mozc. JavaFx with Gtk3 seems to be unaware of any mozc IME activity - while Gtk2 works. Is building the `new_ime` branch the only way to try it? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2156383318 From duke at openjdk.org Mon Jun 10 00:31:24 2024 From: duke at openjdk.org (=?UTF-8?B?R8OhYm9y?= =?UTF-8?B?IA==?= =?UTF-8?B?UGludMOpcg==?=) Date: Mon, 10 Jun 2024 00:31:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec Much appreciated! I quick test with Japanese on Xubuntu 24.04/ibus/mozc. - `TextArea` -> works out of the box - `TextFieldTableCell` -> a bit buggy - if this is the first widget to input text -> does not detect input method change, cannot trigger `A-> ?` - if starting with `TextArea`, performing input method change, _then_ edit `TextFieldTableCell` -> works as expected: can switch `A<->?` My `TextFieldTableCell` uses the `DefaultStringConverter`, which may affect the behavior. Later I will check with other `StringConverter` classes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2156925867 From zjx001202 at gmail.com Mon Jun 10 01:17:13 2024 From: zjx001202 at gmail.com (Glavo) Date: Mon, 10 Jun 2024 09:17:13 +0800 Subject: JavaFX on Windows ARM In-Reply-To: <7bf11808-3284-4e1b-ab58-89f1a76590db@xpipe.io> References: <506677ae-53b6-4199-8992-523dcd83a9e1@xpipe.io> <26220f6b-2cda-43c0-a9f4-82e9b26c8960@oracle.com> <7bf11808-3284-4e1b-ab58-89f1a76590db@xpipe.io> Message-ID: As far as I know, BellSoft provides OpenJDK and OpenJFX builds for Windows on ARM[1]. But like Johan said, the media and web modules are not available yet. Maybe they are interested in this. Glavo [1]: https://bell-sw.com/pages/downloads/?os=windows&architecture=arm&package=jdk-full On Mon, Jun 10, 2024 at 6:25?AM Christopher Schnick wrote: > Is there a rough timeline that you can provide from Oracle's side for > this? Assuming that it even is on the horizon. > > Because as you rightly say, this is the primary building block that > everything depends on. I also don't know what the status is for other > vendors right now. > On 10/06/2024 00:15, Philip Race wrote: > > Since we at Oracle don't have or produce Windows ARM JDK binaries, > I don't see a road to anyone here being able to work on it for the > forseeable future. > > -phil. > > On 6/9/24 2:51 AM, Johan Vos wrote: > > Hi Christopher, > > The question about Windows. AArch64 increasingly pops up. We did some > local tests, and the basis modules builds out-of-the-box, but media and web > modules require more work. > It's definitely helpful that there are GA runners for it now -- although > the GA is just a basic check. > It would be good to know if someone is compiling media/webkit for > Win/AArch64. > > - Johan > > > On Sat, Jun 8, 2024 at 10:01?PM Christopher Schnick > wrote: > >> Hello there, >> >> with the latest releases of ARM hardware with Windows I just wanted to >> ask whether there are any plans on officially supporting JavaFX for >> Windows on ARM. >> >> There are also now GitHub runners for Windows and Linux that run on ARM >> (see >> >> https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), >> >> so things have definitely gotten easier with regards to actually >> realizing a CI/CD pipeline. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Jun 10 13:19:21 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 10 Jun 2024 13:19:21 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 Reviewers: @arapte @lukostyra ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2158358540 From angorya at openjdk.org Mon Jun 10 15:03:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jun 2024 15:03:21 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v13] In-Reply-To: <2GY47oVE9mCl0FLEyRr8FvMsZVR1z7Jp5K45vCTx668=.463f1350-f524-4e14-87f9-618c2c1b6463@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> <2GY47oVE9mCl0FLEyRr8FvMsZVR1z7Jp5K45vCTx668=.463f1350-f524-4e14-87f9-618c2c1b6463@github.com> Message-ID: On Fri, 12 Apr 2024 22:47:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - tolerance > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - undo merge > - ... and 22 more: https://git.openjdk.org/jfx/compare/44d53baf...197cfaf0 keep alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2158600774 From angorya at openjdk.org Mon Jun 10 15:06:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 10 Jun 2024 15:06:30 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v14] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - Merge remote-tracking branch 'origin/master' into 8299753.resize - ... and 23 more: https://git.openjdk.org/jfx/compare/c8b96e4e...b9a105ee ------------- Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=13 Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From mark.reinhold at oracle.com Tue Jun 11 15:26:01 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 11 Jun 2024 15:26:01 +0000 Subject: Result: New OpenJFX Reviewer: John Hendrikx In-Reply-To: <72eda936-db09-4043-83b8-bbf7dfd8c648@oracle.com> References: <72eda936-db09-4043-83b8-bbf7dfd8c648@oracle.com> Message-ID: <20240611112600.990659872@eggemoggin.niobe.net> 2024/6/7 8:10:20 -0400, kevin.rushforth at oracle.com: > Voting for John Hendrikx [1] to OpenJFX Reviewer [2] is now closed. > > Yes: 6 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. So recorded. - Mark From kcr at openjdk.org Tue Jun 11 22:44:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jun 2024 22:44:27 GMT Subject: RFR: 8311895: CSS Transitions [v23] In-Reply-To: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> References: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> Message-ID: <50k2Qy5ekecNKCveuQC26lD9FeuybMXQMRPlkvItJ8E=.74b976cf-35a6-479c-a107-3cee56be1849@github.com> On Wed, 5 Jun 2024 21:59:13 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). >> >> ### Future enhancements >> CSS transition support for backgrounds and borders: #1471 >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > link to easing function images in scene I've finished testing and reviewing the code. All looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2111570661 From kcr at openjdk.org Tue Jun 11 22:44:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 11 Jun 2024 22:44:28 GMT Subject: RFR: 8311895: CSS Transitions [v20] In-Reply-To: References: Message-ID: On Sun, 26 May 2024 11:26:50 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> documentation change > > I think the CSR needs updating. @nlisker @drmarmac Can you re-review (there have only been minor changes since you approved) ------------- PR Comment: https://git.openjdk.org/jfx/pull/870#issuecomment-2161719306 From nlisker at openjdk.org Tue Jun 11 22:52:26 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 11 Jun 2024 22:52:26 GMT Subject: RFR: 8311895: CSS Transitions [v23] In-Reply-To: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> References: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> Message-ID: <3GKRq-j8jbV_qUKcNTDFDzeZm7dk91gvRi6Hvm8JSzc=.6949c9b9-09c1-4c6c-b10e-2f98acff2471@github.com> On Wed, 5 Jun 2024 21:59:13 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). >> >> ### Future enhancements >> CSS transition support for backgrounds and borders: #1471 >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > link to easing function images in scene Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2111578408 From mmack at openjdk.org Wed Jun 12 07:34:31 2024 From: mmack at openjdk.org (Markus Mack) Date: Wed, 12 Jun 2024 07:34:31 GMT Subject: RFR: 8311895: CSS Transitions [v23] In-Reply-To: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> References: <6B3iwuFURj0HdrASNsB2srKdS3vDYm-VKWfwqvKkVQ0=.58a739f3-c2b6-4138-aeb3-6b363b48d27c@github.com> Message-ID: On Wed, 5 Jun 2024 21:59:13 GMT, Michael Strau? wrote: >> Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). >> >> ### Future enhancements >> CSS transition support for backgrounds and borders: #1471 >> >> ### Limitations >> This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: >> >> .button { >> transition: -fx-background-color 1s; >> transition-easing-function: linear; >> } >> >> This issue should be addressed in a follow-up enhancement. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > link to easing function images in scene Marked as reviewed by mmack (Author). ------------- PR Review: https://git.openjdk.org/jfx/pull/870#pullrequestreview-2112189009 From kcr at openjdk.org Wed Jun 12 12:06:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jun 2024 12:06:23 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:15:56 GMT, Martin Fox wrote: > JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. @andy-goryachev-oracle Can you review this? It looks like a straight-forward fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1470#issuecomment-2162838363 From kcr at openjdk.org Wed Jun 12 12:27:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jun 2024 12:27:22 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 17:51:58 GMT, Andy Goryachev wrote: > should this PR be closed in favor of #1462 ? Either that, or else moved to Draft while #1462 is being reviewed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-2162878296 From angorya at openjdk.org Wed Jun 12 14:40:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Jun 2024 14:40:18 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:15:56 GMT, Martin Fox wrote: > JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. will do ------------- PR Comment: https://git.openjdk.org/jfx/pull/1470#issuecomment-2163184641 From angorya at openjdk.org Wed Jun 12 15:09:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 12 Jun 2024 15:09:20 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:15:56 GMT, Martin Fox wrote: > JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. Looks good on macOS 14.5 M1. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1470#pullrequestreview-2113335438 From jvos at openjdk.org Wed Jun 12 17:50:21 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 12 Jun 2024 17:50:21 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 09:20:12 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> process reviewers comments > > About adding an automated test, the leak that PR tries to fix happens in `com.sun.javafx.tk.quantum.GlassSystemMenu`, which is package private, and adding new tests to check `javafx.scene.control.Menu`, or related public classes, won't catch that leak, will it? > > Unless we open it (and all the related classes/methods in `com.sun.glass.ui.*`), I don't think it can be done? @jperedadnr @hjohn can you review this? @kevinrushforth feel free to add other reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-2163597794 From kcr at openjdk.org Wed Jun 12 20:09:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jun 2024 20:09:29 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor Message-ID: This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" * `TOOL_LINT` - used when compiling tool tasks : default = "" * `TEST_LINT` - used when compiling test tasks : default = "" Each property takes a string with a comma-separated list of lint options. For example: gradle -PLINT="deprecation,removal" sdk I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. ------------- Commit messages: - 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods - 8334143: Suppress remaining removal warnings for internal methods and classes - 8327255: javac lint warnings: removal, missing-explicit-ctor Changes: https://git.openjdk.org/jfx/pull/1474/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1474&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327255 Stats: 113 lines in 13 files changed: 101 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1474.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1474/head:pull/1474 PR: https://git.openjdk.org/jfx/pull/1474 From kcr at openjdk.org Wed Jun 12 20:09:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 12 Jun 2024 20:09:29 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor In-Reply-To: References: Message-ID: <6UvXkbVmu6MzWYHkq7D9DX8SZ9R2V3Wkv3Ob8wF6PXQ=.dece812f-ec03-49fd-8f41-8c46ef1f0f47@github.com> On Wed, 12 Jun 2024 20:03:24 GMT, Kevin Rushforth wrote: > This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. > > We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: > > * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" > * `TOOL_LINT` - used when compiling tool tasks : default = "" > * `TEST_LINT` - used when compiling test tasks : default = "" > > Each property takes a string with a comma-separated list of lint options. For example: > > > gradle -PLINT="deprecation,removal" sdk > > > I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. > > While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. > > I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. With the addition of the fixes for JDK-8334143 and JDK-8334138 we are lint clean for removal. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1474#issuecomment-2163807534 From jhendrikx at openjdk.org Thu Jun 13 07:24:26 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 13 Jun 2024 07:24:26 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 19:48:19 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add more type info The new test passed with both the old and the new version (I reverted the code, aside from leaving `setMenuBindings` `protected`). Is the test testing the right thing? (If relevant, this was done on a Windows platform) tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 287: > 285: > 286: @Test > 287: public void testJDK8309935() { minor: Not sure what our policies are, but I find test names like this pretty useless, perhaps a short indication what this is doing? tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 346: > 344: }); > 345: Util.runAndWait(() -> { > 346: }); I checked the code that `runAndWait` would do when you pass in 0 runnables, and it basically does no waiting at all (less than a microsecond for sure). If this is really essential (I removed it and the test still passed) then I think a `sleep` might be better. ------------- Changes requested by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2114917800 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1637684395 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1637687030 From duke at openjdk.org Thu Jun 13 07:49:25 2024 From: duke at openjdk.org (leewyatt) Date: Thu, 13 Jun 2024 07:49:25 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 16:21:50 GMT, Thiago Milczarek Sayao wrote: > I did an updated build of this branch [here](https://github.com/tsayao/jfx/releases/download/test-ime/jfx_23_linux_ime.zip) (for testing only). Wow, thank you. I have downloaded it and will test it as soon as possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2164875426 From jpereda at openjdk.org Thu Jun 13 10:48:23 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 13 Jun 2024 10:48:23 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: On Thu, 9 May 2024 19:48:19 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add more type info I've tested on macOS, and tests pass now, and fail without the changes from this PR. I've left some comments, but once addressed, I'll re-approve. modules/javafx.graphics/src/shims/java/com/sun/javafx/tk/quantum/GlassSystemMenuShim.java line 37: > 35: > 36: private GlassSystemMenu gsm; > 37: final ArrayList> uncollectedMenus = new ArrayList<>(); this can be private? modules/javafx.graphics/src/shims/java/com/sun/javafx/tk/quantum/GlassSystemMenuShim.java line 54: > 52: protected void setMenuBindings(final Menu glassMenu, final MenuBase mb) { > 53: super.setMenuBindings(glassMenu, mb); > 54: uncollectedMenus.add(new WeakReference(glassMenu)); Add `<>` to avoid raw use of `WeakReference` tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 289: > 287: public void testJDK8309935() { > 288: MenuBar menuBar = new MenuBar(); > 289: AtomicReference throwableRef = new AtomicReference(); Add missing `<>` to avoid raw use of `AtomicReference` ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2115396776 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1637974242 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1637973453 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1637980139 From kcr at openjdk.org Thu Jun 13 11:49:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 13 Jun 2024 11:49:22 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 07:21:47 GMT, John Hendrikx wrote: > The new test passed with both the old and the new version (I reverted the code, aside from leaving `setMenuBindings` `protected`). Is the test testing the right thing? > > (If relevant, this was done on a Windows platform) That's not surprising since only macOS provides the (optional) system menu capability, and the leak is in the glass system menu implementation. The tests will pass vacuously on other platforms, since the system menu code with the bug will never be reached. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-2165425472 From mstrauss at openjdk.org Thu Jun 13 19:20:26 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 Jun 2024 19:20:26 GMT Subject: Integrated: 8311895: CSS Transitions In-Reply-To: References: Message-ID: <9JG4ZWgYWUhYEoJy1YnWPAN-I7hAZ4-rpD-ErDxZqgE=.ef66b4b1-07be-44f1-b9c2-29e3f0aadb97@github.com> On Tue, 16 Aug 2022 03:01:23 GMT, Michael Strau? wrote: > Implementation of [CSS Transitions](https://www.w3.org/TR/css-transitions-1/). > > ### Future enhancements > CSS transition support for backgrounds and borders: #1471 > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. This pull request has now been integrated. Changeset: 762f5902 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/762f5902cdd2e6297996baf24f7a3e3ee8e26560 Stats: 4698 lines in 43 files changed: 4655 ins; 4 del; 39 mod 8311895: CSS Transitions Reviewed-by: mmack, nlisker, kcr ------------- PR: https://git.openjdk.org/jfx/pull/870 From openjdk at laurinmurer.ch Thu Jun 13 19:31:09 2024 From: openjdk at laurinmurer.ch (Laurin Murer) Date: Thu, 13 Jun 2024 21:31:09 +0200 Subject: 8289521: Publication to Apple App Store still not possible with JavaFX web 21 In-Reply-To: References: <68F4C308-4FA2-43A8-B791-F80D333FB6E6@laurinmurer.ch> <130387E8-B4F6-478B-9136-E5ECF13E7CEF@gmail.com> <3FAEE9C1-5B9D-461D-9192-19002111559B@gmail.com> <87CF02DC-2C8F-4508-BA70-6BC4E7879777@gmail.com> Message-ID: <572BC37C-19D8-48A5-BEBB-C798EA2A810B@laurinmurer.ch> Yes, it sounds like the method cache_simulate_memory_warning_event was never public (at least I couldn?t find any documentation about it) and Apple started to enforce its removal. As far as I can tell, a user of JavaFX web cannot fix this and has currently no chance of publishing a (new?) app to Apples App Store. For a bit of context, this call is inside the method MemoryPressureHandler::platformReleaseMemory which is implemented differently on different platforms: - cocoa (Mac): with the discussed method - generic: does nothing (empty implementation) - unix: calls `malloc_trim(0);` - win: does nothing (empty implementation) The currently only solution is the one of Michael Hall to add a compiler directive similar to one which was there before 2016-12-14 and no-oped it for certain platforms/versions. I guess this idea would fix the problem of submitting it to Apples App Store. Does anyone have another idea or is willing to bring this idea forward? > On 7 Jun 2024, at 17:48, Michael Hall wrote: > > Sorry, I did a little more digging on this. > > My best guess is that Apple is rejecting this because they think you are using a non-public API of their own. > > The OpenJFX version of MemoryPressureHandlerCocoa.mm matches what appears to be the current WebKit version. [1] > > Older versions appear somewhat different. Including this? > > #if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED >= 101000 > > [2][3] > > [3] seems to show where this code was actually introduced with the above included. > > It might be that for a Cocoa version it was thought that this compiler directive wasn?t needed but it actually still is? > Anyhow, adding something similar now might achieve a no-op that would get past them flagging this as an error. > ?locate? on my machine doesn?t seem to show the libcache.dylib mentioned anywhere other than Xcode and other developer locations. > > [1] https://github.com/WebKit/webkit/blob/main/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm > [2] https://opensource.apple.com/source/WebCore/WebCore-7601.5.17/platform/cocoa/MemoryPressureHandlerCocoa.mm.auto.html > [3] https://fossies.org/diffs/WebKit/r174650_vs_r189384/Source/WebCore/platform/cocoa/MemoryPressureHandlerCocoa.mm-diff.html > >> On Jun 6, 2024, at 6:41?PM, Michael Hall wrote: >> >> Odd, but searching shows this used in a different places and nowhere does it appear anyone has made any changes to the symbol referencing code. >> It seems like some applications should of used this same code as-is. >> Sort of strange. >> I?m done with what digging I think I?m going to do. >> >> GL. > From jvos at openjdk.org Thu Jun 13 19:54:46 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 13 Jun 2024 19:54:46 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v17] In-Reply-To: References: Message-ID: <6nQrs1MIcgujl9ZoTN7sZcQkJ5UcJDWD2Wxd8n-TlbU=.279283d7-068b-43f5-a3e1-901f5c5cbdba@github.com> > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into 8319779-systemmenu - Add more type info - Add type info Fix issue where notifications are missed when a new property is used. - Merge branch 'master' into 8319779-systemmenu - Remove whiteline and language error - Ignore test in case the underlying GlassSystemMenu is not supported. - Update modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java Co-authored-by: John Hendrikx - Merge branch 'master' into 8319779-systemmenu - Add additional test for IOOBE detection. This test comes from JDK-8323787 - Revert some of the conditional bindings. Clear menu construction when an menuitem that is a menu needs to be removed Add a test for the latter - ... and 8 more: https://git.openjdk.org/jfx/compare/762f5902...5c733838 ------------- Changes: https://git.openjdk.org/jfx/pull/1283/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=16 Stats: 663 lines in 5 files changed: 462 ins; 192 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Thu Jun 13 20:07:32 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 13 Jun 2024 20:07:32 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with two additional commits since the last revision: - process more reviewer comments - Process reviewer comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/5c733838..328ad6db Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=17 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=16-17 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Thu Jun 13 20:07:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 13 Jun 2024 20:07:33 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: <2K2th__uIhFwrrR342OiB7f1CsXgDf0q3vJsE15PmRM=.ba6713bd-f941-4c49-bc9c-b629bd9dcd0d@github.com> On Thu, 13 Jun 2024 10:25:15 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more type info > > modules/javafx.graphics/src/shims/java/com/sun/javafx/tk/quantum/GlassSystemMenuShim.java line 37: > >> 35: >> 36: private GlassSystemMenu gsm; >> 37: final ArrayList> uncollectedMenus = new ArrayList<>(); > > this can be private? done > modules/javafx.graphics/src/shims/java/com/sun/javafx/tk/quantum/GlassSystemMenuShim.java line 54: > >> 52: protected void setMenuBindings(final Menu glassMenu, final MenuBase mb) { >> 53: super.setMenuBindings(glassMenu, mb); >> 54: uncollectedMenus.add(new WeakReference(glassMenu)); > > Add `<>` to avoid raw use of `WeakReference` done > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 289: > >> 287: public void testJDK8309935() { >> 288: MenuBar menuBar = new MenuBar(); >> 289: AtomicReference throwableRef = new AtomicReference(); > > Add missing `<>` to avoid raw use of `AtomicReference` done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1638809325 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1638809211 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1638809871 From jvos at openjdk.org Thu Jun 13 20:07:32 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 13 Jun 2024 20:07:32 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v2] In-Reply-To: References: Message-ID: <_zKLmZkFufeMFPO0D9u3VyoNy3cYdJAIeElfB-wlOHA=.cdf876ba-50bb-4677-9d7f-ec912196c50b@github.com> On Tue, 12 Dec 2023 07:05:49 GMT, Ambarish Rapte wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> process reviewers comments > > Looks all good to me. > Is it possible to add an automated test ? @arapte if possible, can you re-review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1283#issuecomment-2166671943 From jpereda at openjdk.org Thu Jun 13 23:24:20 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 13 Jun 2024 23:24:20 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 20:07:32 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with two additional commits since the last revision: > > - process more reviewer comments > - Process reviewer comments Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2117171377 From kcr at openjdk.org Fri Jun 14 15:57:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jun 2024 15:57:23 GMT Subject: RFR: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 19:01:21 GMT, Martin Fox wrote: >> Which key is it that causes this? There is a ticket https://bugs.openjdk.org/browse/JDK-8090319 that suggests completing the missing key codes is also an option. > >> Which key is it that causes this? There is a ticket https://bugs.openjdk.org/browse/JDK-8090319 that suggests completing the missing key codes is also an option. > > The original bug report was for letter keys on layouts that don't generate Latin characters like Russian or Greek. On Windows AWT handles these keys by assigning a Latin key code (so shortcuts like Ctrl-A continue to work) and separately providing an extended key code based on the Unicode value. On Mac AWT is dropping the ball by not providing a Latin key code. @beldenfox I think this is ready for you to integrate; it is a simple enough change that a single reviewer is enough. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1470#issuecomment-2168317449 From kcr at openjdk.org Fri Jun 14 15:57:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 14 Jun 2024 15:57:25 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor In-Reply-To: References: Message-ID: <46UBcL-z_GMi4lyoASdeK6u6pApbPgxqDmZIf45hLiE=.1d881d2c-9251-4a10-8048-bb1364483bb5@github.com> On Wed, 12 Jun 2024 20:03:24 GMT, Kevin Rushforth wrote: > This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. > > We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: > > * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" > * `TOOL_LINT` - used when compiling tool tasks : default = "" > * `TEST_LINT` - used when compiling test tasks : default = "" > > Each property takes a string with a comma-separated list of lint options. For example: > > > gradle -PLINT="deprecation,removal" sdk > > > I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. > > While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. > > I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. @arapte Can you be the primary reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1474#issuecomment-2168316283 From mfox at openjdk.org Fri Jun 14 17:34:21 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 14 Jun 2024 17:34:21 GMT Subject: Integrated: 8324232: KeyEvent.getCode() is null inside JFXPanel In-Reply-To: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> References: <8TpERSQ2BIqTRiT8Bms6lvuBr4uT6E69M8NfHPPoFx8=.cf2a7bcd-5a4f-40fc-a47f-afbbffeedc11@github.com> Message-ID: On Sat, 1 Jun 2024 18:15:56 GMT, Martin Fox wrote: > JavaFX uses a table to map from an AWT integer key code to a JavaFX KeyCode. If AWT provides a code that's not in the table JavaFX attempts to use a KeyCode of null when constructing the KeyEvent which raises an exception. This PR just checks for null and changes it to KeyCode.UNDEFINED. This pull request has now been integrated. Changeset: 14cd9806 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/14cd9806eab87954f998aab33c8b2529e34924d6 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod 8324232: KeyEvent.getCode() is null inside JFXPanel Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1470 From duke at openjdk.org Mon Jun 17 07:17:23 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 17 Jun 2024 07:17:23 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` keep alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2172471168 From duke at openjdk.org Mon Jun 17 07:17:24 2024 From: duke at openjdk.org (eduardsdv) Date: Mon, 17 Jun 2024 07:17:24 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8322619: Add test > - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" > > This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. keep alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2172471620 From angorya at openjdk.org Mon Jun 17 17:56:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 17:56:26 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec I am testing with an unorthodox linux setup: linux mint on mac book pro `Linux OraMac 5.15.0-107-generic #117-Ubuntu SMP Fri Apr 26 12:26:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux` I have Japanese input method support installed (Input Method Framework: fcitx, input method Mozc) I can switch to Japanese IME in the native Text Editor, and I can invoke the IME in a TextArea when running the Monkey Tester. I cannot invoke Japanese IME or in fact switch to another input language if I am inside an editable TableView in the Monkey Tester. Starting with the "us" selection in the tray, even if I right click on that icon in the tray and change the input method it goes back to the "us". Space-Space (the key sequence used to toggle input language in my setup) does not work, and Ctrl-Space which brings up the Japanes IME does not work either. See nothing in the console. I might be doing something wrong, of course, since this is not an environment I typically work with. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2173996625 From angorya at openjdk.org Mon Jun 17 18:56:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 18:56:56 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 Initial comments: 1. the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR 2. the description in JDK-8332222 is insufficient: missing steps to reproduce, expected, and observed behavior. Please update both PR and the ticket(s). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174206604 From angorya at openjdk.org Mon Jun 17 19:53:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 19:53:17 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 Question. I see different behavior between macOS and linux mint with the attached program (unmodified master branch). On mac, the alert window is always positioned at the upper left corner, while on linux it is correctly placed at the center of the screen. Is this expected? Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner. Unless we move the main window to another monitor. In that case I can see a number of differences: 1. main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located 2. when main window is "maximized" to full screen, both screens go into full screen mode, one (secondary) with the main window, the other (primary) with a black background. an alert pops up on the primary screen (i.e. other than the screen with the main window), but this time it is correctly positioned at the center of the primary screen. I feel this behavior (on mac) is unexpected. Any ideas? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174303188 From angorya at openjdk.org Mon Jun 17 20:14:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 20:14:22 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 on linux mint, the positioning of the alert window in the case of two screens is the same as on mac, so it looks like it works "as designed". ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174336677 From kcr at openjdk.org Mon Jun 17 20:14:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 17 Jun 2024 20:14:23 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 If there are bugs on macOS, then I'd file a separate bug, since this bug is only about Linux behavior. > Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner. There is a maximized state on macOS. You can enter/exit maximized state programmatically, or by double-clicking on the title bar. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174338290 From thiago.sayao at gmail.com Mon Jun 17 20:46:54 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 17 Jun 2024 17:46:54 -0300 Subject: Platform diferences In-Reply-To: References: Message-ID: I'm forwarding here since it's unrelated to the specific issue. The existing behavior on Linux is to center the windows. I think we should let the window manager decide and don't touch the initial position (unless the user sets it). On mutter, for example, there's an option to automatically center the windows. There's also an option to automatically maximize windows near screen size (and we probably break it). There's also window managers like i3 on which making effort to center the windows are pointless since it's a tiling wm. We should let some platform details be different, I think. -- Thiago ---------- Forwarded message --------- De: Andy Goryachev Date: seg., 17 de jun. de 2024 ?s 16:51 Subject: Re: [openjdk/jfx] 8332222: Linux Debian: Maximized stage shrinks when opening another stage (PR #1460) To: openjdk/jfx Cc: Thiago Milczarek Say?o , Mention < mention at noreply.github.com> Question. I see different behavior between macOS and linux mint with the attached program (unmodified master branch). On mac, the alert window is always positioned at the upper left corner, while on linux it is correctly placed at the center of the screen. Is this expected? Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner. Unless we move the main window to another monitor. In that case I can see a number of differences: 1. main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located 2. when main window is "maximized" to full screen, both screens go into full screen mode, one (secondary) with the main window, the other (primary) with a black background. an alert pops up on the primary screen (i.e. other than the screen with the main window), but this time it is correctly positioned at the center of the primary screen. I feel this behavior (on mac) is unexpected. Any ideas? ? Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you were mentioned.Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Jun 17 20:50:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 20:50:17 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 I don't see any difference with or without this fix on linux mint (I think it's running its own desktop env., different from KDE - how can I tell?). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174394648 From andy.goryachev at oracle.com Mon Jun 17 20:52:19 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 17 Jun 2024 20:52:19 +0000 Subject: Platform diferences In-Reply-To: References: Message-ID: Thank you for clarification. I guess the only problem I see (and which applies to both mac and linux) is that the alert window appears on the wrong monitor - I would expect it to appear on the same monitor where the main window is positioned. -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Monday, June 17, 2024 at 13:47 To: openjfx-dev Subject: Platform diferences I'm forwarding here since it's unrelated to the specific issue. The existing behavior on Linux is to center the windows. I think we should let the window manager decide and don't touch the initial position (unless the user sets it). On mutter, for example, there's an option to automatically center the windows. There's also an option to automatically maximize windows near screen size (and we probably break it). There's also window managers like i3 on which making effort to center the windows are pointless since it's a tiling wm. We should let some platform details be different, I think. -- Thiago ---------- Forwarded message --------- De: Andy Goryachev > Date: seg., 17 de jun. de 2024 ?s 16:51 Subject: Re: [openjdk/jfx] 8332222: Linux Debian: Maximized stage shrinks when opening another stage (PR #1460) To: openjdk/jfx > Cc: Thiago Milczarek Say?o >, Mention > Question. I see different behavior between macOS and linux mint with the attached program (unmodified master branch). On mac, the alert window is always positioned at the upper left corner, while on linux it is correctly placed at the center of the screen. Is this expected? Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner. Unless we move the main window to another monitor. In that case I can see a number of differences: 1. main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located 2. when main window is "maximized" to full screen, both screens go into full screen mode, one (secondary) with the main window, the other (primary) with a black background. an alert pops up on the primary screen (i.e. other than the screen with the main window), but this time it is correctly positioned at the center of the primary screen. I feel this behavior (on mac) is unexpected. Any ideas? ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsayao at openjdk.org Mon Jun 17 21:22:15 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 17 Jun 2024 21:22:15 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 The issue 8332222 is KDE specific. When a `MODAL` or `APPLICATION_MODAL` window pops, all chindren (or all other windows in case of `APPLICATION_MODAL` are disabled. And part of de "disabling" is to not allow the window to be resized, so `update_window_constraints` "freezes" the window size. In the KDE case the window manager probably does not check if the window is maximized and ignores it as gnome does. The fix is around the `is_floating` check - it checks if the window is "floating" on the screen and just constraint the sizes if it is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174443819 From tsayao at openjdk.org Mon Jun 17 21:34:17 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 17 Jun 2024 21:34:17 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Mon, 17 Jun 2024 18:54:15 GMT, Andy Goryachev wrote: > Initial comments: > > 1. the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR > 2. the description in JDK-8332222 is insufficient: missing steps to reproduce, expected, and observed behavior. > > Please update both PR and the ticket(s). @andy-goryachev-oracle Thanks for looking at Linux issues :) 1. No, the wrong behaviour of positioning was observed while trying to resolve the original issue on which this PR is linked. I don't know if someone reported it. 2. I think @jperedadnr opened it directly, so it didn't go through the user problem reporting process. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174462509 From kevin.rushforth at oracle.com Mon Jun 17 22:02:06 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Jun 2024 15:02:06 -0700 Subject: Platform diferences In-Reply-To: References: Message-ID: Positioning of Windows, among other window system interactions, is inherently platform specific. We added language, primarily in support of Wayland, to clarify this, but I can easily imagine other windowing environments where this is also true. We should try for consistency where possible, but recognize that some things are under control of the system. -- Kevin On 6/17/2024 1:46 PM, Thiago Milczarek Say?o wrote: > I'm forwarding here since it's unrelated to the specific issue. > > The existing behavior on Linux is to center the windows. I think we > should let the window manager decide and don't touch the initial > position (unless the user sets it). > > On mutter, for example, there's an option to automatically?center the > windows. There's also an option to automatically maximize windows near > screen size (and we probably?break it). > > There's also window managers like i3 on which making effort to center > the windows are pointless since it's a tiling wm. > > We should let some platform details be different, I think. > > -- Thiago > > ---------- Forwarded message --------- > De: *Andy Goryachev* > Date: seg., 17 de jun. de 2024 ?s 16:51 > Subject: Re: [openjdk/jfx] 8332222: Linux Debian: Maximized stage > shrinks when opening another stage (PR #1460) > To: openjdk/jfx > Cc: Thiago Milczarek Say?o , Mention > > > > Question. I see different behavior between macOS and linux mint with > the attached program (unmodified master branch). > > On mac, the alert window is always positioned at the upper left > corner, while on linux it is correctly placed at the center of the > screen. Is this expected? > > Also on mac, as I understand it, there is no "maximized" state, only > full screen. So when the alert window comes up, the main window slides > out of view and all we see is the black screen and alert widow at the > upper left corner. > > Unless we move the main window to another monitor. In that case I can > see a number of differences: > > 1. main window in normal state, the alert comes up on a primary > screen and not on the screen where the main window is located > 2. when main window is "maximized" to full screen, both screens go > into full screen mode, one (secondary) with the main window, the > other (primary) with a black background. an alert pops up on the > primary screen (i.e. other than the screen with the main window), > but this time it is correctly positioned at the center of the > primary screen. > > I feel this behavior (on mac) is unexpected. Any ideas? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > . > You are receiving this because you were mentioned.Message ID: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Jun 17 22:08:33 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Jun 2024 15:08:33 -0700 Subject: Platform diferences In-Reply-To: References: Message-ID: If it only misbehaves on multi-screen, then that's almost certainly a separate issue. -- Kevin On 6/17/2024 1:52 PM, Andy Goryachev wrote: > > Thank you for clarification. > > I guess the only problem I see (and which applies to both mac and > linux) is that the alert window appears on the wrong monitor - I would > expect it to appear on the same monitor where the main window is > positioned. > > -andy > > *From: *openjfx-dev on behalf of Thiago > Milczarek Say?o > *Date: *Monday, June 17, 2024 at 13:47 > *To: *openjfx-dev > *Subject: *Platform diferences > > I'm forwarding here since it's unrelated to the specific issue. > > The existing behavior on Linux is to center the windows. I think we > should let the window manager decide and don't touch the initial > position (unless the user sets it). > > On mutter, for example, there's an option to automatically?center the > windows. There's also an option to automatically maximize windows near > screen size (and we probably?break it). > > There's also window managers like i3 on which making effort to center > the windows are pointless since it's a tiling wm. > > We should let some platform details be different, I think. > > -- Thiago > > ---------- Forwarded message --------- > De: *Andy Goryachev* > Date: seg., 17 de jun. de 2024 ?s 16:51 > Subject: Re: [openjdk/jfx] 8332222: Linux Debian: Maximized stage > shrinks when opening another stage (PR #1460) > To: openjdk/jfx > Cc: Thiago Milczarek Say?o , Mention > > > Question. I see different behavior between macOS and linux mint with > the attached program (unmodified master branch). > > On mac, the alert window is always positioned at the upper left > corner, while on linux it is correctly placed at the center of the > screen. Is this expected? > > Also on mac, as I understand it, there is no "maximized" state, only > full screen. So when the alert window comes up, the main window slides > out of view and all we see is the black screen and alert widow at the > upper left corner. > > Unless we move the main window to another monitor. In that case I can > see a number of differences: > > 1. main window in normal state, the alert comes up on a primary > screen and not on the screen where the main window is located > 2. when main window is "maximized" to full screen, both screens go > into full screen mode, one (secondary) with the main window, the > other (primary) with a black background. an alert pops up on the > primary screen (i.e. other than the screen with the main window), > but this time it is correctly positioned at the center of the > primary screen. > > I feel this behavior (on mac) is unexpected. Any ideas? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > . > You are receiving this because you were mentioned.Image removed by > sender.Message ID: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Jun 17 23:36:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 17 Jun 2024 23:36:17 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: <1-YbjEbYGAi7_eRcvoM55xZoTeqaCdEqHRwlpCHCseQ=.f738d11c-0d95-4851-bf36-9fe43ff41bcf@github.com> On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao 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 seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 I've tested a bit more on linux mint (not a KDE desktop), see no ill effects. There were a couple of warnings opening modal and regular windows, but the same warnings are present in the master branch. For completeness sake, here they are: Color picker -> custom color -> use? `(java:64981): Gtk-CRITICAL **: 15:36:07.237: gtk_window_resize: assertion 'width > 0' failed` tools -> FxTextArea Embedded in JFXPanel `(java:64981): Gdk-WARNING **: 15:37:06.136: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2174623232 From andy.goryachev at oracle.com Mon Jun 17 23:36:43 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 17 Jun 2024 23:36:43 +0000 Subject: Platform diferences In-Reply-To: References: Message-ID: definitely a separate issue. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Monday, June 17, 2024 at 15:09 To: openjfx-dev at openjdk.org Subject: Re: Platform diferences If it only misbehaves on multi-screen, then that's almost certainly a separate issue. -- Kevin On 6/17/2024 1:52 PM, Andy Goryachev wrote: Thank you for clarification. I guess the only problem I see (and which applies to both mac and linux) is that the alert window appears on the wrong monitor - I would expect it to appear on the same monitor where the main window is positioned. -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Monday, June 17, 2024 at 13:47 To: openjfx-dev Subject: Platform diferences I'm forwarding here since it's unrelated to the specific issue. The existing behavior on Linux is to center the windows. I think we should let the window manager decide and don't touch the initial position (unless the user sets it). On mutter, for example, there's an option to automatically center the windows. There's also an option to automatically maximize windows near screen size (and we probably break it). There's also window managers like i3 on which making effort to center the windows are pointless since it's a tiling wm. We should let some platform details be different, I think. -- Thiago ---------- Forwarded message --------- De: Andy Goryachev > Date: seg., 17 de jun. de 2024 ?s 16:51 Subject: Re: [openjdk/jfx] 8332222: Linux Debian: Maximized stage shrinks when opening another stage (PR #1460) To: openjdk/jfx > Cc: Thiago Milczarek Say?o >, Mention > Question. I see different behavior between macOS and linux mint with the attached program (unmodified master branch). On mac, the alert window is always positioned at the upper left corner, while on linux it is correctly placed at the center of the screen. Is this expected? Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner. Unless we move the main window to another monitor. In that case I can see a number of differences: 1. main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located 2. when main window is "maximized" to full screen, both screens go into full screen mode, one (secondary) with the main window, the other (primary) with a black background. an alert pops up on the primary screen (i.e. other than the screen with the main window), but this time it is correctly positioned at the center of the primary screen. I feel this behavior (on mac) is unexpected. Any ideas? ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Jun 18 15:13:23 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 18 Jun 2024 15:13:23 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor In-Reply-To: References: Message-ID: <5Bg_gRafYBx8lY4rPmPd5Z3UHvQXJSt3iJD3LlIdwe4=.dfd26532-bc35-46c0-aeed-a9b690100db0@github.com> On Wed, 12 Jun 2024 20:03:24 GMT, Kevin Rushforth wrote: > This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. > > We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: > > * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" > * `TOOL_LINT` - used when compiling tool tasks : default = "" > * `TEST_LINT` - used when compiling test tasks : default = "" > > Each property takes a string with a comma-separated list of lint options. For example: > > > gradle -PLINT="deprecation,removal" sdk > > > I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. > > While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. > > I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. Looks good, tested several combination of options. Have one minor query, added as comment. An observation to mention: In setupLintOptions the options are separated and provided to javac individually. though the comma separated list can be provided at once. I tested that a single comma separated list works, but in case of any invalid option the error message is not clear (It prints all the options in list). But when options are provided individually then error points out exact invalid option. build.gradle line 4139: > 4137: } > 4138: } else if (compile.name == "compileJslcJava" || > 4139: compile.name == "compileToolJava") { Should we include the _compileToolsJava_ task from media too ? ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1474#pullrequestreview-2125657996 PR Review Comment: https://git.openjdk.org/jfx/pull/1474#discussion_r1644548174 From angorya at openjdk.org Tue Jun 18 15:34:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 18 Jun 2024 15:34:26 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote: >> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. >> >> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. >> >> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) >> >> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. > > Martin Fox 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 ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Comment fixes > - Consistency in naming conventions and comment cleanup. > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Expanded robot lookup table, general cleanup > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Resolving duplicates for Robot, fallback for getKeyCodeForChar > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - KeyCharacterCombination fixes on Linux Tested on linux mint, the app in the ticket fails without the fix and works with the fix. The code looks good to me, though I'd like to have a second pair of eyes on it. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1373#pullrequestreview-2125852531 From andy.goryachev at oracle.com Tue Jun 18 19:05:15 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 18 Jun 2024 19:05:15 +0000 Subject: Eclipse and Gradle in OpenJFX Message-ID: Dear developers: Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo? The reason I am asking is that in my experience, the gradle nature in OpenJFX is either misconfigured, or obsolete, or both. There is a rather old wiki page [0] which describes the Eclipse setup, though I don't think it is correct anymore. The initial import of the repository in Eclipse triggers an internal gradle run which creates/modifies a bunch of .classpath and .project files which must be undone before the workspace becomes usable. In any case, only a proper command line gradle build is supported anyway. I would like to propose removing the gradle nature from Eclipse's .project files in OpenJFX. Once done, the projects can be trivially imported into a new workspace with no extra steps required. This change has no impact on command line build whatsoever. What do you think? Thank you -andy References [1] https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Tue Jun 18 19:51:38 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 18 Jun 2024 16:51:38 -0300 Subject: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: Andy, We kind of did the opposite for Intellij (got rid of the .iml files and went for gradle import): https://github.com/openjdk/jfx/pull/1009 I couldn't get it to detect the manual tests tho. Changing some gradle files worked, but would require a deeper review, so we went without it. -- Thiago. Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > Dear developers: > > > > Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX > repo? > > > > The reason I am asking is that in my experience, the gradle nature in > OpenJFX is either misconfigured, or obsolete, or both. There is a rather > old wiki page [0] which describes the Eclipse setup, though I don't think > it is correct anymore. The initial import of the repository in Eclipse > triggers an internal gradle run which creates/modifies a bunch of > .classpath and .project files which must be undone before the workspace > becomes usable. In any case, only a proper command line gradle build is > supported anyway. > > > > I would like to propose removing the gradle nature from Eclipse's .project > files in OpenJFX. Once done, the projects can be trivially imported into a > new workspace with no extra steps required. This change has no impact on > command line build whatsoever. > > > > What do you think? > > > > Thank you > > -andy > > > > > > > > *References* > > > > [1] > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jun 18 20:14:58 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 18 Jun 2024 20:14:58 +0000 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: Interesting, thank you, Thiago. Maybe it's just the quality of gradle support in IntelliJ, or complexity of the Buildship plug-in in Eclipse. It never worked for me, and removing the gradle nature from Eclipse project files has an added benefit of removing an extra dependency. -andy From: Thiago Milczarek Say?o Date: Tuesday, June 18, 2024 at 12:51 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: Eclipse and Gradle in OpenJFX Andy, We kind of did the opposite for Intellij (got rid of the .iml files and went for gradle import): https://github.com/openjdk/jfx/pull/1009 I couldn't get it to detect the manual tests tho. Changing some gradle files worked, but would require a deeper review, so we went without it. -- Thiago. Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev > escreveu: Dear developers: Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo? The reason I am asking is that in my experience, the gradle nature in OpenJFX is either misconfigured, or obsolete, or both. There is a rather old wiki page [0] which describes the Eclipse setup, though I don't think it is correct anymore. The initial import of the repository in Eclipse triggers an internal gradle run which creates/modifies a bunch of .classpath and .project files which must be undone before the workspace becomes usable. In any case, only a proper command line gradle build is supported anyway. I would like to propose removing the gradle nature from Eclipse's .project files in OpenJFX. Once done, the projects can be trivially imported into a new workspace with no extra steps required. This change has no impact on command line build whatsoever. What do you think? Thank you -andy References [1] https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at martinfox.com Tue Jun 18 20:42:59 2024 From: martin at martinfox.com (Martin Fox) Date: Tue, 18 Jun 2024 13:42:59 -0700 Subject: Platform diferences In-Reply-To: References: Message-ID: <294B8D5A-0477-45F0-8E27-AC75D2F41A2E@martinfox.com> The alert is being shown without setting its screen or position so it will default to the primary screen regardless of where the main window is. It might make sense for new windows to default to the screen of the active stage to reduce these sorts of surprises. In any case it looks like this decision isn?t being made in the platform code, when creating a new window glass is passed the screen. On Mac things do get strange if the main window is in fullscreen mode and has taken over a Space (aka virtual desktop). The alert and the main window are both top-level DECORATED windows and can?t share that space. The work-around is to set the alert?s StageStyle to UTILITY before showing it. > On 6/17/2024 1:52 PM, Andy Goryachev wrote: > Thank you for clarification. > > I guess the only problem I see (and which applies to both mac and linux) is that the alert window appears on the wrong monitor - I would expect it to appear on the same monitor where the main window is positioned. > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Jun 18 23:09:33 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Jun 2024 16:09:33 -0700 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: We also did that for NetBeans, meaning we removed the NetBeans IDE-specific files and use their gradle plug-in (with somewhat mixed results). See https://bugs.openjdk.org/browse/JDK-8223375 FWIW, there is an open issue to do the same for Eclipse, but I think it hasn't been looked at in a while. Nir is the assignee so he will likely have some thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374 -- Kevin On 6/18/2024 1:14 PM, Andy Goryachev wrote: > > Interesting, thank you, Thiago. > > Maybe it's just the quality of gradle support in IntelliJ, or > complexity of the Buildship plug-in in Eclipse.? It never worked for > me, and removing the gradle nature from Eclipse project files has an > added benefit of removing an extra dependency. > > -andy > > *From: *Thiago Milczarek Say?o > *Date: *Tuesday, June 18, 2024 at 12:51 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: Eclipse and Gradle in OpenJFX > > Andy, > > We kind of did the opposite for Intellij (got rid of the .iml files > and went for gradle import): > > https://github.com/openjdk/jfx/pull/1009 > > > I couldn't get it to detect the manual tests tho. Changing some gradle > files worked, but would require a deeper review, so we went without it. > > -- Thiago. > > Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev > escreveu: > > Dear developers: > > Does anyone use gradle in Eclipse (Buildship plug-in) with the > OpenJFX repo? > > The reason I am asking is that in my experience, the gradle nature > in OpenJFX is either misconfigured, or obsolete, or both.? There > is a rather old wiki page [0] which describes the Eclipse setup, > though I don't think it is correct anymore.? The initial import of > the repository in Eclipse triggers an internal gradle run which > creates/modifies a bunch of .classpath and .project files which > must be undone before the workspace becomes usable. In any case, > only a proper command line gradle build is supported anyway. > > I would like to propose removing the gradle nature from Eclipse's > .project files in OpenJFX.? Once done, the projects can be > trivially imported into a new workspace with no extra steps > required.? This change has no impact on command line build whatsoever. > > What do you think? > > Thank you > > -andy > > *References* > > [1] > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jun 18 23:34:21 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 18 Jun 2024 23:34:21 +0000 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: Thank you Kevin, for this bit of insight. I see the Buildship issue mentioned in one of the comments is still open with no one assigned https://github.com/eclipse/buildship/issues/658 Chances that it will be fixed in a reasonable time frame are slim to none. I would recommend to make the changes (remove the gradle nature from eclipse config files) in the meantime, as it allows for clean import of the whole thing into Eclipse. Once the situation with Buildship changes, we can remove the Eclipse files altogether and rely on gradle import per JDK-8223374. I am also very interested in Nir's view on the subject. -andy From: Kevin Rushforth Date: Tuesday, June 18, 2024 at 16:09 To: Andy Goryachev , Thiago Milczarek Say?o Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Eclipse and Gradle in OpenJFX We also did that for NetBeans, meaning we removed the NetBeans IDE-specific files and use their gradle plug-in (with somewhat mixed results). See https://bugs.openjdk.org/browse/JDK-8223375 FWIW, there is an open issue to do the same for Eclipse, but I think it hasn't been looked at in a while. Nir is the assignee so he will likely have some thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374 -- Kevin On 6/18/2024 1:14 PM, Andy Goryachev wrote: Interesting, thank you, Thiago. Maybe it's just the quality of gradle support in IntelliJ, or complexity of the Buildship plug-in in Eclipse. It never worked for me, and removing the gradle nature from Eclipse project files has an added benefit of removing an extra dependency. -andy From: Thiago Milczarek Say?o Date: Tuesday, June 18, 2024 at 12:51 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: Eclipse and Gradle in OpenJFX Andy, We kind of did the opposite for Intellij (got rid of the .iml files and went for gradle import): https://github.com/openjdk/jfx/pull/1009 I couldn't get it to detect the manual tests tho. Changing some gradle files worked, but would require a deeper review, so we went without it. -- Thiago. Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev > escreveu: Dear developers: Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo? The reason I am asking is that in my experience, the gradle nature in OpenJFX is either misconfigured, or obsolete, or both. There is a rather old wiki page [0] which describes the Eclipse setup, though I don't think it is correct anymore. The initial import of the repository in Eclipse triggers an internal gradle run which creates/modifies a bunch of .classpath and .project files which must be undone before the workspace becomes usable. In any case, only a proper command line gradle build is supported anyway. I would like to propose removing the gradle nature from Eclipse's .project files in OpenJFX. Once done, the projects can be trivially imported into a new workspace with no extra steps required. This change has no impact on command line build whatsoever. What do you think? Thank you -andy References [1] https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Jun 19 00:29:29 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 Jun 2024 03:29:29 +0300 Subject: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: It has been a while since I tried a clean import of jfx, but the instructions in https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse seem correct, unless something changed. What you describe is written there. Only the initial import requires a gradle build, and after reverting the project and classpath changes, you can work with ECJ (unless you need tasks to build native code etc.) What is worth looking at is the 'eclipse' gradle task that tries to generate these files according to the gradle files. However, the way the project is built in gradle is both complicated and very old (compliant with gradle 2 I think), so I don't know how well that will work. In my modern projects, the 'eclipse' task works really well and allows me to not check in the eclipse files: a gradle refresh/synch is run once (does all the configuration and dependency management), and then running 'eclipse' once sets up the eclipse side. On Tue, Jun 18, 2024 at 10:52?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Andy, > > We kind of did the opposite for Intellij (got rid of the .iml files and > went for gradle import): > > https://github.com/openjdk/jfx/pull/1009 > > I couldn't get it to detect the manual tests tho. Changing some gradle > files worked, but would require a deeper review, so we went without it. > > -- Thiago. > > Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev < > andy.goryachev at oracle.com> escreveu: > >> Dear developers: >> >> >> >> Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX >> repo? >> >> >> >> The reason I am asking is that in my experience, the gradle nature in >> OpenJFX is either misconfigured, or obsolete, or both. There is a rather >> old wiki page [0] which describes the Eclipse setup, though I don't think >> it is correct anymore. The initial import of the repository in Eclipse >> triggers an internal gradle run which creates/modifies a bunch of >> .classpath and .project files which must be undone before the workspace >> becomes usable. In any case, only a proper command line gradle build is >> supported anyway. >> >> >> >> I would like to propose removing the gradle nature from Eclipse's >> .project files in OpenJFX. Once done, the projects can be trivially >> imported into a new workspace with no extra steps required. This change >> has no impact on command line build whatsoever. >> >> >> >> What do you think? >> >> >> >> Thank you >> >> -andy >> >> >> >> >> >> >> >> *References* >> >> >> >> [1] >> https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Wed Jun 19 00:48:34 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 Jun 2024 03:48:34 +0300 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: https://github.com/eclipse/buildship/issues/658 is not that relevant because it describes a problem in Gradle's integration with Eclipse, not with Buildship, but it's reported on Buildship, so I don't think there's much to resolve there except for alignment issues. It has since been solved on Gradle's side. If you go to Preferences > Grade > Experimental features > Enable module support, the described issue will be resolved (and maybe even without it because I'm not sure these features are experimental anymore - Gradle 7 enabled module support by default https://docs.gradle.org/7.0/release-notes.html#promoted-features). On Wed, Jun 19, 2024 at 3:28?AM Andy Goryachev wrote: > Thank you Kevin, for this bit of insight. I see the Buildship issue > mentioned in one of the comments is still open with no one assigned > > > > https://github.com/eclipse/buildship/issues/658 > > > > Chances that it will be fixed in a reasonable time frame are slim to > none. I would recommend to make the changes (remove the gradle nature from > eclipse config files) in the meantime, as it allows for clean import of the > whole thing into Eclipse. > > > > Once the situation with Buildship changes, we can remove the Eclipse files > altogether and rely on gradle import per JDK-8223374. > > > > I am also very interested in Nir's view on the subject. > > > > -andy > > > > > > > > *From: *Kevin Rushforth > *Date: *Tuesday, June 18, 2024 at 16:09 > *To: *Andy Goryachev , Thiago Milczarek Say?o < > thiago.sayao at gmail.com> > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: Eclipse and Gradle in OpenJFX > > We also did that for NetBeans, meaning we removed the NetBeans > IDE-specific files and use their gradle plug-in (with somewhat mixed > results). See https://bugs.openjdk.org/browse/JDK-8223375 > > FWIW, there is an open issue to do the same for Eclipse, but I think it > hasn't been looked at in a while. Nir is the assignee so he will likely > have some thoughts on this. https://bugs.openjdk.org/browse/JDK-8223374 > > -- Kevin > > On 6/18/2024 1:14 PM, Andy Goryachev wrote: > > Interesting, thank you, Thiago. > > > > Maybe it's just the quality of gradle support in IntelliJ, or complexity > of the Buildship plug-in in Eclipse. It never worked for me, and removing > the gradle nature from Eclipse project files has an added benefit of > removing an extra dependency. > > > > -andy > > > > > > > > *From: *Thiago Milczarek Say?o > > *Date: *Tuesday, June 18, 2024 at 12:51 > *To: *Andy Goryachev > > *Cc: *openjfx-dev at openjdk.org > > *Subject: *[External] : Re: Eclipse and Gradle in OpenJFX > > Andy, > > > > We kind of did the opposite for Intellij (got rid of the .iml files and > went for gradle import): > > > > https://github.com/openjdk/jfx/pull/1009 > > > > > I couldn't get it to detect the manual tests tho. Changing some gradle > files worked, but would require a deeper review, so we went without it. > > > > -- Thiago. > > > > Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev < > andy.goryachev at oracle.com> escreveu: > > Dear developers: > > > > Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX > repo? > > > > The reason I am asking is that in my experience, the gradle nature in > OpenJFX is either misconfigured, or obsolete, or both. There is a rather > old wiki page [0] which describes the Eclipse setup, though I don't think > it is correct anymore. The initial import of the repository in Eclipse > triggers an internal gradle run which creates/modifies a bunch of > .classpath and .project files which must be undone before the workspace > becomes usable. In any case, only a proper command line gradle build is > supported anyway. > > > > I would like to propose removing the gradle nature from Eclipse's .project > files in OpenJFX. Once done, the projects can be trivially imported into a > new workspace with no extra steps required. This change has no impact on > command line build whatsoever. > > > > What do you think? > > > > Thank you > > -andy > > > > > > > > *References* > > > > [1] > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmack at openjdk.org Wed Jun 19 10:26:25 2024 From: mmack at openjdk.org (Markus Mack) Date: Wed, 19 Jun 2024 10:26:25 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart Message-ID: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. ------------- Commit messages: - BarChart duplicate category index fix + test Changes: https://git.openjdk.org/jfx/pull/1476/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8088923 Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1476.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/jfx/pull/1476 From arapte at openjdk.org Wed Jun 19 14:29:20 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 19 Jun 2024 14:29:20 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 20:07:32 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with two additional commits since the last revision: > > - process more reviewer comments > - Process reviewer comments looks good, suggesting a few minor changes. tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 1: > 1: /* This test file is moved from a different location, could do `git mv` instead removing and adding. tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. This file is moved, so the copyright should reflect same. Should be : `2023, 2024` tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 321: > 319: Stage stage = new Stage(); > 320: stage.setScene(new Scene(root)); > 321: stage.show(); I think, a CountDownLatch should be added to make sure that stage is shown before proceeding. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2128074964 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1646128134 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1646060915 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1646303282 From mfox at openjdk.org Wed Jun 19 15:57:23 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 19 Jun 2024 15:57:23 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Mon, 17 Jun 2024 17:53:53 GMT, Andy Goryachev wrote: > I cannot invoke Japanese IME or in fact switch to another input language if I am inside an editable TableView in the Monkey Tester. I'm also seeing bad behavior in a TableView using IBus on Ubuntu 22. Glass is being told to disable the IME when focus moves to the TableView. I don't see anything in the stack dump which is Linux-specific so I would expect the failure to be cross-platform but it's working on Mac. Bit of a puzzle. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2179032394 From mfox at openjdk.org Wed Jun 19 16:35:24 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 19 Jun 2024 16:35:24 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: <04Bx8NzUevUkI-fjgKiaZ26IK50rK9vCEP9FeGpkYUs=.543907c0-bb27-4dbe-964c-3b77eb08d422@github.com> On Mon, 17 Jun 2024 17:53:53 GMT, Andy Goryachev wrote: >> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: >> >> - Merge branch 'refs/heads/master' into new_ime >> - Merge branch 'refs/heads/master' into new_ime >> - Merge branch 'master' into new_ime >> - Add signals to avoid warnings >> - Merge branch 'master' into new_ime >> >> # Conflicts: >> # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp >> - Add check for jview >> - - Fix comment path >> - - Fix double keyrelease >> - - Use a work-around to relative positioning (until wayland is not officially supported) >> - Unref pango attr list >> - Merge branch 'master' into new_ime >> - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec > > I am testing with an unorthodox linux setup: linux mint on mac book pro > > `Linux OraMac 5.15.0-107-generic #117-Ubuntu SMP Fri Apr 26 12:26:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux` > > I have Japanese input method support installed (Input Method Framework: fcitx, input method Mozc) > > I can switch to Japanese IME in the native Text Editor, and I can invoke the IME in a TextArea when running the Monkey Tester. > > I cannot invoke Japanese IME or in fact switch to another input language if I am inside an editable TableView in the Monkey Tester. Starting with the "us" selection in the tray, even if I right click on that icon in the tray and change the input method it goes back to the "us". Space-Space (the key sequence used to toggle input language in my setup) does not work, and Ctrl-Space which brings up the Japanes IME does not work either. > > See nothing in the console. > > I might be doing something wrong, of course, since this is not an environment I typically work with. The issue @andy-goryachev-oracle reported with the Monkey Tester TableView isn't related to this PR or even Linux since I can reproduce it on Mac. As I double-click on cells in the Table View to make them editable Glass is being told to disable the IME most of the time. Sometimes the IME is enabled but I have to figure out a pattern. On Mac disabling the IME turns off the composition window but I can still enter individual Japanese characters which makes the problem less obvious than on Linux. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2179096935 From mfox at openjdk.org Wed Jun 19 23:50:21 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 19 Jun 2024 23:50:21 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec I created [JDK-8334586](https://bugs.openjdk.org/browse/JDK-8334586) for the TableView issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2179582595 From jbhaskar at openjdk.org Thu Jun 20 02:30:35 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 20 Jun 2024 02:30:35 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update Message-ID: Issue: The Websocket Channel is broken Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. ------------- Commit messages: - add pass and fail button - 8331765: Websocket callbacks are not executed after WebKit 617.1 update Changes: https://git.openjdk.org/jfx/pull/1477/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331765 Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1477.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1477/head:pull/1477 PR: https://git.openjdk.org/jfx/pull/1477 From kcr at openjdk.org Thu Jun 20 12:33:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Jun 2024 12:33:17 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 02:25:54 GMT, Jay Bhaskar wrote: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. Reviewers: @kevinrushforth @HimaBinduMeda @tiainen do you want to give this a test drive as well? I don't think there are any potential platform-specific build issues, but it wouldn't hurt to confirm that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1477#issuecomment-2180553573 From andy.goryachev at oracle.com Thu Jun 20 15:16:45 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 20 Jun 2024 15:16:45 +0000 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: Nir: I don't understand two things: 1. why we need to jump through the hoops with the initial import (reverting the changes etc.) even if it described and 2. what 'eclipse' task you are referring to? There is no 'eclipse' task in build.gradle as far as I can see (see below) What is the value of keeping these steps and complicating the process (with Eclipse)? -andy $ gradle -q :tasks --all Defining Closed Properties [...snip...] ------------------------------------------------------------ Tasks runnable from root project 'rt' ------------------------------------------------------------ Default tasks: sdk Basic tasks ----------- appsMac - Runs the apps creation tasks buildModuleBaseMac - creates javafx.base property files buildModuleGraphicsMac - copies javafx.graphics native libraries buildModuleLibsMac buildModuleMediaMac - copies javafx.media native libraries buildModuleSWTMac - copies SWT JAR buildModuleWebMac - copies javafx.web native libraries clean - Deletes the build directory and the build directory of all sub projects cleanAll - Scrubs the repo of build artifacts findbugsMac - Runs the findbugs creation tasks javadoc - Generates the JavaDoc for all the public API javafxSwtMac - Creates the javafx-swt.jar for the mac target base:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods controls:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods fxml:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods graphics:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods media:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods swing:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods web:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods publicExportsMac - Creates the public export bundles publicExportsStandaloneMac - Creates the disk layout for sdk, jmods, and docs sdkArtifactsMac - Copies bundled and standalone sdk dirs into artifacts for mac sdkMac targzJmodsMac - Creates the public jmods tar.gz bundle targzSdkMac - Creates the public sdk tar.gz bundle zipsMac - Creates the public zip bundles zipsStandaloneMac - Creates the public zip bundles Build tasks ----------- base:assemble - Assembles the outputs of this project. closedTests:assemble - Assembles the outputs of this project. controls:assemble - Assembles the outputs of this project. fxml:assemble - Assembles the outputs of this project. graphics:assemble - Assembles the outputs of this project. media:assemble - Assembles the outputs of this project. swing:assemble - Assembles the outputs of this project. swt:assemble - Assembles the outputs of this project. systemTests:assemble - Assembles the outputs of this project. web:assemble - Assembles the outputs of this project. base:build - Assembles and tests this project. closedTests:build - Assembles and tests this project. controls:build - Assembles and tests this project. fxml:build - Assembles and tests this project. graphics:build - Assembles and tests this project. media:build - Assembles and tests this project. swing:build - Assembles and tests this project. swt:build - Assembles and tests this project. systemTests:build - Assembles and tests this project. web:build - Assembles and tests this project. base:buildDependents - Assembles and tests this project and all projects that depend on it. closedTests:buildDependents - Assembles and tests this project and all projects that depend on it. controls:buildDependents - Assembles and tests this project and all projects that depend on it. fxml:buildDependents - Assembles and tests this project and all projects that depend on it. graphics:buildDependents - Assembles and tests this project and all projects that depend on it. media:buildDependents - Assembles and tests this project and all projects that depend on it. swing:buildDependents - Assembles and tests this project and all projects that depend on it. swt:buildDependents - Assembles and tests this project and all projects that depend on it. systemTests:buildDependents - Assembles and tests this project and all projects that depend on it. web:buildDependents - Assembles and tests this project and all projects that depend on it. base:buildModuleMac controls:buildModuleMac fxml:buildModuleMac graphics:buildModuleMac media:buildModuleMac swing:buildModuleMac web:buildModuleMac buildModulesMac buildModuleZipMac base:buildNeeded - Assembles and tests this project and all projects it depends on. closedTests:buildNeeded - Assembles and tests this project and all projects it depends on. controls:buildNeeded - Assembles and tests this project and all projects it depends on. fxml:buildNeeded - Assembles and tests this project and all projects it depends on. graphics:buildNeeded - Assembles and tests this project and all projects it depends on. media:buildNeeded - Assembles and tests this project and all projects it depends on. swing:buildNeeded - Assembles and tests this project and all projects it depends on. swt:buildNeeded - Assembles and tests this project and all projects it depends on. systemTests:buildNeeded - Assembles and tests this project and all projects it depends on. web:buildNeeded - Assembles and tests this project and all projects it depends on. buildRunArgsMac graphics:ccMacFont - Compiles native sources for font for mac graphics:ccMacGlass - Compiles native sources for glass for mac graphics:ccMacIio - Compiles native sources for iio for mac graphics:ccMacPrism - Compiles native sources for prism for mac graphics:ccMacPrismES2 - Compiles native sources for prismES2 for mac graphics:ccMacPrismSW - Compiles native sources for prismSW for mac base:classes - Assembles main classes. closedTests:classes - Assembles main classes. controls:classes - Assembles main classes. fxml:classes - Assembles main classes. graphics:classes - Assembles main classes. media:classes - Assembles main classes. swing:classes - Assembles main classes. swt:classes - Assembles main classes. systemTests:classes - Assembles main classes. web:classes - Assembles main classes. base:clean - Deletes the build directory. closedTests:clean - Deletes the build directory. controls:clean - Deletes the build directory. fxml:clean - Deletes the build directory. graphics:clean - Deletes the build directory. media:clean - Deletes the build directory. swing:clean - Deletes the build directory. swt:clean - Deletes the build directory. systemTests:clean - Deletes the build directory. web:clean - Deletes the build directory. graphics:cleanNative - Clean all native libraries and objects for Graphics graphics:cleanNativeDecora - Clean native objects for Decora graphics:cleanNativeFont - Clean native objects for font graphics:cleanNativeGlass - Clean native objects for glass graphics:cleanNativeIio - Clean native objects for iio graphics:cleanNativePrism - Clean native objects for prism graphics:cleanNativePrismES2 - Clean native objects for prismES2 graphics:cleanNativePrismSW - Clean native objects for prismSW createMSPfile base:jar - Assembles a jar archive containing the classes of the 'main' feature. closedTests:jar - Assembles a jar archive containing the classes of the 'main' feature. controls:jar - Assembles a jar archive containing the classes of the 'main' feature. fxml:jar - Assembles a jar archive containing the classes of the 'main' feature. graphics:jar - Assembles a jar archive containing the classes of the 'main' feature. media:jar - Assembles a jar archive containing the classes of the 'main' feature. swing:jar - Assembles a jar archive containing the classes of the 'main' feature. swt:jar - Assembles a jar archive containing the classes of the 'main' feature. systemTests:jar - Assembles a jar archive containing the classes of the 'main' feature. web:jar - Assembles a jar archive containing the classes of the 'main' feature. base:jmodMac controls:jmodMac fxml:jmodMac graphics:jmodMac media:jmodMac swing:jmodMac web:jmodMac graphics:jslcClasses - Assembles jslc classes. graphics:linkMacFont - Creates native dynamic library for font for mac graphics:linkMacGlass - Creates native dynamic library for glass for mac graphics:linkMacIio - Creates native dynamic library for iio for mac graphics:linkMacPrism - Creates native dynamic library for prism for mac graphics:linkMacPrismES2 - Creates native dynamic library for prismES2 for mac graphics:linkMacPrismSW - Creates native dynamic library for prismSW for mac graphics:native - Compiles and Builds all native libraries for Graphics graphics:nativeDecora - Generates JNI headers, compiles, and builds native dynamic library for Decora graphics:nativeFont - Generates JNI headers, compiles, and builds native dynamic library for font for all compile targets graphics:nativeGlass - Generates JNI headers, compiles, and builds native dynamic library for glass for all compile targets graphics:nativeIio - Generates JNI headers, compiles, and builds native dynamic library for iio for all compile targets graphics:nativePrism - Generates JNI headers, compiles, and builds native dynamic library for prism for all compile targets graphics:nativePrismES2 - Generates JNI headers, compiles, and builds native dynamic library for prismES2 for all compile targets graphics:nativePrismSW - Generates JNI headers, compiles, and builds native dynamic library for prismSW for all compile targets graphics:shadersClasses - Assembles shaders classes. base:shimsClasses - Assembles shims classes. controls:shimsClasses - Assembles shims classes. fxml:shimsClasses - Assembles shims classes. graphics:shimsClasses - Assembles shims classes. swing:shimsClasses - Assembles shims classes. web:shimsClasses - Assembles shims classes. graphics:stubClasses - Assembles stub classes. systemTests:testapp1Classes - Assembles testapp1 classes. systemTests:testapp2Classes - Assembles testapp2 classes. systemTests:testapp3Classes - Assembles testapp3 classes. systemTests:testapp4Classes - Assembles testapp4 classes. systemTests:testapp5Classes - Assembles testapp5 classes. systemTests:testapp6Classes - Assembles testapp6 classes. systemTests:testapp7Classes - Assembles testapp7 classes. base:testClasses - Assembles test classes. closedTests:testClasses - Assembles test classes. controls:testClasses - Assembles test classes. fxml:testClasses - Assembles test classes. graphics:testClasses - Assembles test classes. media:testClasses - Assembles test classes. swing:testClasses - Assembles test classes. swt:testClasses - Assembles test classes. systemTests:testClasses - Assembles test classes. web:testClasses - Assembles test classes. systemTests:testscriptapp1Classes - Assembles testscriptapp1 classes. systemTests:testscriptapp2Classes - Assembles testscriptapp2 classes. media:toolsClasses - Assembles tools classes. Build Setup tasks ----------------- init - Initializes a new Gradle build. wrapper - Generates Gradle wrapper files. Documentation tasks ------------------- base:javadoc - Generates Javadoc API documentation for the 'main' feature. closedTests:javadoc - Generates Javadoc API documentation for the 'main' feature. controls:javadoc - Generates Javadoc API documentation for the 'main' feature. fxml:javadoc - Generates Javadoc API documentation for the 'main' feature. graphics:javadoc - Generates Javadoc API documentation for the 'main' feature. media:javadoc - Generates Javadoc API documentation for the 'main' feature. swing:javadoc - Generates Javadoc API documentation for the 'main' feature. swt:javadoc - Generates Javadoc API documentation for the 'main' feature. systemTests:javadoc - Generates Javadoc API documentation for the 'main' feature. web:javadoc - Generates Javadoc API documentation for the 'main' feature. Help tasks ---------- buildEnvironment - Displays all buildscript dependencies declared in root project 'rt'. apps:buildEnvironment - Displays all buildscript dependencies declared in project ':apps'. base:buildEnvironment - Displays all buildscript dependencies declared in project ':base'. closedTests:buildEnvironment - Displays all buildscript dependencies declared in project ':closedTests'. controls:buildEnvironment - Displays all buildscript dependencies declared in project ':controls'. fxml:buildEnvironment - Displays all buildscript dependencies declared in project ':fxml'. graphics:buildEnvironment - Displays all buildscript dependencies declared in project ':graphics'. media:buildEnvironment - Displays all buildscript dependencies declared in project ':media'. swing:buildEnvironment - Displays all buildscript dependencies declared in project ':swing'. swt:buildEnvironment - Displays all buildscript dependencies declared in project ':swt'. systemTests:buildEnvironment - Displays all buildscript dependencies declared in project ':systemTests'. web:buildEnvironment - Displays all buildscript dependencies declared in project ':web'. dependencies - Displays all dependencies declared in root project 'rt'. apps:dependencies - Displays all dependencies declared in project ':apps'. base:dependencies - Displays all dependencies declared in project ':base'. closedTests:dependencies - Displays all dependencies declared in project ':closedTests'. controls:dependencies - Displays all dependencies declared in project ':controls'. fxml:dependencies - Displays all dependencies declared in project ':fxml'. graphics:dependencies - Displays all dependencies declared in project ':graphics'. media:dependencies - Displays all dependencies declared in project ':media'. swing:dependencies - Displays all dependencies declared in project ':swing'. swt:dependencies - Displays all dependencies declared in project ':swt'. systemTests:dependencies - Displays all dependencies declared in project ':systemTests'. web:dependencies - Displays all dependencies declared in project ':web'. dependencyInsight - Displays the insight into a specific dependency in root project 'rt'. apps:dependencyInsight - Displays the insight into a specific dependency in project ':apps'. base:dependencyInsight - Displays the insight into a specific dependency in project ':base'. closedTests:dependencyInsight - Displays the insight into a specific dependency in project ':closedTests'. controls:dependencyInsight - Displays the insight into a specific dependency in project ':controls'. fxml:dependencyInsight - Displays the insight into a specific dependency in project ':fxml'. graphics:dependencyInsight - Displays the insight into a specific dependency in project ':graphics'. media:dependencyInsight - Displays the insight into a specific dependency in project ':media'. swing:dependencyInsight - Displays the insight into a specific dependency in project ':swing'. swt:dependencyInsight - Displays the insight into a specific dependency in project ':swt'. systemTests:dependencyInsight - Displays the insight into a specific dependency in project ':systemTests'. web:dependencyInsight - Displays the insight into a specific dependency in project ':web'. help - Displays a help message. apps:help - Displays a help message. base:help - Displays a help message. closedTests:help - Displays a help message. controls:help - Displays a help message. fxml:help - Displays a help message. graphics:help - Displays a help message. media:help - Displays a help message. swing:help - Displays a help message. swt:help - Displays a help message. systemTests:help - Displays a help message. web:help - Displays a help message. javaToolchains - Displays the detected java toolchains. apps:javaToolchains - Displays the detected java toolchains. base:javaToolchains - Displays the detected java toolchains. closedTests:javaToolchains - Displays the detected java toolchains. controls:javaToolchains - Displays the detected java toolchains. fxml:javaToolchains - Displays the detected java toolchains. graphics:javaToolchains - Displays the detected java toolchains. media:javaToolchains - Displays the detected java toolchains. swing:javaToolchains - Displays the detected java toolchains. swt:javaToolchains - Displays the detected java toolchains. systemTests:javaToolchains - Displays the detected java toolchains. web:javaToolchains - Displays the detected java toolchains. outgoingVariants - Displays the outgoing variants of root project 'rt'. apps:outgoingVariants - Displays the outgoing variants of project ':apps'. base:outgoingVariants - Displays the outgoing variants of project ':base'. closedTests:outgoingVariants - Displays the outgoing variants of project ':closedTests'. controls:outgoingVariants - Displays the outgoing variants of project ':controls'. fxml:outgoingVariants - Displays the outgoing variants of project ':fxml'. graphics:outgoingVariants - Displays the outgoing variants of project ':graphics'. media:outgoingVariants - Displays the outgoing variants of project ':media'. swing:outgoingVariants - Displays the outgoing variants of project ':swing'. swt:outgoingVariants - Displays the outgoing variants of project ':swt'. systemTests:outgoingVariants - Displays the outgoing variants of project ':systemTests'. web:outgoingVariants - Displays the outgoing variants of project ':web'. projects - Displays the sub-projects of root project 'rt'. apps:projects - Displays the sub-projects of project ':apps'. base:projects - Displays the sub-projects of project ':base'. closedTests:projects - Displays the sub-projects of project ':closedTests'. controls:projects - Displays the sub-projects of project ':controls'. fxml:projects - Displays the sub-projects of project ':fxml'. graphics:projects - Displays the sub-projects of project ':graphics'. media:projects - Displays the sub-projects of project ':media'. swing:projects - Displays the sub-projects of project ':swing'. swt:projects - Displays the sub-projects of project ':swt'. systemTests:projects - Displays the sub-projects of project ':systemTests'. web:projects - Displays the sub-projects of project ':web'. properties - Displays the properties of root project 'rt'. apps:properties - Displays the properties of project ':apps'. base:properties - Displays the properties of project ':base'. closedTests:properties - Displays the properties of project ':closedTests'. controls:properties - Displays the properties of project ':controls'. fxml:properties - Displays the properties of project ':fxml'. graphics:properties - Displays the properties of project ':graphics'. media:properties - Displays the properties of project ':media'. swing:properties - Displays the properties of project ':swing'. swt:properties - Displays the properties of project ':swt'. systemTests:properties - Displays the properties of project ':systemTests'. web:properties - Displays the properties of project ':web'. resolvableConfigurations - Displays the configurations that can be resolved in root project 'rt'. apps:resolvableConfigurations - Displays the configurations that can be resolved in project ':apps'. base:resolvableConfigurations - Displays the configurations that can be resolved in project ':base'. closedTests:resolvableConfigurations - Displays the configurations that can be resolved in project ':closedTests'. controls:resolvableConfigurations - Displays the configurations that can be resolved in project ':controls'. fxml:resolvableConfigurations - Displays the configurations that can be resolved in project ':fxml'. graphics:resolvableConfigurations - Displays the configurations that can be resolved in project ':graphics'. media:resolvableConfigurations - Displays the configurations that can be resolved in project ':media'. swing:resolvableConfigurations - Displays the configurations that can be resolved in project ':swing'. swt:resolvableConfigurations - Displays the configurations that can be resolved in project ':swt'. systemTests:resolvableConfigurations - Displays the configurations that can be resolved in project ':systemTests'. web:resolvableConfigurations - Displays the configurations that can be resolved in project ':web'. tasks - Displays the tasks runnable from root project 'rt' (some of the displayed tasks may belong to subprojects). apps:tasks - Displays the tasks runnable from project ':apps'. base:tasks - Displays the tasks runnable from project ':base'. closedTests:tasks - Displays the tasks runnable from project ':closedTests'. controls:tasks - Displays the tasks runnable from project ':controls'. fxml:tasks - Displays the tasks runnable from project ':fxml'. graphics:tasks - Displays the tasks runnable from project ':graphics'. media:tasks - Displays the tasks runnable from project ':media'. swing:tasks - Displays the tasks runnable from project ':swing'. swt:tasks - Displays the tasks runnable from project ':swt'. systemTests:tasks - Displays the tasks runnable from project ':systemTests'. web:tasks - Displays the tasks runnable from project ':web'. Verification tasks ------------------ base:check - Runs all checks. closedTests:check - Runs all checks. controls:check - Runs all checks. fxml:check - Runs all checks. graphics:check - Runs all checks. media:check - Runs all checks. swing:check - Runs all checks. swt:check - Runs all checks. systemTests:check - Runs all checks. web:check - Runs all checks. base:test - Runs the test suite. closedTests:test - Runs the test suite. controls:test - Runs the test suite. fxml:test - Runs the test suite. graphics:test - Runs the test suite. media:test - Runs the test suite. swing:test - Runs the test suite. swt:test - Runs the test suite. systemTests:test - Runs the test suite. web:test - Runs the test suite. Other tasks ----------- all antUpdateCacheIfNeeded apps appsjar apps:appsJarMac media:buildMacGlib media:buildMacGStreamer media:buildMacNative media:buildMacPlugins buildModules media:buildNativeTargets checkCache chmodArtifactsSdkMac apps:cleanMac base:cleanOpenLegalStandaloneMac controls:cleanOpenLegalStandaloneMac fxml:cleanOpenLegalStandaloneMac graphics:cleanOpenLegalStandaloneMac media:cleanOpenLegalStandaloneMac swing:cleanOpenLegalStandaloneMac web:cleanOpenLegalStandaloneMac closedSystemTests graphics:compileDecoraCompilers - Compile the Decora JSL Compilers graphics:compileDecoraHLSLShaders - Compile Decora HLSL files into .obj files graphics:compileDecoraNativeShadersMac - Compiles Decora SSE natives for mac graphics:compileFullJava - Compile all of the graphics java classes - main and shaders base:compileJava - Compiles main Java source. closedTests:compileJava - Compiles main Java source. controls:compileJava - Compiles main Java source. fxml:compileJava - Compiles main Java source. graphics:compileJava - Compiles main Java source. media:compileJava - Compiles main Java source. swing:compileJava - Compiles main Java source. swt:compileJava - Compiles main Java source. systemTests:compileJava - Compiles main Java source. web:compileJava - Compiles main Java source. web:compileJavaDOMBinding web:compileJavaDOMBindingMac graphics:compileJslcJava - Compiles jslc Java source. web:compileNativeMac graphics:compilePrismCompilers - Compile the Prism JSL Compilers graphics:compilePrismHLSLShaders - Compile Prism HLSL files into .obj files graphics:compileShadersJava - Compiles shaders Java source. base:compileShimsJava - Compiles shims Java source. controls:compileShimsJava - Compiles shims Java source. fxml:compileShimsJava - Compiles shims Java source. graphics:compileShimsJava - Compiles shims Java source. swing:compileShimsJava - Compiles shims Java source. web:compileShimsJava - Compiles shims Java source. graphics:compileStubJava - Compiles stub Java source. systemTests:compileTestapp1Java - Compiles testapp1 Java source. systemTests:compileTestapp2Java - Compiles testapp2 Java source. systemTests:compileTestapp3Java - Compiles testapp3 Java source. systemTests:compileTestapp4Java - Compiles testapp4 Java source. systemTests:compileTestapp5Java - Compiles testapp5 Java source. systemTests:compileTestapp6Java - Compiles testapp6 Java source. systemTests:compileTestapp7Java - Compiles testapp7 Java source. base:compileTestJava - Compiles test Java source. closedTests:compileTestJava - Compiles test Java source. controls:compileTestJava - Compiles test Java source. fxml:compileTestJava - Compiles test Java source. graphics:compileTestJava - Compiles test Java source. media:compileTestJava - Compiles test Java source. swing:compileTestJava - Compiles test Java source. swt:compileTestJava - Compiles test Java source. systemTests:compileTestJava - Compiles test Java source. web:compileTestJava - Compiles test Java source. systemTests:compileTestscriptapp1Java - Compiles testscriptapp1 Java source. systemTests:compileTestscriptapp2Java - Compiles testscriptapp2 Java source. media:compileToolsJava - Compiles tools Java source. components - Displays the components produced by root project 'rt'. [deprecated] apps:components - Displays the components produced by project ':apps'. [deprecated] base:components - Displays the components produced by project ':base'. [deprecated] closedTests:components - Displays the components produced by project ':closedTests'. [deprecated] controls:components - Displays the components produced by project ':controls'. [deprecated] fxml:components - Displays the components produced by project ':fxml'. [deprecated] graphics:components - Displays the components produced by project ':graphics'. [deprecated] media:components - Displays the components produced by project ':media'. [deprecated] swing:components - Displays the components produced by project ':swing'. [deprecated] swt:components - Displays the components produced by project ':swt'. [deprecated] systemTests:components - Displays the components produced by project ':systemTests'. [deprecated] web:components - Displays the components produced by project ':web'. [deprecated] copyAppsArtifacts copyAppsArtifacts3DViewerMac copyAppsArtifactsEnsemble8Mac copyAppsArtifactsMac copyAppsArtifactsMandelbrotSetMac copyAppsArtifactsModenaMac copyAppsArtifactsProjectProperties3DViewerMac copyAppsArtifactsProjectPropertiesEnsemble8Mac copyAppsArtifactsProjectPropertiesMandelbrotSetMac copyAppsArtifactsProjectPropertiesModenaMac copyAppsArtifactsReadmeMac copyAppsArtifactsSources3DViewerMac copyAppsArtifactsSourcesEnsemble8Mac copyAppsArtifactsSourcesMandelbrotSetMac copyAppsArtifactsSourcesModenaMac copyArtifactsDocsMac copyArtifactsJmodsMac copyArtifactsSdkMac copyArtifactsToysCanvasTestMac copyArtifactsToysColorCubeMac copyArtifactsToysEarthCubeFX2Mac copyArtifactsToysEmbeddedSwingMac copyArtifactsToysFX8-3DAPIMac copyArtifactsToysGradientsMac copyArtifactsToysHelloMac copyArtifactsToysHelloWorldMac copyArtifactsToysMac copyArtifactsToysPickTest3DMac copyArtifactsToysRobotMac copyArtifactsToysVersionInfoMac copyArtifactsToysVideoCubeMac copyArtifactsToysZBufferTestMac base:copyBinFilesMac controls:copyBinFilesMac fxml:copyBinFilesMac graphics:copyBinFilesMac media:copyBinFilesMac swing:copyBinFilesMac web:copyBinFilesMac base:copyBuildPropertiesMac controls:copyBuildPropertiesMac fxml:copyBuildPropertiesMac graphics:copyBuildPropertiesMac media:copyBuildPropertiesMac swing:copyBuildPropertiesMac web:copyBuildPropertiesMac base:copyClassFilesMac controls:copyClassFilesMac fxml:copyClassFilesMac graphics:copyClassFilesMac media:copyClassFilesMac swing:copyClassFilesMac web:copyClassFilesMac base:copyClosedLegalStandaloneMac controls:copyClosedLegalStandaloneMac fxml:copyClosedLegalStandaloneMac graphics:copyClosedLegalStandaloneMac media:copyClosedLegalStandaloneMac swing:copyClosedLegalStandaloneMac web:copyClosedLegalStandaloneMac base:copyDocFilesMac controls:copyDocFilesMac fxml:copyDocFilesMac graphics:copyDocFilesMac media:copyDocFilesMac swing:copyDocFilesMac web:copyDocFilesMac web:copyDumpTreeNativeMac base:copyGeneratedShims controls:copyGeneratedShims fxml:copyGeneratedShims graphics:copyGeneratedShims swing:copyGeneratedShims web:copyGeneratedShims web:copyICUFile base:copyLegalMac controls:copyLegalMac fxml:copyLegalMac graphics:copyLegalMac media:copyLegalMac swing:copyLegalMac web:copyLegalMac base:copyLegalStandaloneMac controls:copyLegalStandaloneMac fxml:copyLegalStandaloneMac graphics:copyLegalStandaloneMac media:copyLegalStandaloneMac swing:copyLegalStandaloneMac web:copyLegalStandaloneMac base:copyLibFilesMac controls:copyLibFilesMac fxml:copyLibFilesMac graphics:copyLibFilesMac media:copyLibFilesMac swing:copyLibFilesMac web:copyLibFilesMac base:copyLibFilesStandaloneMac controls:copyLibFilesStandaloneMac fxml:copyLibFilesStandaloneMac graphics:copyLibFilesStandaloneMac media:copyLibFilesStandaloneMac swing:copyLibFilesStandaloneMac web:copyLibFilesStandaloneMac base:copyNativeFilesStandaloneMac controls:copyNativeFilesStandaloneMac fxml:copyNativeFilesStandaloneMac graphics:copyNativeFilesStandaloneMac media:copyNativeFilesStandaloneMac swing:copyNativeFilesStandaloneMac web:copyNativeFilesStandaloneMac web:copyNativeMac web:copyPreGeneratedWrappers controls:copyShimBss base:copySourceFilesMac controls:copySourceFilesMac fxml:copySourceFilesMac graphics:copySourceFilesMac media:copySourceFilesMac swing:copySourceFilesMac web:copySourceFilesMac systemTests:copyTestapp2 systemTests:copyTestapp3 systemTests:copyTestapp4 systemTests:copyTestapp5 systemTests:copyTestapp6 systemTests:copyTestapp7 systemTests:copyTestscriptapp1 systemTests:copyTestscriptapp2 copyToArtifactsBundledSDKMac copyToArtifactsDocsApiMac copyToArtifactsExportsMac copyToArtifactsStandaloneSDKMac copyToArtifactsTestMac copyToysToArtifactsMac systemTests:createTestapp1Jar1 systemTests:createTestapp1Jar2 systemTests:createTestApps createTestArgfiles createTestArgfilesMac dependentComponents - Displays the dependent components of components in root project 'rt'. [deprecated] apps:dependentComponents - Displays the dependent components of components in project ':apps'. [deprecated] base:dependentComponents - Displays the dependent components of components in project ':base'. [deprecated] closedTests:dependentComponents - Displays the dependent components of components in project ':closedTests'. [deprecated] controls:dependentComponents - Displays the dependent components of components in project ':controls'. [deprecated] fxml:dependentComponents - Displays the dependent components of components in project ':fxml'. [deprecated] graphics:dependentComponents - Displays the dependent components of components in project ':graphics'. [deprecated] media:dependentComponents - Displays the dependent components of components in project ':media'. [deprecated] swing:dependentComponents - Displays the dependent components of components in project ':swing'. [deprecated] swt:dependentComponents - Displays the dependent components of components in project ':swt'. [deprecated] systemTests:dependentComponents - Displays the dependent components of components in project ':systemTests'. [deprecated] web:dependentComponents - Displays the dependent components of components in project ':web'. [deprecated] downloadJdkDocs web:drtJar findbugs graphics:generateDecoraShaders - Generate Decora shaders from JSL graphics:generateGrammarSource media:generateMediaErrorHeader graphics:generatePrismShaders - Generate Prism shaders from JSL apps:getLucene graphics:initShaderDirs jdkZip jmods graphics:linkDecoraNativeShadersMac - Creates native dynamic library for Decora SSE mac closedTests:manualTest mkdirArtifactsMac mkdirBundledSDKMac mkdirStandaloneSDKMac model - Displays the configuration model of root project 'rt'. [deprecated] apps:model - Displays the configuration model of project ':apps'. [deprecated] base:model - Displays the configuration model of project ':base'. [deprecated] closedTests:model - Displays the configuration model of project ':closedTests'. [deprecated] controls:model - Displays the configuration model of project ':controls'. [deprecated] fxml:model - Displays the configuration model of project ':fxml'. [deprecated] graphics:model - Displays the configuration model of project ':graphics'. [deprecated] media:model - Displays the configuration model of project ':media'. [deprecated] swing:model - Displays the configuration model of project ':swing'. [deprecated] swt:model - Displays the configuration model of project ':swt'. [deprecated] systemTests:model - Displays the configuration model of project ':systemTests'. [deprecated] web:model - Displays the configuration model of project ':web'. [deprecated] base:modularJarStandaloneMac controls:modularJarStandaloneMac fxml:modularJarStandaloneMac graphics:modularJarStandaloneMac media:modularJarStandaloneMac swing:modularJarStandaloneMac web:modularJarStandaloneMac base:modularPublicationJarMac controls:modularPublicationJarMac fxml:modularPublicationJarMac graphics:modularPublicationJarMac media:modularPublicationJarMac swing:modularPublicationJarMac web:modularPublicationJarMac base:moduleEmptyPublicationJarMac controls:moduleEmptyPublicationJarMac fxml:moduleEmptyPublicationJarMac graphics:moduleEmptyPublicationJarMac media:moduleEmptyPublicationJarMac swing:moduleEmptyPublicationJarMac web:moduleEmptyPublicationJarMac perf prepareKotlinBuildScriptModel prepOpenJfxStubs graphics:processDecoraShaders - Copy hlsl / frag shaders to build/resources/jsl-decora graphics:processDecoraShimsShaders - Copy hlsl / frag shaders to shims graphics:processJslcResources - Processes jslc resources. graphics:processPrismShaders - Copy hlsl / frag shaders to build/resources/jsl-prism graphics:processPrismShimsShaders - Copy hlsl / frag shaders to shims base:processResources - Processes main resources. closedTests:processResources - Processes main resources. controls:processResources - Processes main resources. fxml:processResources - Processes main resources. graphics:processResources - Processes main resources. media:processResources - Processes main resources. swing:processResources - Processes main resources. swt:processResources - Processes main resources. systemTests:processResources - Processes main resources. web:processResources - Processes main resources. graphics:processShaders graphics:processShadersResources - Processes shaders resources. base:processShimsResources - Processes shims resources. controls:processShimsResources - Processes shims resources. fxml:processShimsResources - Processes shims resources. graphics:processShimsResources - Processes shims resources. swing:processShimsResources - Processes shims resources. web:processShimsResources - Processes shims resources. graphics:processShimsShaders graphics:processStubResources - Processes stub resources. systemTests:processTestapp1Resources - Processes testapp1 resources. systemTests:processTestapp2Resources - Processes testapp2 resources. systemTests:processTestapp3Resources - Processes testapp3 resources. systemTests:processTestapp4Resources - Processes testapp4 resources. systemTests:processTestapp5Resources - Processes testapp5 resources. systemTests:processTestapp6Resources - Processes testapp6 resources. systemTests:processTestapp7Resources - Processes testapp7 resources. base:processTestResources - Processes test resources. closedTests:processTestResources - Processes test resources. controls:processTestResources - Processes test resources. fxml:processTestResources - Processes test resources. graphics:processTestResources - Processes test resources. media:processTestResources - Processes test resources. swing:processTestResources - Processes test resources. swt:processTestResources - Processes test resources. systemTests:processTestResources - Processes test resources. web:processTestResources - Processes test resources. systemTests:processTestscriptapp1Resources - Processes testscriptapp1 resources. systemTests:processTestscriptapp2Resources - Processes testscriptapp2 resources. media:processToolsResources - Processes tools resources. base:processVersionInfo - Replace params in VersionInfo and copy file to destination publicExports sdk shims showFlags showFlagsMAC systemTests:systemTestSetup testAntImport web:testWebArchiveJar updateCacheIfNeeded base:validateSourceSets controls:validateSourceSets fxml:validateSourceSets graphics:validateSourceSets media:validateSourceSets swing:validateSourceSets swt:validateSourceSets systemTests:validateSourceSets web:validateSourceSets verifyJava zipDocsMac zipJmodsMac zips zipSdkMac zipSourceFilesStandaloneMac From: Nir Lisker Date: Tuesday, June 18, 2024 at 17:30 To: Thiago Milczarek Say?o Cc: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Eclipse and Gradle in OpenJFX It has been a while since I tried a clean import of jfx, but the instructions in https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse seem correct, unless something changed. What you describe is written there. Only the initial import requires a gradle build, and after reverting the project and classpath changes, you can work with ECJ (unless you need tasks to build native code etc.) What is worth looking at is the 'eclipse' gradle task that tries to generate these files according to the gradle files. However, the way the project is built in gradle is both complicated and very old (compliant with gradle 2 I think), so I don't know how well that will work. In my modern projects, the 'eclipse' task works really well and allows me to not check in the eclipse files: a gradle refresh/synch is run once (does all the configuration and dependency management), and then running 'eclipse' once sets up the eclipse side. On Tue, Jun 18, 2024 at 10:52?PM Thiago Milczarek Say?o > wrote: Andy, We kind of did the opposite for Intellij (got rid of the .iml files and went for gradle import): https://github.com/openjdk/jfx/pull/1009 I couldn't get it to detect the manual tests tho. Changing some gradle files worked, but would require a deeper review, so we went without it. -- Thiago. Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev > escreveu: Dear developers: Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX repo? The reason I am asking is that in my experience, the gradle nature in OpenJFX is either misconfigured, or obsolete, or both. There is a rather old wiki page [0] which describes the Eclipse setup, though I don't think it is correct anymore. The initial import of the repository in Eclipse triggers an internal gradle run which creates/modifies a bunch of .classpath and .project files which must be undone before the workspace becomes usable. In any case, only a proper command line gradle build is supported anyway. I would like to propose removing the gradle nature from Eclipse's .project files in OpenJFX. Once done, the projects can be trivially imported into a new workspace with no extra steps required. This change has no impact on command line build whatsoever. What do you think? Thank you -andy References [1] https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Jun 20 15:38:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Jun 2024 15:38:16 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 02:25:54 GMT, Jay Bhaskar wrote: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. The code changes in the modified files looks good. I confirm that the newly added files match those same files in WebKit 616.1, accounting for the expected changes in the current WebKit. All my testing looks good. I left a couple minor comments on the test. I've approved it, and will re-approve after you update the test. tests/manual/web/WebSocketTestApp.java line 2: > 1: /* > 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. This file is new in 2024, so you can remove the `2022,` tests/manual/web/WebSocketTestApp.java line 62: > 60: failButton.setOnAction(e -> { > 61: Platform.exit(); > 62: throw new AssertionError("on paste the Data Nodes count is wrong."); The error message is wrong. It looks like a copy/paste from another test program. Something like "WebSocket connection failed" would be a better message. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1477#pullrequestreview-2130763098 PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1647771413 PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1647773017 From angorya at openjdk.org Thu Jun 20 16:39:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 16:39:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Wed, 19 Jun 2024 10:21:52 GMT, Markus Mack wrote: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. @drmarmac can you assign the ticket to yourself please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181110871 From mmack at openjdk.org Thu Jun 20 16:42:13 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 16:42:13 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Wed, 19 Jun 2024 10:21:52 GMT, Markus Mack wrote: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. ok, done! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181114706 From angorya at openjdk.org Thu Jun 20 16:55:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 16:55:16 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Wed, 19 Jun 2024 10:21:52 GMT, Markus Mack wrote: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 64: > 62: * which axis is a category axis. > 63: * > 64: * Adding data with multiple occurences of a category to a series shows the last occurence. you probably want to add

on line 63 this PR does not require CSR as the change in javadoc is mere clarification rather than a substantial API change. modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 215: > 213: if (!categoryAxis.getCategories().contains(category)) { > 214: // find category index in case data contains duplicate categories > 215: int i = series.getData().size() != categoryAxis.getCategories().size() ? series.getItemIndex(item) : this is clever: little impact on performance in the case of non-duplicate categories (the most common case). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647849149 PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647851273 From angorya at openjdk.org Thu Jun 20 16:55:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 16:55:17 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 16:50:23 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 215: >> >>> 213: if (!categoryAxis.getCategories().contains(category)) { >>> 214: // find category index in case data contains duplicate categories >>> 215: int i = series.getData().size() != categoryAxis.getCategories().size() ? series.getItemIndex(item) : >> >> this is clever: little impact on performance in the case of non-duplicate categories (the most common case). > > However, I don't see the issue if I just add a duplicate data point after the chart is rendered (the code jumps to line 218 in the master branch). > > This makes me think that perhaps the fix should include fixing the logic of adding category to the right hashtables at the right moment. What do you think? I've added a popup menu on the BarChart page in the Monkey Tester to test the case ... https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647871163 From angorya at openjdk.org Thu Jun 20 16:55:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 16:55:16 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 16:34:23 GMT, Andy Goryachev wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 215: > >> 213: if (!categoryAxis.getCategories().contains(category)) { >> 214: // find category index in case data contains duplicate categories >> 215: int i = series.getData().size() != categoryAxis.getCategories().size() ? series.getItemIndex(item) : > > this is clever: little impact on performance in the case of non-duplicate categories (the most common case). However, I don't see the issue if I just add a duplicate data point after the chart is rendered (the code jumps to line 218 in the master branch). This makes me think that perhaps the fix should include fixing the logic of adding category to the right hashtables at the right moment. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647868437 From mmack at openjdk.org Thu Jun 20 17:44:41 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 17:44:41 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: JavaDoc formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1476/files - new: https://git.openjdk.org/jfx/pull/1476/files/04433781..276717ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1476.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/jfx/pull/1476 From mmack at openjdk.org Thu Jun 20 17:53:18 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 17:53:18 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 16:52:49 GMT, Andy Goryachev wrote: >> However, I don't see the issue if I just add a duplicate data point after the chart is rendered (the code jumps to line 218 (edit: 216, sorry) in the master branch). >> >> This makes me think that perhaps the fix should include fixing the logic of adding category to the right hashtables at the right moment. What do you think? > > I've added a popup menu on the BarChart page in the Monkey Tester to test the case ... > https://github.com/andy-goryachev-oracle/MonkeyTest You'll need to add an additional point after adding the one with duplicate categories to see the exception in the console. Using the "Add Point" button in the monkey tester after using the context menu entry should reproduce the issue. Regarding category hashtables, do you have any specific issues in mind, or see any regressions due to this PR? Otherwise I'd suggest to create separate issues / failing tests and do follow-up PRs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647940331 From angorya at openjdk.org Thu Jun 20 18:02:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 18:02:16 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: <2ACwrh7LWNLJb3PX_mSbhlAiJlnAg_kJ0ke3PxaSu7k=.30eabdcc-2b3d-4a6b-9cc9-102f33935994@github.com> On Thu, 20 Jun 2024 17:50:20 GMT, Markus Mack wrote: >> I've added a popup menu on the BarChart page in the Monkey Tester to test the case ... >> https://github.com/andy-goryachev-oracle/MonkeyTest > > You'll need to add an additional point after adding the one with duplicate categories to see the exception in the console. Using the "Add Point" button in the monkey tester after using the context menu entry should reproduce the issue. > Regarding category hashtables, do you have any specific issues in mind, or see any regressions due to this PR? Otherwise I'd suggest to create separate issues / failing tests and do follow-up PRs. No, repeated invocation of the menu does not produce an exception. Maybe I am doing something wrong: void addDuplicateCategory() { var d = chart.getData(); if (d.size() > 0) { var dd = d.get(0).getData(); if (dd.size() > 0) { var v = dd.get(0); dd.add(new XYChart.Data(v.getXValue(), v.getYValue().doubleValue() + 1.0)); } } } As for the hashtables, I was just surprised to see the issue not reproducible with the menu. It is a different scenario, and I am trying to understand why the difference. The reason for my comment is that the code that checks for the sizes looks suspicious on the grounds that, when things are accounted for correctly, it should be unnecessary. The current fix does look a bit artificial. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647950248 From angorya at openjdk.org Thu Jun 20 18:25:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 18:25:20 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting This code does not work: Exception in thread "JavaFX Application Thread" java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 1 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) at java.base/java.util.Objects.checkIndex(Objects.java:385) at javafx.base/com.sun.javafx.collections.ObservableListWrapper.doAdd(ObservableListWrapper.java:98) at javafx.base/javafx.collections.ModifiableObservableListBase.add(ModifiableObservableListBase.java:196) at javafx.controls/javafx.scene.chart.BarChart.dataItemAdded(BarChart.java:218) at javafx.controls/javafx.scene.chart.XYChart.dataItemsChanged(XYChart.java:558) at javafx.controls/javafx.scene.chart.XYChart$Series$1.onChanged(XYChart.java:1556) at javafx.base/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162) at javafx.base/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71) at javafx.base/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246) at javafx.base/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482) at javafx.base/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541) at javafx.base/javafx.collections.ObservableListBase.endChange(ObservableListBase.java:210) at javafx.base/javafx.collections.ModifiableObservableListBase.add(ModifiableObservableListBase.java:200) at java.base/java.util.AbstractList.add(AbstractList.java:113) at monkey_tester/com.oracle.tools.fx.monkey.pages.BarChartPage.addDuplicateCategory(BarChartPage.java:86) at monkey_tester/com.oracle.tools.fx.monkey.util.FX.lambda$2(FX.java:145) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) at javafx.base/javafx.event.Event.fireEvent(Event.java:199) at javafx.controls/javafx.scene.control.MenuItem.fire(MenuItem.java:459) at javafx.controls/com.sun.javafx.scene.control.ContextMenuContent$MenuItemContainer.doSelect(ContextMenuContent.java:1426) at javafx.controls/com.sun.javafx.scene.control.ContextMenuContent$MenuItemContainer.lambda$12(ContextMenuContent.java:1379) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:199) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3987) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1893) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2711) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:128) To reproduce: - run the **latest** Monkey Tester - select BarChart - just in case, I am going to attach a screenshot of the settings - right click on chart, select "Add Duplicate Category" item **twice** - right click, select "Add Series with Duplicate Category" - BOOM ![Screenshot 2024-06-20 at 11 21 49](https://github.com/openjdk/jfx/assets/107069028/c0c92c5b-b602-4821-948d-6ec0f91683bb) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181282900 From mmack at openjdk.org Thu Jun 20 18:28:15 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 18:28:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: <2ACwrh7LWNLJb3PX_mSbhlAiJlnAg_kJ0ke3PxaSu7k=.30eabdcc-2b3d-4a6b-9cc9-102f33935994@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <2ACwrh7LWNLJb3PX_mSbhlAiJlnAg_kJ0ke3PxaSu7k=.30eabdcc-2b3d-4a6b-9cc9-102f33935994@github.com> Message-ID: On Thu, 20 Jun 2024 17:59:13 GMT, Andy Goryachev wrote: >> You'll need to add an additional point after adding the one with duplicate categories to see the exception in the console. Using the "Add Point" button in the monkey tester after using the context menu entry should reproduce the issue. >> Regarding category hashtables, do you have any specific issues in mind, or see any regressions due to this PR? Otherwise I'd suggest to create separate issues / failing tests and do follow-up PRs. > > No, repeated invocation of the menu does not produce an exception. Maybe I am doing something wrong: > > > void addDuplicateCategory() { > var d = chart.getData(); > if (d.size() > 0) { > var dd = d.get(0).getData(); > if (dd.size() > 0) { > var v = dd.get(0); > dd.add(new XYChart.Data(v.getXValue(), v.getYValue().doubleValue() + 1.0)); > } > } > } > > > As for the hashtables, I was just surprised to see the issue not reproducible with the menu. It is a different scenario, and I am trying to understand why the difference. > > The reason for my comment is that the code that checks for the sizes looks suspicious on the grounds that, when things are accounted for correctly, it should be unnecessary. The current fix does look a bit artificial. The second added Point specifically needs to be in another, later category for this issue to occur - I created such a point in the monkey tester with the "Add Point" button to the right, not by repeatedly using the new context menu. Maybe try multiple times (depending on how the points random values are implemented there?) Regarding categories: My understanding is that `series.getData()` is supposed to include all data, including duplicates. On the other hand, `categoryAxis.getCategories()` only contains distinct categories. So the new insertion index of the category of a (not necessarily duplicate) newly added point needs to be shifted only if there are any previous duplicates with lower indices. Thus, I think everything is accounted for correctly unless I'm missing something. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1647976604 From mmack at openjdk.org Thu Jun 20 18:47:13 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 18:47:13 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting I'm not able to reproduce this with either master or this PR, can you check if that was the correct order? Note that `chart.getData().getFirst().setData(list);` in `addDuplicateSeries` in the monkey tester actually replaces the data of the previous series, not the newly added one. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181315671 From angorya at openjdk.org Thu Jun 20 19:01:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 19:01:16 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting My apologies! The steps to reproduce (swap the two menus): - run the latest Monkey Tester - select BarChart - right click on chart, select "Add Series with Duplicate Category" item twice - right click, select "Add Duplicate Category" ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181340868 From angorya at openjdk.org Thu Jun 20 19:05:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 19:05:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: <0usiz61HTfF5nlW0_USc_hWH2CwkDADUuJPFiMYIYOM=.287708b9-6dd2-4488-9056-b55e1310955f@github.com> On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting Also (this might be a separate issue), repeated invocation of "Add Series with Duplicate Category" menu causes XAxis legend to display ever increasing number of series: ![Screenshot 2024-06-20 at 11 59 46](https://github.com/openjdk/jfx/assets/107069028/33402fe5-5ef9-43b0-9333-22fd68338ee9) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181346168 From mmack at openjdk.org Thu Jun 20 19:14:15 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 20 Jun 2024 19:14:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting Thanks, I can reproduce this now, both in master and this PR, so it may even be another unrelated issue. I can have a look if it actually touches this PR or not. The legends being added in your screenshot are correct, that's actually what the monkey tester method is currently doing (adding empty series, because the code just modifies the first series). However, the tick marks on the axis are in incorrect places (which I'm pretty sure is the next unrelated bug...) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181359648 From angorya at openjdk.org Thu Jun 20 19:26:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 20 Jun 2024 19:26:14 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: <3uMoOAV_K6OnWLXS-K6EOnyaQiiLf6Nbk92SoovRWgY=.ba466d49-6967-484a-8de6-d3152e0d88d3@github.com> On Thu, 20 Jun 2024 19:11:48 GMT, Markus Mack wrote: > adding empty series ah, right! > the tick marks on the axis are in incorrect this might be [JDK-8314754](https://bugs.openjdk.org/browse/JDK-8314754) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2181376320 From jbhaskar at openjdk.org Thu Jun 20 23:21:48 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 20 Jun 2024 23:21:48 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v2] In-Reply-To: References: Message-ID: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: adding review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1477/files - new: https://git.openjdk.org/jfx/pull/1477/files/17cc3f1f..32a447a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1477.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1477/head:pull/1477 PR: https://git.openjdk.org/jfx/pull/1477 From jbhaskar at openjdk.org Thu Jun 20 23:21:48 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 20 Jun 2024 23:21:48 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 15:30:03 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> adding review comments > > tests/manual/web/WebSocketTestApp.java line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. > > This file is new in 2024, so you can remove the `2022,` done > tests/manual/web/WebSocketTestApp.java line 62: > >> 60: failButton.setOnAction(e -> { >> 61: Platform.exit(); >> 62: throw new AssertionError("on paste the Data Nodes count is wrong."); > > The error message is wrong. It looks like a copy/paste from another test program. Something like "WebSocket connection failed" would be a better message. looks good, will do ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648231491 PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648231716 From kcr at openjdk.org Thu Jun 20 23:51:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Jun 2024 23:51:14 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v2] In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 23:21:48 GMT, Jay Bhaskar wrote: >> Issue: The Websocket Channel is broken >> Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > adding review comments tests/manual/web/WebSocketTestApp.java line 62: > 60: failButton.setOnAction(e -> { > 61: Platform.exit(); > 62: throw new AssertionError("!Unable to received meesgae data from server, something is wrong"); Better, but there are typos: "received meesgae " --> "receive message" ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648265147 From jbhaskar at openjdk.org Thu Jun 20 23:55:53 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 20 Jun 2024 23:55:53 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v3] In-Reply-To: References: Message-ID: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Fix typos ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1477/files - new: https://git.openjdk.org/jfx/pull/1477/files/32a447a4..768b4011 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1477.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1477/head:pull/1477 PR: https://git.openjdk.org/jfx/pull/1477 From jbhaskar at openjdk.org Thu Jun 20 23:55:53 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 20 Jun 2024 23:55:53 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v2] In-Reply-To: References: Message-ID: <7Vvr3lJb_2OYyH4kZJ9Kknl8UMd1Irri-IL7zOL6ibw=.8a76102c-4e15-4c36-9949-c360b682fdee@github.com> On Thu, 20 Jun 2024 23:48:32 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> adding review comments > > tests/manual/web/WebSocketTestApp.java line 62: > >> 60: failButton.setOnAction(e -> { >> 61: Platform.exit(); >> 62: throw new AssertionError("!Unable to received meesgae data from server, something is wrong"); > > Better, but there are typos: > > "received meesgae " --> "receive message" done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648266839 From kcr at openjdk.org Thu Jun 20 23:58:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 20 Jun 2024 23:58:15 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v3] In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 23:55:53 GMT, Jay Bhaskar wrote: >> Issue: The Websocket Channel is broken >> Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos tests/manual/web/WebSocketTestApp.java line 50: > 48: new Label(" 1. Click on RunTest button"), > 49: new Label(" "), > 50: new Label(" 2. Expected behaviour: Data received from server meesgae should appear on webview")); Typo: "meesgae" --> "message". tests/manual/web/WebSocketTestApp.java line 62: > 60: failButton.setOnAction(e -> { > 61: Platform.exit(); > 62: throw new AssertionError("!Unable to receive meesgae data from server, something is wrong"); You fixed one of the two typos. "message" is still spelled wrong (as I mentioned in my last comment). I found one other occurrence of that typo, so I noted that as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648268353 PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648268240 From jbhaskar at openjdk.org Fri Jun 21 00:07:33 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jun 2024 00:07:33 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v4] In-Reply-To: References: Message-ID: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Fix typos meesage to message ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1477/files - new: https://git.openjdk.org/jfx/pull/1477/files/768b4011..30b8e199 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1477&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1477.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1477/head:pull/1477 PR: https://git.openjdk.org/jfx/pull/1477 From kcr at openjdk.org Fri Jun 21 00:07:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 00:07:33 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v4] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 00:04:42 GMT, Jay Bhaskar wrote: >> Issue: The Websocket Channel is broken >> Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos meesage to message Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1477#pullrequestreview-2131578806 From jbhaskar at openjdk.org Fri Jun 21 00:07:34 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jun 2024 00:07:34 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v3] In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 23:55:16 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > tests/manual/web/WebSocketTestApp.java line 62: > >> 60: failButton.setOnAction(e -> { >> 61: Platform.exit(); >> 62: throw new AssertionError("!Unable to receive meesgae data from server, something is wrong"); > > You fixed one of the two typos. "message" is still spelled wrong (as I mentioned in my last comment). I found one other occurrence of that typo, so I noted that as well. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648270889 From jbhaskar at openjdk.org Fri Jun 21 00:07:34 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jun 2024 00:07:34 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v3] In-Reply-To: References: Message-ID: <8qKGupudeckOw4kS1kc_m9CaQGIePMyBTLbJ_eAcewY=.dfd1b158-5ccb-41f7-aff2-423c93414352@github.com> On Fri, 21 Jun 2024 00:01:21 GMT, Jay Bhaskar wrote: >> tests/manual/web/WebSocketTestApp.java line 62: >> >>> 60: failButton.setOnAction(e -> { >>> 61: Platform.exit(); >>> 62: throw new AssertionError("!Unable to receive meesgae data from server, something is wrong"); >> >> You fixed one of the two typos. "message" is still spelled wrong (as I mentioned in my last comment). I found one other occurrence of that typo, so I noted that as well. > > done done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648270951 From sykora at openjdk.org Fri Jun 21 09:01:17 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 21 Jun 2024 09:01:17 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v4] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 00:07:33 GMT, Jay Bhaskar wrote: >> Issue: The Websocket Channel is broken >> Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos meesage to message Everything still built fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1477#pullrequestreview-2132158211 From aoqi at openjdk.org Fri Jun 21 09:07:29 2024 From: aoqi at openjdk.org (Ao Qi) Date: Fri, 21 Jun 2024 09:07:29 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Message-ID: This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. Error log: /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." 140 | #error "Unsupported platform: need implementation of currentStackPointer." | ^~~~~ make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 ------------- Commit messages: - 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Changes: https://git.openjdk.org/jfx/pull/1482/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1482&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334713 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1482.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1482/head:pull/1482 PR: https://git.openjdk.org/jfx/pull/1482 From kcr at openjdk.org Fri Jun 21 11:27:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 11:27:13 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 09:02:43 GMT, Ao Qi wrote: > This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. > > Error log: > > > /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." > 140 | #error "Unsupported platform: need implementation of currentStackPointer." > | ^~~~~ > make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 Reviewers: @jaybhaskar @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1482#issuecomment-2182563557 From hmeda at openjdk.org Fri Jun 21 12:36:18 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 21 Jun 2024 12:36:18 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v4] In-Reply-To: References: Message-ID: <8tz0NwmcPoI4b3T4dEWmyyiRPYecyEqDO7X3zUqFtis=.68726082-a2f7-4d4e-86e9-479345cab250@github.com> On Fri, 21 Jun 2024 00:07:33 GMT, Jay Bhaskar wrote: >> Issue: The Websocket Channel is broken >> Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos meesage to message Changes look fine tests/manual/web/WebSocketTestApp.java line 70: > 68: loadButton.setOnAction(e -> { > 69: URL url = this.getClass().getResource("websocket.html"); > 70: System.out.println(url); Minor:Is it required to print url in the terminal? ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1477#pullrequestreview-2132540876 PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648894257 From jbhaskar at openjdk.org Fri Jun 21 12:41:15 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jun 2024 12:41:15 GMT Subject: RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update [v4] In-Reply-To: <8tz0NwmcPoI4b3T4dEWmyyiRPYecyEqDO7X3zUqFtis=.68726082-a2f7-4d4e-86e9-479345cab250@github.com> References: <8tz0NwmcPoI4b3T4dEWmyyiRPYecyEqDO7X3zUqFtis=.68726082-a2f7-4d4e-86e9-479345cab250@github.com> Message-ID: <0SZ__2WVkRSINtbxXUqY4_-rSfoROTh7LP0KMB4DATE=.78ef63b5-de68-4f60-b0d6-796bf83f5af4@github.com> On Fri, 21 Jun 2024 12:25:20 GMT, Hima Bindu Meda wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos meesage to message > > tests/manual/web/WebSocketTestApp.java line 70: > >> 68: loadButton.setOnAction(e -> { >> 69: URL url = this.getClass().getResource("websocket.html"); >> 70: System.out.println(url); > > Minor:Is it required to print url in the terminal? Not required ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1477#discussion_r1648908187 From jbhaskar at openjdk.org Fri Jun 21 12:44:18 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 21 Jun 2024 12:44:18 GMT Subject: Integrated: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: References: Message-ID: On Thu, 20 Jun 2024 02:25:54 GMT, Jay Bhaskar wrote: > Issue: The Websocket Channel is broken > Solution: The socket Provider needs a web page pointer, since the web socket channel source code is moved to WebkitLegacy in 617.1 for the web process model, it is invalid for JavaFx Webkit. This pull request has now been integrated. Changeset: 6a586b66 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod 8331765: Websocket callbacks are not executed after WebKit 617.1 update Reviewed-by: kcr, sykora, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/1477 From kcr at openjdk.org Fri Jun 21 12:58:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 12:58:37 GMT Subject: RFR: 8334657: Enable binary check Message-ID: This PR enables two warnings that are now (or soon will be) enabled in the [jdk](https://github.com/openjdk/jdk) repo: 1. Binary file check -- this will alert the reviewers of a PR that the patch being reviewed includes one or more binary files. 2. Issue title check -- this will check for two common (minor) formatting issues with the JBS title and matching PR title, a trailing period or a leading lower-case word. Both are informational warnings that will not block integration. To see how the warnings look, refer to the following Draft PRs: 1. PR with binary file: #1478 2. PR for bug with trailing period: #1479 ------------- Commit messages: - 8334657: Enable binary check Changes: https://git.openjdk.org/jfx/pull/1483/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334657 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1483.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1483/head:pull/1483 PR: https://git.openjdk.org/jfx/pull/1483 From kcr at openjdk.org Fri Jun 21 13:21:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 13:21:14 GMT Subject: RFR: 8334657: Enable binary check In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 12:50:45 GMT, Kevin Rushforth wrote: > This PR enables two warnings that are now (or soon will be) enabled in the [jdk](https://github.com/openjdk/jdk) repo: > > 1. Binary file check -- this will alert the reviewers of a PR that the patch being reviewed includes one or more binary files. > 2. Issue title check -- this will check for two common (minor) formatting issues with the JBS title and matching PR title, a trailing period or a leading lower-case word. > > Both are informational warnings that will not block integration. > > To see how the warnings look, refer to the following Draft PRs: > > 1. PR with binary file: #1478 > 2. PR for bug with trailing period: #1479 Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1483#issuecomment-2182740147 From mmack at openjdk.org Fri Jun 21 15:22:41 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 15:22:41 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v3] In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: additional BarChart tests & updated fix: Insert new categories according to the concatenation of the data of all series, skipping duplicates ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1476/files - new: https://git.openjdk.org/jfx/pull/1476/files/276717ab..7fd81ad5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=01-02 Stats: 73 lines in 2 files changed: 69 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1476.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/jfx/pull/1476 From mmack at openjdk.org Fri Jun 21 15:22:41 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 15:22:41 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v2] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Thu, 20 Jun 2024 17:44:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > JavaDoc formatting Turns out this problem is even worse. If there are multiple series, and some data has duplicate categories within one or across multiple series, the insertion index on the category axis could be more or less anywhere. I've enhanced the fix by choosing an ordering of the categories on the axis according to the concatenation of the data of each series, skipping duplicates. I've added some more unit tests, and checked the manual monkey tester issue discussed above as well. Note this category ordering on the axis is not necessarily maintained, e.g. removing previously duplicate data items might cause some rather arbitrary ordering again, so it's probably not safe to optimize this much more without much more control over the methods being called. Performance is still O(n) per item added, however n now is the sum of all categories of all series. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2182954403 From kcr at openjdk.org Fri Jun 21 15:27:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 15:27:22 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 Message-ID: GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). ------------- Commit messages: - 8334731: GHA: build on macOS / aarch64 Changes: https://git.openjdk.org/jfx/pull/1484/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1484&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334731 Stats: 86 lines in 1 file changed: 86 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1484.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1484/head:pull/1484 PR: https://git.openjdk.org/jfx/pull/1484 From angorya at openjdk.org Fri Jun 21 15:33:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 15:33:15 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 15:22:57 GMT, Kevin Rushforth wrote: > GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). .github/workflows/submit.yml line 231: > 229: > 230: > 231: macos_aarch64_build: should we add a note at the beginning of the file warning about attempting to modify one target vs. possibly propagating the changes to all targets? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1484#discussion_r1649120035 From kcr at openjdk.org Fri Jun 21 15:50:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 15:50:31 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 [v2] In-Reply-To: References: Message-ID: > GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Add a note about duplicated logic ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1484/files - new: https://git.openjdk.org/jfx/pull/1484/files/ef2c221b..8efda242 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1484&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1484&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1484.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1484/head:pull/1484 PR: https://git.openjdk.org/jfx/pull/1484 From kcr at openjdk.org Fri Jun 21 15:50:31 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 15:50:31 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 15:30:50 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a note about duplicated logic > > .github/workflows/submit.yml line 231: > >> 229: >> 230: >> 231: macos_aarch64_build: > > should we add a note at the beginning of the file warning about attempting to modify one target vs. possibly propagating the changes to all targets? Good idea. I added a NOTE ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1484#discussion_r1649141723 From angorya at openjdk.org Fri Jun 21 15:59:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 15:59:15 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 [v2] In-Reply-To: References: Message-ID: <2HdAlynXL14FuNbyhILnHogCzBPYccQevd77h6SP_Jc=.afc02a1e-ee4b-4eb6-82b6-f5fc973b48bc@github.com> On Fri, 21 Jun 2024 15:50:31 GMT, Kevin Rushforth wrote: >> GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add a note about duplicated logic weird: the detail view shows the macOS aarch64 target has completed, but the PR checks displays it as running still... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1484#issuecomment-2183018916 From angorya at openjdk.org Fri Jun 21 16:05:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 16:05:14 GMT Subject: RFR: 8334731: GHA: build on macOS / aarch64 [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 15:50:31 GMT, Kevin Rushforth wrote: >> GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Add a note about duplicated logic all targets run successfully, looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1484#pullrequestreview-2132975900 From mmack at openjdk.org Fri Jun 21 16:15:20 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 16:15:20 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean Message-ID: This PR makes the `XYChart` axes properties return the correct parent XYChart object. ------------- Commit messages: - XYChart: Set correct bean of axes properties Changes: https://git.openjdk.org/jfx/pull/1485/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334739 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1485.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1485/head:pull/1485 PR: https://git.openjdk.org/jfx/pull/1485 From angorya at openjdk.org Fri Jun 21 16:26:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 16:26:14 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:11:52 GMT, Markus Mack wrote: > This PR makes the `XYChart` axes properties return the correct parent XYChart object. I am wondering if we have more cases like that. Would it be possible to have a unit test to scan over a set of Controls + Shapes + any other classes looking for public properties and checking their `getBean()` values? Is that even possible @kevinrushforth ? This might be a separate issue though. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183059452 From angorya at openjdk.org Fri Jun 21 16:49:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 16:49:14 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:11:52 GMT, Markus Mack wrote: > This PR makes the `XYChart` axes properties return the correct parent XYChart object. Searched for `public Object getBean() {` For class names A-C found one hit: AreaChart.createSymbols line 109 which means there might be more, but manual scanning of 1,752 total hits might take some time... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183094361 From mmack at openjdk.org Fri Jun 21 16:57:38 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 16:57:38 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean [v2] In-Reply-To: References: Message-ID: > This PR makes the `XYChart` axes properties return the correct parent XYChart object. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: Set correct bean for properties in AreaChart / StackedAreaChart ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1485/files - new: https://git.openjdk.org/jfx/pull/1485/files/25610ea1..761c82a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1485&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1485&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1485.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1485/head:pull/1485 PR: https://git.openjdk.org/jfx/pull/1485 From mmack at openjdk.org Fri Jun 21 16:57:39 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 16:57:39 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:11:52 GMT, Markus Mack wrote: > This PR makes the `XYChart` axes properties return the correct parent XYChart object. in `StackedAreaChart` there's another one ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183103384 From angorya at openjdk.org Fri Jun 21 17:02:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 17:02:14 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:57:38 GMT, Markus Mack wrote: >> This PR makes the `XYChart` axes properties return the correct parent XYChart object. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > Set correct bean for properties in AreaChart / StackedAreaChart Looks good. Please wait 24 hrs for other people to weigh in. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1485#pullrequestreview-2133078931 From kcr at openjdk.org Fri Jun 21 17:15:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 17:15:15 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:57:38 GMT, Markus Mack wrote: >> This PR makes the `XYChart` axes properties return the correct parent XYChart object. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > Set correct bean for properties in AreaChart / StackedAreaChart Since this fix now includes two other chart classes, maybe change the JBS title (and, correspondingly this PR title) to something a little more generic that would cover them? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183133492 From kcr at openjdk.org Fri Jun 21 17:15:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 17:15:14 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean In-Reply-To: References: Message-ID: <8kSprm1D_Q5ntcvXtzf71OQT7WeL9WMeGt5y36JTzhc=.9d1dd58b-8ffd-4ea4-bfd9-473eeccd025a@github.com> On Fri, 21 Jun 2024 16:23:15 GMT, Andy Goryachev wrote: > Would it be possible to have a unit test to scan over a set of Controls + Shapes + any other classes looking for public properties and checking their `getBean()` values? Is that even possible @kevinrushforth ? This might be a separate issue though. It seems like it ought to be possible to write such a test. Thinking out loud, perhaps the test could take a list of JavaFX object instances (since we need an instance to inspect the bean, and not all of our classes have a no-arg constructor), and for each object enumerate the methods of its class -- including the superclass methods up the chain -- looking for methods named `xxxProperty` whose return type implements `javafx.beans.property.ReadOnlyProperty`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183130982 From kcr at openjdk.org Fri Jun 21 17:33:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 21 Jun 2024 17:33:14 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean In-Reply-To: <8kSprm1D_Q5ntcvXtzf71OQT7WeL9WMeGt5y36JTzhc=.9d1dd58b-8ffd-4ea4-bfd9-473eeccd025a@github.com> References: <8kSprm1D_Q5ntcvXtzf71OQT7WeL9WMeGt5y36JTzhc=.9d1dd58b-8ffd-4ea4-bfd9-473eeccd025a@github.com> Message-ID: On Fri, 21 Jun 2024 17:11:02 GMT, Kevin Rushforth wrote: > It seems like it ought to be possible to write such a test. Oh, and definitely a separate issue and not urgent (maybe a good test sprint bug). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183159670 From angorya at openjdk.org Fri Jun 21 17:59:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 17:59:13 GMT Subject: RFR: 8334739: XYChart.x/yAxisProperty returns incorrect bean [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:57:38 GMT, Markus Mack wrote: >> This PR makes the `XYChart` axes properties return the correct parent XYChart object. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > Set correct bean for properties in AreaChart / StackedAreaChart Created umbrella task https://bugs.openjdk.org/browse/JDK-8334744 Currently only mentions the getBean(), but I am sure we can test other invariants. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183193457 From angorya at openjdk.org Fri Jun 21 18:21:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 18:21:20 GMT Subject: RFR: 8334739: XYChart and (Stacked)AreaChart properties return incorrect beans In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:52:28 GMT, Markus Mack wrote: >> This PR makes the `XYChart` axes properties return the correct parent XYChart object. > > in `StackedAreaChart` there's another one Thank you @drmarmac for logging and fixing this and the other bugs! We'll integrate on Monday if no other feedback is received. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2183225387 From emilia.lopezf.1999 at gmail.com Fri Jun 21 18:54:53 2024 From: emilia.lopezf.1999 at gmail.com (=?UTF-8?Q?Emilia_L=C3=B3pez?=) Date: Fri, 21 Jun 2024 15:54:53 -0300 Subject: Building Images in FXML Message-ID: Hi :) I am currently working on an app that loads its layouts from FXML, everything is working great so far* and I am somewhat impressed by the myriad of things you can define in that format. *However I have encountered one issue having ImageViews with Images declared in the FXML, everything works great until I try to define one of the Image properties (for the `@NamedArg`uments) as a nested XML attribute, in my case I want to bring the Image URL from a constant: I get the following error (JavaFX 17.0.11): javafx.fxml.LoadException: file:/home/emilia/projects/java/planta-produccion/planta-produccion/build/libs/planta-produccion-1.13-SNAPSHOT.jar!/fxml/Primary.fxml:261 at javafx.fxml/javafx.fxml.FXMLLoader.constructLoadException(FXMLLoader.java:2714) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2692) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2555) at javafx.fxml/javafx.fxml.FXMLLoader.load(FXMLLoader.java:2523) at ar.emily.plantaproduccion.controller.Controller.load(Controller.java:24) ... 11 more Caused by: java.lang.UnsupportedOperationException at javafx.fxml/com.sun.javafx.fxml.builder.JavaFXImageBuilder.entrySet(JavaFXImageBuilder.java:77) at java.base/java.util.AbstractMap.containsKey(AbstractMap.java:144) at javafx.fxml/javafx.fxml.FXMLLoader$PropertyElement.(FXMLLoader.java:1381) at javafx.fxml/javafx.fxml.FXMLLoader.createElement(FXMLLoader.java:2869) at javafx.fxml/javafx.fxml.FXMLLoader.processStartElement(FXMLLoader.java:2842) at javafx.fxml/javafx.fxml.FXMLLoader.loadImpl(FXMLLoader.java:2641) ... 14 more My workaround for that was to have a custom ImageBuilder and a BuilderFactory for it that I add to the FXMLLoader, but this also raises a problem with IntelliJ IDEA's Scene Builder integration, since I can't add those to its FXMLLoader it will fail to load the layouts with essentially the same error. I was wondering if someone knows/is aware about this and if there's a better approach or solution than a custom builder, (granted that JavaFXImageBuilder is basically just a Map, but having a custom builder also means that I will miss out on future changes to the default image builder unless I check for them whenever we upgrade JDK/JFX versions). Cheers, Emilia L?pez. From kevin.rushforth at oracle.com Fri Jun 21 19:08:10 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Jun 2024 12:08:10 -0700 Subject: Proposed schedule for JavaFX 23 In-Reply-To: References: Message-ID: <2afbe768-e977-4b60-a589-653b82b72959@oracle.com> As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 23 starts on July 11, 2024 at 16:00 UTC (09:00 Pacific time), a little less than three weeks from now. Please allow sufficient time for any feature that needs a CSR. Given that we are entering the summer holiday season, and with the upcoming July 4th US holiday, there may be some delays. New features should be far enough along in the review process that you can finalize the CSR by Tuesday, July 2, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 24. During rampdown of JavaFX 23, the "master" branch of the jfx repo will be open for JavaFX 24 fixes, including enhancements. We will follow the same process as in previous releases for getting fixes into JavaFX 23 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/8/2024 11:31 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 23. > > RDP1: Jul 11, 2024 (aka ?feature freeze?) > RDP2: Aug 1, 2024 > Freeze: Aug 29, 2024 > GA: Sep 17, 2024 > > We plan to fork a jfx23 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 Fri Jun 21 20:08:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 20:08:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v3] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Fri, 21 Jun 2024 15:22:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > additional BarChart tests & updated fix: Insert new categories according to the concatenation of the data of all series, skipping duplicates Looks good to me. I'd like a second reviewer to take a look at this. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1476#pullrequestreview-2133346143 From mstrauss at openjdk.org Fri Jun 21 20:15:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 Jun 2024 20:15:14 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v3] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Fri, 21 Jun 2024 15:22:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > additional BarChart tests & updated fix: Insert new categories according to the concatenation of the data of all series, skipping duplicates The changes look good. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1476#pullrequestreview-2133355545 From mmack at openjdk.org Fri Jun 21 22:10:42 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 22:10:42 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v4] In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: testAddingDataAtIndex & fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1476/files - new: https://git.openjdk.org/jfx/pull/1476/files/7fd81ad5..6c0ccb80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=02-03 Stats: 38 lines in 2 files changed: 36 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1476.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/jfx/pull/1476 From mmack at openjdk.org Fri Jun 21 22:10:42 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 21 Jun 2024 22:10:42 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v3] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Fri, 21 Jun 2024 15:22:41 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > additional BarChart tests & updated fix: Insert new categories according to the concatenation of the data of all series, skipping duplicates The last implementation could have caused a regression if anyone relied on the previous ordering when there are no duplicates and an insertion is made within a series. I've updated the algorithm and added unit tests to ensure this should now be consistent with the previous behavior, and also works when there are duplicates. @andy-goryachev-oracle @mstr2 Please re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2183523702 From angorya at openjdk.org Fri Jun 21 22:10:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 22:10:43 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v4] In-Reply-To: <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> Message-ID: On Fri, 21 Jun 2024 22:07:22 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > testAddingDataAtIndex & fix modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 227: > 225: var uniqueCategories = new HashSet(); > 226: for (var entry : seriesCategoryMap.entrySet()) { > 227: Series s = entry.getKey(); would it make sense to add a comment explaining the reasoning for this more complex code? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1649465456 From angorya at openjdk.org Fri Jun 21 23:08:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 21 Jun 2024 23:08:16 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v4] In-Reply-To: <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> Message-ID: On Fri, 21 Jun 2024 22:10:42 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > testAddingDataAtIndex & fix Found another problem. It looks like it is present in the master branch, so this is a separate issue. To reproduce with the Monkey Tester: - select bar chart page - right click, select "Add Series with Duplicate Category" twice - click "Add Series" button on the right, under XY Chart - resize the chart using the split pane on the right (or vertically) The series added via context menu are not getting resized This may or may not be related to https://bugs.openjdk.org/browse/JDK-8314754 ![Screenshot 2024-06-21 at 15 59 15](https://github.com/openjdk/jfx/assets/107069028/6bfe3391-8af0-44cd-b961-5cf184b60040) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2183563587 From mmack at openjdk.org Sat Jun 22 10:55:28 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 22 Jun 2024 10:55:28 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: add javadoc clarification ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1476/files - new: https://git.openjdk.org/jfx/pull/1476/files/6c0ccb80..7a943fcf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1476&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1476.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1476/head:pull/1476 PR: https://git.openjdk.org/jfx/pull/1476 From mmack at openjdk.org Sat Jun 22 10:55:29 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 22 Jun 2024 10:55:29 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v4] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> Message-ID: On Fri, 21 Jun 2024 22:07:22 GMT, Andy Goryachev wrote: >> Markus Mack has updated the pull request incrementally with one additional commit since the last revision: >> >> testAddingDataAtIndex & fix > > modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 227: > >> 225: var uniqueCategories = new HashSet(); >> 226: for (var entry : seriesCategoryMap.entrySet()) { >> 227: Series s = entry.getKey(); > > would it make sense to add a comment explaining the reasoning for this more complex code? I've extended the code comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1649628640 From mmack at openjdk.org Sat Jun 22 11:01:15 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 22 Jun 2024 11:01:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: <-N4xBT7h2xi1WwkVsZuqbEja4uGdinYtL87PFTwm6v4=.a0b74760-f37c-44d7-963e-fac7bd55fc9b@github.com> On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification I can reproduce this, looks unrelated to the issue this PR is trying to fix. The category axis entries look reasonable, while the calculated plot coordinates are off. Not sure if this is the same as [8314754](https://bugs.openjdk.org/browse/JDK-8314754) either, probabaly should get its own ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2183979660 From kcr at openjdk.org Sat Jun 22 13:37:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Jun 2024 13:37:30 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor [v2] In-Reply-To: References: Message-ID: > This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. > > We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: > > * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" > * `TOOL_LINT` - used when compiling tool tasks : default = "" > * `TEST_LINT` - used when compiling test tasks : default = "" > > Each property takes a string with a comma-separated list of lint options. For example: > > > gradle -PLINT="deprecation,removal" sdk > > > I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. > > While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. > > I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. 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. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8327255-lint-removal,missing-explicit-ctor - fix typo and add missing tool tasks - 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods - 8334143: Suppress remaining removal warnings for internal methods and classes - 8327255: javac lint warnings: removal, missing-explicit-ctor ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1474/files - new: https://git.openjdk.org/jfx/pull/1474/files/1d90c796..753d5377 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1474&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1474&range=00-01 Stats: 5235 lines in 61 files changed: 5136 ins; 36 del; 63 mod Patch: https://git.openjdk.org/jfx/pull/1474.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1474/head:pull/1474 PR: https://git.openjdk.org/jfx/pull/1474 From kcr at openjdk.org Sat Jun 22 13:37:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 22 Jun 2024 13:37:30 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor [v2] In-Reply-To: <5Bg_gRafYBx8lY4rPmPd5Z3UHvQXJSt3iJD3LlIdwe4=.dfd26532-bc35-46c0-aeed-a9b690100db0@github.com> References: <5Bg_gRafYBx8lY4rPmPd5Z3UHvQXJSt3iJD3LlIdwe4=.dfd26532-bc35-46c0-aeed-a9b690100db0@github.com> Message-ID: On Tue, 18 Jun 2024 14:16:25 GMT, Ambarish Rapte wrote: >> 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. The pull request contains five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8327255-lint-removal,missing-explicit-ctor >> - fix typo and add missing tool tasks >> - 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods >> - 8334143: Suppress remaining removal warnings for internal methods and classes >> - 8327255: javac lint warnings: removal, missing-explicit-ctor > > build.gradle line 4139: > >> 4137: } >> 4138: } else if (compile.name == "compileJslcJava" || >> 4139: compile.name == "compileToolJava") { > > Should we include the _compileToolsJava_ task from media too ? That was a typo: "compileToolJava" should have been "compileToolsJava". While checking this, I also found that I missed two other tools tasks, "compileDecoraCompilers" and "compilePrismCompilers", so I added them as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1474#discussion_r1649699902 From mstrauss at openjdk.org Sat Jun 22 15:52:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 Jun 2024 15:52:14 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1476#pullrequestreview-2133846362 From jvos at openjdk.org Mon Jun 24 13:52:30 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 24 Jun 2024 13:52:30 GMT Subject: [jfx17u] RFR: 8301312: Create implementation of NSAccessibilityButton protocol Message-ID: 8301312: Create implementation of NSAccessibilityButton protocol ------------- Commit messages: - Backport 05548ace27f099a5ce152e3fb9efb4d22da683c8 Changes: https://git.openjdk.org/jfx17u/pull/193/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301312 Stats: 421 lines in 7 files changed: 372 ins; 41 del; 8 mod Patch: https://git.openjdk.org/jfx17u/pull/193.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/193/head:pull/193 PR: https://git.openjdk.org/jfx17u/pull/193 From angorya at openjdk.org Mon Jun 24 14:58:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 14:58:22 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v4] In-Reply-To: References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <1xpq-WKwQJFwFco2WqR4EuX9Nw3-HtT6pa-5nUZNbTI=.d6a47e2d-7416-4d9c-b5a5-1fa335b1590d@github.com> Message-ID: On Sat, 22 Jun 2024 10:52:42 GMT, Markus Mack wrote: >> modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 227: >> >>> 225: var uniqueCategories = new HashSet(); >>> 226: for (var entry : seriesCategoryMap.entrySet()) { >>> 227: Series s = entry.getKey(); >> >> would it make sense to add a comment explaining the reasoning for this more complex code? > > I've extended the code comment. thank you ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1476#discussion_r1651183756 From angorya at openjdk.org Mon Jun 24 15:01:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 15:01:21 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification lgtm. There is additional performance hit which I think is ok because javafx charts' design is not suitable for large amount of data points anyway. A typical use of the chart is to render relatively few data points where the impact is minor. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1476#pullrequestreview-2136063435 From angorya at openjdk.org Mon Jun 24 15:35:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 15:35:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <-N4xBT7h2xi1WwkVsZuqbEja4uGdinYtL87PFTwm6v4=.a0b74760-f37c-44d7-963e-fac7bd55fc9b@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> <-N4xBT7h2xi1WwkVsZuqbEja4uGdinYtL87PFTwm6v4=.a0b74760-f37c-44d7-963e-fac7bd55fc9b@github.com> Message-ID: On Sat, 22 Jun 2024 10:58:53 GMT, Markus Mack wrote: > I can reproduce this, looks unrelated to the issue this PR is trying to fix. Created https://bugs.openjdk.org/browse/JDK-8334873 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2186856495 From arapte at openjdk.org Mon Jun 24 16:21:18 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 24 Jun 2024 16:21:18 GMT Subject: RFR: 8334657: Enable binary check In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 12:50:45 GMT, Kevin Rushforth wrote: > This PR enables two warnings that are now (or soon will be) enabled in the [jdk](https://github.com/openjdk/jdk) repo: > > 1. Binary file check -- this will alert the reviewers of a PR that the patch being reviewed includes one or more binary files. > 2. Issue title check -- this will check for two common (minor) formatting issues with the JBS title and matching PR title, a trailing period or a leading lower-case word. > > Both are informational warnings that will not block integration. > > To see how the warnings look, refer to the following Draft PRs: > > 1. PR with binary file: #1478 > 2. PR for bug with trailing period: #1479 Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1483#pullrequestreview-2136252926 From arapte at openjdk.org Mon Jun 24 16:23:17 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 24 Jun 2024 16:23:17 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor [v2] In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 13:37:30 GMT, Kevin Rushforth wrote: >> This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. >> >> We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: >> >> * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" >> * `TOOL_LINT` - used when compiling tool tasks : default = "" >> * `TEST_LINT` - used when compiling test tasks : default = "" >> >> Each property takes a string with a comma-separated list of lint options. For example: >> >> >> gradle -PLINT="deprecation,removal" sdk >> >> >> I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. >> >> While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. >> >> I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. > > 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. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8327255-lint-removal,missing-explicit-ctor > - fix typo and add missing tool tasks > - 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods > - 8334143: Suppress remaining removal warnings for internal methods and classes > - 8327255: javac lint warnings: removal, missing-explicit-ctor Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1474#pullrequestreview-2136258001 From jvos at openjdk.org Mon Jun 24 17:17:18 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 24 Jun 2024 17:17:18 GMT Subject: [jfx17u] Integrated: 8301312: Create implementation of NSAccessibilityButton protocol In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 13:47:54 GMT, Johan Vos wrote: > 8301312: Create implementation of NSAccessibilityButton protocol This pull request has now been integrated. Changeset: cf66048e Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/cf66048eb7519a2c652ccf388218c385e8820151 Stats: 421 lines in 7 files changed: 372 ins; 41 del; 8 mod 8301312: Create implementation of NSAccessibilityButton protocol Backport-of: 05548ace27f099a5ce152e3fb9efb4d22da683c8 ------------- PR: https://git.openjdk.org/jfx17u/pull/193 From jvos at openjdk.org Mon Jun 24 17:32:29 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 24 Jun 2024 17:32:29 GMT Subject: [jfx17u] RFR: 8329705: Add missing Application thread checks to platform specific a11y methods Message-ID: 8329705: Add missing Application thread checks to platform specific a11y methods ------------- Commit messages: - Backport 0eb4d7196099d817cc6467985b882242845bdd2e Changes: https://git.openjdk.org/jfx17u/pull/194/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329705 Stats: 299 lines in 4 files changed: 299 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/194.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/194/head:pull/194 PR: https://git.openjdk.org/jfx17u/pull/194 From jvos at openjdk.org Mon Jun 24 17:32:33 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 24 Jun 2024 17:32:33 GMT Subject: [jfx21u] RFR: 8329705: Add missing Application thread checks to platform specific a11y methods Message-ID: 8329705: Add missing Application thread checks to platform specific a11y methods ------------- Commit messages: - Backport 0eb4d7196099d817cc6467985b882242845bdd2e Changes: https://git.openjdk.org/jfx21u/pull/61/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=61&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329705 Stats: 299 lines in 4 files changed: 299 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/61.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/61/head:pull/61 PR: https://git.openjdk.org/jfx21u/pull/61 From jpereda at openjdk.org Mon Jun 24 18:09:37 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 24 Jun 2024 18:09:37 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs Message-ID: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> This PR considers the horizontal scroll events that can be generated on a trackpad, on an horizontally sided `TabPane` control (top or bottom), adding to the existing vertical scroll events from mouse wheel and trackpad, to scroll its tabs. Therefore, scrolling a `TabPane` will behave in the same way that `ScrollBar` does regarding those same events and control orientation (vertical/horizontal). ------------- Commit messages: - Consider horizontal scroll events on an horizontally sided tabPane control Changes: https://git.openjdk.org/jfx/pull/1486/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1486&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334874 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1486.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1486/head:pull/1486 PR: https://git.openjdk.org/jfx/pull/1486 From mmack at openjdk.org Mon Jun 24 19:11:18 2024 From: mmack at openjdk.org (Markus Mack) Date: Mon, 24 Jun 2024 19:11:18 GMT Subject: Integrated: 8088923: IOOBE when adding duplicate categories to the BarChart In-Reply-To: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> Message-ID: On Wed, 19 Jun 2024 10:21:52 GMT, Markus Mack wrote: > This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. > > Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. > > The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. > Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. This pull request has now been integrated. Changeset: c0216ae9 Author: Markus Mack Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/c0216ae94862c860e238b251a5e51aa7c83b9a1d Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod 8088923: IOOBE when adding duplicate categories to the BarChart Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1476 From mmack at openjdk.org Mon Jun 24 19:13:14 2024 From: mmack at openjdk.org (Markus Mack) Date: Mon, 24 Jun 2024 19:13:14 GMT Subject: Integrated: 8334739: XYChart and (Stacked)AreaChart properties return incorrect beans In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 16:11:52 GMT, Markus Mack wrote: > This PR makes the `XYChart` axes properties return the correct parent XYChart object. This pull request has now been integrated. Changeset: 17c2dba0 Author: Markus Mack Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/17c2dba0d5ab7608e7df6673c67ace7212a60040 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod 8334739: XYChart and (Stacked)AreaChart properties return incorrect beans Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1485 From angorya at openjdk.org Mon Jun 24 19:14:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 19:14:15 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification thank you for fixing these two bugs! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2187233890 From angorya at openjdk.org Mon Jun 24 19:39:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 19:39:14 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: On Mon, 24 Jun 2024 18:05:09 GMT, Jose Pereda wrote: > This PR considers the horizontal scroll events that can be generated on a trackpad, on an horizontally sided `TabPane` control (top or bottom), adding to the existing vertical scroll events from mouse wheel and trackpad, to scroll its tabs. > > Therefore, scrolling a `TabPane` will behave in the same way that `ScrollBar` does regarding those same events and control orientation (vertical/horizontal). Considering that this is an improvement and a change in behavior, I would like to suggest a couple of changes: 1. For Side.LEFT/RIGHT, reverse the direction. What we have now is inconsistent with the movement of e.g. ListView (can be seen if using track pad with the list view and TabPane in the Monkey Tester): ![Screenshot 2024-06-24 at 12 32 18](https://github.com/openjdk/jfx/assets/107069028/92aacb1b-c8b8-4ed0-bd9f-b787292b5e6b) 2. Since now the TabPane movement correctly reflects the orientation of track pad gesture, we need to reverse the movement when TabPane effective nodeOrientation is RTL. 3. We don't have the behavior documented currently (some initial docs can be found in /doc-files/behavior). Maybe it's a good opportunity at least start a file for TabPane? And, a question - does this change require a CSR, since we are changing the behavior? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1486#issuecomment-2187272193 From sproket at videotron.ca Mon Jun 24 21:04:34 2024 From: sproket at videotron.ca (Dan Howard) Date: Mon, 24 Jun 2024 17:04:34 -0400 Subject: web rendering bug in JavaFX 22 Message-ID: <95e272dc-867d-46a9-965f-4d54ea0d6be1@videotron.ca> Hi all, I didn't try this with older JavaFX versions but I found a page that does not work if I render using the JavaFX browser. https://www.reonis.com/uatu/dungeoncraft/parts/iconmaker.html If you try this in firefox/chrome it works fine. Can anyone confirm? TIA From kcr at openjdk.org Mon Jun 24 22:14:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Jun 2024 22:14:18 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: On Mon, 24 Jun 2024 19:37:02 GMT, Andy Goryachev wrote: > And, a question - does this change require a CSR, since we are changing the behavior? Good question. Thinking out loud, if what this PR does is to change the existing behavior of top/bottom TabPane scrolling (e.g., horizontal scrollbar) to align with what ScrollPane already does, then... maybe not? (a CSR wouldn't be a bad idea, though) I'd be happy to hear others thoughts on this. It does need two reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1486#issuecomment-2187497806 From mmack at openjdk.org Mon Jun 24 22:16:18 2024 From: mmack at openjdk.org (Markus Mack) Date: Mon, 24 Jun 2024 22:16:18 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification I found quite a few more, opened a new PR for one of those... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2187500851 From prr at openjdk.org Mon Jun 24 22:16:22 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Jun 2024 22:16:22 GMT Subject: RFR: 8311124: [Windows] User installed font 8281327 fix does not work for all cases Message-ID: The problem is due to per-user install fonts on windows having full paths so they may be too long. This is identical to the JDK fix that was done some time ago https://github.com/openjdk/jdk/pull/13359 I've tested that per-user fonts still work and so do the system-wide installed fonts. ------------- Commit messages: - 8311124 - 8311124 Changes: https://git.openjdk.org/jfx/pull/1487/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1487&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311124 Stats: 20 lines in 1 file changed: 6 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1487.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1487/head:pull/1487 PR: https://git.openjdk.org/jfx/pull/1487 From mmack at openjdk.org Mon Jun 24 22:16:28 2024 From: mmack at openjdk.org (Markus Mack) Date: Mon, 24 Jun 2024 22:16:28 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data Message-ID: This PR is a fix for another IOOBE that I discovered while working on #1476. The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. ------------- Commit messages: - BarChart: Fix adding non-empty series - BarChart: Add styleClass "negative" for added data Changes: https://git.openjdk.org/jfx/pull/1488/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334900 Stats: 82 lines in 2 files changed: 59 ins; 21 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1488.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488 PR: https://git.openjdk.org/jfx/pull/1488 From kcr at openjdk.org Mon Jun 24 22:20:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Jun 2024 22:20:15 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: <9WQwJj7P71qa3FsuKhDD0Qjogobrpc-q4SYtCGJLdH0=.5bd53872-377b-4624-b371-dca8919b196a@github.com> On Mon, 24 Jun 2024 19:37:02 GMT, Andy Goryachev wrote: > 1. For Side.LEFT/RIGHT, reverse the direction. What we have now is inconsistent with the movement of e.g. ListView (can be seen if using track pad with the list view and TabPane in the Monkey Tester): I don't recommend doing that as part of this PR. That would be a noticeable behavior change, and warrants more discussion. > 2. Since now the TabPane movement correctly reflects the orientation of track pad gesture, we need to reverse the movement when TabPane effective nodeOrientation is RTL. Do ScrollPane or ListView work this way already? If they do, then it seems reasonable to do the same here. Otherwise, I'm not sure we should do this for TabPane in isolation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1486#issuecomment-2187504918 From kcr at openjdk.org Mon Jun 24 22:22:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Jun 2024 22:22:14 GMT Subject: Integrated: 8334731: GHA: build on macOS / aarch64 In-Reply-To: References: Message-ID: <98TN5_9S1IR19gcZU9MyTMvLylHhANXYwYqAev5FKEc=.75694611-2e64-4d79-beb6-1f90b99e0304@github.com> On Fri, 21 Jun 2024 15:22:57 GMT, Kevin Rushforth wrote: > GitHub Actions: add a macOS / aarch64 build using a macOS 14 test runner and a macOS / aarch64 boot JDK. This is a brute force approach that duplicates the job config (I don't want to spend the time to figure out how to parameterize the `.yaml` script). This pull request has now been integrated. Changeset: e9b10ab8 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e9b10ab816c2bf7b3bb88bf6c9c0ccb826bff34c Stats: 89 lines in 1 file changed: 88 ins; 0 del; 1 mod 8334731: GHA: build on macOS / aarch64 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1484 From kcr at openjdk.org Mon Jun 24 22:31:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 24 Jun 2024 22:31:13 GMT Subject: RFR: 8311124: [Windows] User installed font 8281327 fix does not work for all cases In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 22:01:09 GMT, Phil Race wrote: > The problem is due to per-user install fonts on windows having full paths so they may be too long. > This is identical to the JDK fix that was done some time ago https://github.com/openjdk/jdk/pull/13359 > I've tested that per-user fonts still work and so do the system-wide installed fonts. Reviewers: @lukostyra @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1487#issuecomment-2187516310 From angorya at openjdk.org Mon Jun 24 23:14:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 23:14:13 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: <9WQwJj7P71qa3FsuKhDD0Qjogobrpc-q4SYtCGJLdH0=.5bd53872-377b-4624-b371-dca8919b196a@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> <9WQwJj7P71qa3FsuKhDD0Qjogobrpc-q4SYtCGJLdH0=.5bd53872-377b-4624-b371-dca8919b196a@github.com> Message-ID: On Mon, 24 Jun 2024 22:17:13 GMT, Kevin Rushforth wrote: > I don't recommend doing that as part of this PR. That would be a noticeable behavior change, and warrants more discussion we **are** changing the behavior already by changing the direction of the gesture, so I thought we should be able to tackle this issue within the same PR. The other point is the discussion - these comments are already on the mailing list, what alternative discussion is required? And what are the acceptance criteria for that discussion? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1486#issuecomment-2187581811 From angorya at openjdk.org Mon Jun 24 23:18:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 23:18:14 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: <9WQwJj7P71qa3FsuKhDD0Qjogobrpc-q4SYtCGJLdH0=.5bd53872-377b-4624-b371-dca8919b196a@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> <9WQwJj7P71qa3FsuKhDD0Qjogobrpc-q4SYtCGJLdH0=.5bd53872-377b-4624-b371-dca8919b196a@github.com> Message-ID: On Mon, 24 Jun 2024 22:17:13 GMT, Kevin Rushforth wrote: > Do ScrollPane or ListView work this way already? Good point - both have the same issue (I am sure other controls as well, TableView, others did not check). Definitely deserves a separate ticket, possibly even an umbrella task (RTL navigation). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1486#issuecomment-2187586597 From prr at openjdk.org Mon Jun 24 23:28:16 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 24 Jun 2024 23:28:16 GMT Subject: RFR: 8334657: Enable binary check In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 12:50:45 GMT, Kevin Rushforth wrote: > This PR enables two warnings that are now (or soon will be) enabled in the [jdk](https://github.com/openjdk/jdk) repo: > > 1. Binary file check -- this will alert the reviewers of a PR that the patch being reviewed includes one or more binary files. > 2. Issue title check -- this will check for two common (minor) formatting issues with the JBS title and matching PR title, a trailing period or a leading lower-case word. > > Both are informational warnings that will not block integration. > > To see how the warnings look, refer to the following Draft PRs: > > 1. PR with binary file: #1478 > 2. PR for bug with trailing period: #1479 Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1483#pullrequestreview-2136976928 From angorya at openjdk.org Mon Jun 24 23:31:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 24 Jun 2024 23:31:13 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs In-Reply-To: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: <68fQPXmHu9pepCb8mr-2K0-2r9q8_JBNgDeQVuksvpM=.cb1ebe6f-1a5e-4103-871c-3cd229ddfeac@github.com> On Mon, 24 Jun 2024 18:05:09 GMT, Jose Pereda wrote: > This PR considers the horizontal scroll events that can be generated on a trackpad, on an horizontally sided `TabPane` control (top or bottom), adding to the existing vertical scroll events from mouse wheel and trackpad, to scroll its tabs. > > Therefore, scrolling a `TabPane` will behave in the same way that `ScrollBar` does regarding those same events and control orientation (vertical/horizontal). modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 947: > 945: case BOTTOM: > 946: // Consider vertical scroll events (dy > dx) from mouse wheel and trackpad, > 947: // and horizontal scroll events from a trackpad (dx > dy) Maybe we should explain why - to preserve the existing behavior with the mouse (scrolling up/down)? The trackpad events can have both `dx` and `dy` of various magnitude, both non-zero, so the logic seems to me a bit contrived - like filtering some events, although at the end it still feels ok. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1486#discussion_r1651762899 From jvos at openjdk.org Tue Jun 25 07:31:21 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 25 Jun 2024 07:31:21 GMT Subject: [jfx21u] Integrated: 8329705: Add missing Application thread checks to platform specific a11y methods In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 17:23:30 GMT, Johan Vos wrote: > 8329705: Add missing Application thread checks to platform specific a11y methods This pull request has now been integrated. Changeset: b90f009d Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/b90f009df8c67bbb90dd8ec28b303f5e2c71ba4c Stats: 299 lines in 4 files changed: 299 ins; 0 del; 0 mod 8329705: Add missing Application thread checks to platform specific a11y methods Backport-of: 0eb4d7196099d817cc6467985b882242845bdd2e ------------- PR: https://git.openjdk.org/jfx21u/pull/61 From jvos at openjdk.org Tue Jun 25 07:31:21 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 25 Jun 2024 07:31:21 GMT Subject: [jfx17u] Integrated: 8329705: Add missing Application thread checks to platform specific a11y methods In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 17:23:53 GMT, Johan Vos wrote: > 8329705: Add missing Application thread checks to platform specific a11y methods This pull request has now been integrated. Changeset: a205815f Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/a205815f99903a1a55c3fbb65a904b20584fb3fc Stats: 299 lines in 4 files changed: 299 ins; 0 del; 0 mod 8329705: Add missing Application thread checks to platform specific a11y methods Backport-of: 0eb4d7196099d817cc6467985b882242845bdd2e ------------- PR: https://git.openjdk.org/jfx17u/pull/194 From mhanl at openjdk.org Tue Jun 25 08:01:49 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 08:01:49 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: References: Message-ID: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Added sleep in tests / format javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1382/files - new: https://git.openjdk.org/jfx/pull/1382/files/0b959273..fe69b6f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=06-07 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From lkostyra at openjdk.org Tue Jun 25 08:48:20 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 25 Jun 2024 08:48:20 GMT Subject: RFR: 8327255: javac lint warnings: removal, missing-explicit-ctor [v2] In-Reply-To: References: Message-ID: On Sat, 22 Jun 2024 13:37:30 GMT, Kevin Rushforth wrote: >> This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. >> >> We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: >> >> * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" >> * `TOOL_LINT` - used when compiling tool tasks : default = "" >> * `TEST_LINT` - used when compiling test tasks : default = "" >> >> Each property takes a string with a comma-separated list of lint options. For example: >> >> >> gradle -PLINT="deprecation,removal" sdk >> >> >> I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. >> >> While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. >> >> I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. > > 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. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8327255-lint-removal,missing-explicit-ctor > - fix typo and add missing tool tasks > - 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods > - 8334143: Suppress remaining removal warnings for internal methods and classes > - 8327255: javac lint warnings: removal, missing-explicit-ctor LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1474#pullrequestreview-2137916398 From mhanl at openjdk.org Tue Jun 25 10:45:24 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 10:45:24 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 28 May 2024 16:53:39 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test for changing the stylesheet and always process CSS for that matter > > modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 461: > >> 459: >> 460: // RT-28447 >> 461: applyStylesheetFromOwner(owner); > > minor: Does this comment RT-28477 (https://bugs.openjdk.org/browse/JDK-8116444) applies to the change of to the code that follows? Either here or in the new method I think. What is your opinion? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1652517746 From jpereda at openjdk.org Tue Jun 25 11:42:44 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 25 Jun 2024 11:42:44 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs [v2] In-Reply-To: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: > This PR considers the horizontal scroll events that can be generated on a trackpad, on an horizontally sided `TabPane` control (top or bottom), adding to the existing vertical scroll events from mouse wheel and trackpad, to scroll its tabs. > > Therefore, scrolling a `TabPane` will behave in the same way that `ScrollBar` does regarding those same events and control orientation (vertical/horizontal). Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add unit tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1486/files - new: https://git.openjdk.org/jfx/pull/1486/files/9e6b89c6..2046b04e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1486&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1486&range=00-01 Stats: 77 lines in 1 file changed: 76 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1486.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1486/head:pull/1486 PR: https://git.openjdk.org/jfx/pull/1486 From kcr at openjdk.org Tue Jun 25 12:04:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 12:04:22 GMT Subject: Integrated: 8327255: javac lint warnings: removal, missing-explicit-ctor In-Reply-To: References: Message-ID: <4tr14zeYP5oSim0UHuijSaIuD0VQtoSQKNJUIVpacdA=.e911be3d-8c59-472c-8f48-8da479775db9@github.com> On Wed, 12 Jun 2024 20:03:24 GMT, Kevin Rushforth wrote: > This PR updates `build.gradle` to define javac lint options for three different types of java compilation tasks: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for these three groups of lint options are specified in `build.gradle`. > > We also define three gradle properties that can be used at build time to override the global lint options for each of the three categories of tasks as follows: > > * `LINT` - used when compiling sdk tasks : default = "removal,missing-explicit-ctor" > * `TOOL_LINT` - used when compiling tool tasks : default = "" > * `TEST_LINT` - used when compiling test tasks : default = "" > > Each property takes a string with a comma-separated list of lint options. For example: > > > gradle -PLINT="deprecation,removal" sdk > > > I provided a build mechanism to add extra per-module lint options in `build.gradle`. None are currently defined, but I tested the logic to show that it can be. I did not provide a way to override the per-module lint options via the command line. Once we start using them, we might consider adding that. > > While testing this PR, I ran into a few places where we need to suppress removal warnings for use of our own internal classes that are terminally deprecated, so I filed [JDK-8334143](https://bugs.openjdk.org/browse/JDK-8334143) to track this, and added the missing annotations in this PR. > > I also tested with JDK 23 to verify that we are now getting the expected warnings for the use of sun.misc.Unsafe, and filed two bugs --[JDK-8334138](https://bugs.openjdk.org/browse/JDK-8334138) to (temporarily) suppress those warnings in this PR and [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) to eventually fix them by replacing our use of sun.misc.Unsafe. This pull request has now been integrated. Changeset: 83c8dcc9 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/83c8dcc91a892c557c5b40064e94274caa89ce6f Stats: 115 lines in 13 files changed: 103 ins; 2 del; 10 mod 8327255: javac lint warnings: removal, missing-explicit-ctor 8334143: Suppress remaining removal warnings for internal methods and classes 8334138: Suppress removal warnings for sun.misc.Unsafe memory access methods Reviewed-by: arapte, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1474 From kcr at openjdk.org Tue Jun 25 12:04:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 12:04:22 GMT Subject: Integrated: 8334657: Enable binary check In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 12:50:45 GMT, Kevin Rushforth wrote: > This PR enables two warnings that are now (or soon will be) enabled in the [jdk](https://github.com/openjdk/jdk) repo: > > 1. Binary file check -- this will alert the reviewers of a PR that the patch being reviewed includes one or more binary files. > 2. Issue title check -- this will check for two common (minor) formatting issues with the JBS title and matching PR title, a trailing period or a leading lower-case word. > > Both are informational warnings that will not block integration. > > To see how the warnings look, refer to the following Draft PRs: > > 1. PR with binary file: #1478 > 2. PR for bug with trailing period: #1479 This pull request has now been integrated. Changeset: 101e5175 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/101e5175ff429828de25204bc3e5f216d383060b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8334657: Enable binary check 8334656: Enable issuestitle check Reviewed-by: arapte, prr ------------- PR: https://git.openjdk.org/jfx/pull/1483 From angorya at openjdk.org Tue Jun 25 14:54:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 14:54:17 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Sun, 26 May 2024 13:02:23 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Add a test for changing the stylesheet and always process CSS for that matter LGTM ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2138940839 From angorya at openjdk.org Tue Jun 25 14:54:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 14:54:18 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 10:42:22 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 461: >> >>> 459: >>> 460: // RT-28447 >>> 461: applyStylesheetFromOwner(owner); >> >> minor: Does this comment RT-28477 (https://bugs.openjdk.org/browse/JDK-8116444) applies to the change of to the code that follows? > > Either here or in the new method I think. What is your opinion? I wasn't sure; I suppose you have it right. I would have added the new JBS ticket id since RT- prefix is no more, but it is ok as it is. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1652983696 From mmack at openjdk.org Tue Jun 25 15:19:27 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 25 Jun 2024 15:19:27 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart Message-ID: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. I've added a test that fails with the previous code, specifically checking the tick mark spacing. Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). ------------- Commit messages: - Axis: Call tickMarksUpdated() while animating - testMinorTicksMatchMajorTicksAfterAnimation Changes: https://git.openjdk.org/jfx/pull/1489/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1489&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314754 Stats: 43 lines in 2 files changed: 41 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1489.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1489/head:pull/1489 PR: https://git.openjdk.org/jfx/pull/1489 From kcr at openjdk.org Tue Jun 25 15:20:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 15:20:28 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings Message-ID: This PR is a follow-on to #1474. Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: * `JAVAC_WERROR` : `true` * `TOOL_JAVAC_WERROR` : `false` * `TEST_JAVAC_WERROR` : `false` They can be overridden on the command line. I had to do the following two things for the build to pass: 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) ------------- Commit messages: - 8334161: Enable -Werror for javac tasks to fail on any warnings Changes: https://git.openjdk.org/jfx/pull/1475/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334161 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1475.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1475/head:pull/1475 PR: https://git.openjdk.org/jfx/pull/1475 From kcr at openjdk.org Tue Jun 25 15:20:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 15:20:28 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 21:57:32 GMT, Kevin Rushforth wrote: > This PR is a follow-on to #1474. > > Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: > > * `JAVAC_WERROR` : `true` > * `TOOL_JAVAC_WERROR` : `false` > * `TEST_JAVAC_WERROR` : `false` > > They can be overridden on the command line. > > I had to do the following two things for the build to pass: > > 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. > 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. > > I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: > > * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) > * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) Reviewers: @arapte This could use a second reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1475#issuecomment-2189238574 From angorya at openjdk.org Tue Jun 25 15:53:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 15:53:17 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: References: Message-ID: <0DrVBB5iHymV7MB8Xj1LEyT0TCj2i_CCufyEOSsKtec=.3731acba-71dc-489f-8283-2c78be931597@github.com> On Wed, 12 Jun 2024 21:57:32 GMT, Kevin Rushforth wrote: > This PR is a follow-on to #1474. > > Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: > > * `JAVAC_WERROR` : `true` > * `TOOL_JAVAC_WERROR` : `false` > * `TEST_JAVAC_WERROR` : `false` > > They can be overridden on the command line. > > I had to do the following two things for the build to pass: > > 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. > 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. > > I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: > > * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) > * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) introduced a javadoc problem and the build failed: error: warnings found and -Werror specified 1 error 1 warning > Task :javadoc FAILED one minor comment. build.gradle line 2270: > 2268: project.ext.moduleName = "javafx.graphics" > 2269: > 2270: // FIXME: Remove this setting when JDK-8334137 is fixed perhaps refer to https://bugs.openjdk.org/browse/JDK-8334161 as well here? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1475#pullrequestreview-2139104423 PR Review Comment: https://git.openjdk.org/jfx/pull/1475#discussion_r1653091031 From kcr at openjdk.org Tue Jun 25 18:34:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 18:34:17 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: <0DrVBB5iHymV7MB8Xj1LEyT0TCj2i_CCufyEOSsKtec=.3731acba-71dc-489f-8283-2c78be931597@github.com> References: <0DrVBB5iHymV7MB8Xj1LEyT0TCj2i_CCufyEOSsKtec=.3731acba-71dc-489f-8283-2c78be931597@github.com> Message-ID: On Tue, 25 Jun 2024 15:48:46 GMT, Andy Goryachev wrote: >> This PR is a follow-on to #1474. >> >> Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: >> >> * `JAVAC_WERROR` : `true` >> * `TOOL_JAVAC_WERROR` : `false` >> * `TEST_JAVAC_WERROR` : `false` >> >> They can be overridden on the command line. >> >> I had to do the following two things for the build to pass: >> >> 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. >> 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. >> >> I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: >> >> * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) >> * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) > > build.gradle line 2270: > >> 2268: project.ext.moduleName = "javafx.graphics" >> 2269: >> 2270: // FIXME: Remove this setting when JDK-8334137 is fixed > > perhaps refer to https://bugs.openjdk.org/browse/JDK-8334161 as well here? Probably not in this case. We generally don't refer to the bug ID that added a line of code or a comment. I will add a comment to [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) with a note to remove this block as part of fixing it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1475#discussion_r1653341227 From angorya at openjdk.org Tue Jun 25 20:12:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 20:12:15 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart In-Reply-To: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 15:14:14 GMT, Markus Mack wrote: > This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. > Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. > > I've added a test that fails with the previous code, specifically checking the tick mark spacing. > Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). modules/javafx.controls/src/main/java/javafx/scene/chart/Axis.java line 753: > 751: > 752: // call tick marks updated to inform subclasses that we have updated tick marks > 753: tickMarksUpdated(); is this the only place where this call needs to be added? for example, in BarChart the x axis is not updated after "Add series with duplicate category" - is this a separate issue? ![Screenshot 2024-06-25 at 11 58 52](https://github.com/openjdk/jfx/assets/107069028/672c0804-fd00-4bc1-9c01-bd89f41056dc) modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 156: > 154: NumberAxis yAxis = (NumberAxis)chart.getYAxis(); > 155: > 156: List majorTickYValues = yAxis.getChildrenUnmodifiable().stream() does this code captures the ticks before the first frame of animation or after the first frame? should we also check after the animation ran its course? (I assume animation does work with the StubToolkit) modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 168: > 166: .filter(path -> path instanceof MoveTo) > 167: .map(moveTo -> ((MoveTo) moveTo).getY()) > 168: .toList(); very clever - I think this is the right approach to obtain the necessary information via public APIs rather than shims. just need to be aware that only the nodes present in the scene graph can be found this way (I think, please correct me if I am wrong) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653496875 PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653364109 PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653500022 From angorya at openjdk.org Tue Jun 25 20:25:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 20:25:25 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart In-Reply-To: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 15:14:14 GMT, Markus Mack wrote: > This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. > Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. > > I've added a test that fails with the previous code, specifically checking the tick mark spacing. > Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). testing looks good. also tried AreaChart, BubbleChart, ScatterChart, StackedAreaChart. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1489#issuecomment-2189903435 From mmack at openjdk.org Tue Jun 25 21:46:26 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 25 Jun 2024 21:46:26 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 20:06:29 GMT, Andy Goryachev wrote: >> Markus Mack has updated the pull request incrementally with two additional commits since the last revision: >> >> - cleanup imports >> - add clarifying comment to test > > modules/javafx.controls/src/main/java/javafx/scene/chart/Axis.java line 753: > >> 751: >> 752: // call tick marks updated to inform subclasses that we have updated tick marks >> 753: tickMarksUpdated(); > > is this the only place where this call needs to be added? > > for example, in BarChart the x axis is not updated after "Add series with duplicate category" - is this a separate issue? > > > ![Screenshot 2024-06-25 at 11 58 52](https://github.com/openjdk/jfx/assets/107069028/672c0804-fd00-4bc1-9c01-bd89f41056dc) > > ^^ is this a separate issue? yes, the BarChart issue (which I actually want to get fixed) will need additional fixes in other classes. I could add those to this PR, but probably it's best to handle them in another ticket+PR to keep this PR affecting all `Chart`s minimal? > modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 156: > >> 154: NumberAxis yAxis = (NumberAxis)chart.getYAxis(); >> 155: >> 156: List majorTickYValues = yAxis.getChildrenUnmodifiable().stream() > > does this code captures the ticks before the first frame of animation or after the first frame? > > should we also check after the animation ran its course? (I assume animation does work with the StubToolkit) this is after the animation is finished, I added a clarifying comment to the test code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653607166 PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653606713 From mmack at openjdk.org Tue Jun 25 21:46:25 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 25 Jun 2024 21:46:25 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: > This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. > Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. > > I've added a test that fails with the previous code, specifically checking the tick mark spacing. > Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). Markus Mack has updated the pull request incrementally with two additional commits since the last revision: - cleanup imports - add clarifying comment to test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1489/files - new: https://git.openjdk.org/jfx/pull/1489/files/93ef4e69..1a853794 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1489&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1489&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1489.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1489/head:pull/1489 PR: https://git.openjdk.org/jfx/pull/1489 From angorya at openjdk.org Tue Jun 25 21:46:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 21:46:26 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> On Tue, 25 Jun 2024 21:42:23 GMT, Markus Mack wrote: >> modules/javafx.controls/src/main/java/javafx/scene/chart/Axis.java line 753: >> >>> 751: >>> 752: // call tick marks updated to inform subclasses that we have updated tick marks >>> 753: tickMarksUpdated(); >> >> is this the only place where this call needs to be added? >> >> for example, in BarChart the x axis is not updated after "Add series with duplicate category" - is this a separate issue? >> >> >> ![Screenshot 2024-06-25 at 11 58 52](https://github.com/openjdk/jfx/assets/107069028/672c0804-fd00-4bc1-9c01-bd89f41056dc) >> >> ^^ is this a separate issue? > > yes, the BarChart issue (which I actually want to get fixed) will need additional fixes in other classes. I could add those to this PR, but probably it's best to handle them in another ticket+PR to keep this PR affecting all `Chart`s minimal? a separate PR would be best. I am getting lost - do we have a ticket for that issue already or do we need to create one? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653608450 From jpereda at openjdk.org Tue Jun 25 21:47:42 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 25 Jun 2024 21:47:42 GMT Subject: RFR: 8334874: Horizontal scroll events from touch pads should scroll the TabPane tabs [v3] In-Reply-To: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> References: <4Ndy-AwRpo3YfNrpt-OyIxBcSOAGGSv9IBY_egUbRmE=.ccc87607-e4c3-4a2a-8fe2-7a40a0c49ffd@github.com> Message-ID: <2KJ5szj8B6D2is9AJgjk_Ns79rBupkkRfa3x0VxkwoM=.b3f086b2-49b8-4794-b364-4ea2d6c6f244@github.com> > This PR considers the horizontal scroll events that can be generated on a trackpad, on an horizontally sided `TabPane` control (top or bottom), adding to the existing vertical scroll events from mouse wheel and trackpad, to scroll its tabs. > > Therefore, scrolling a `TabPane` will behave in the same way that `ScrollBar` does regarding those same events and control orientation (vertical/horizontal). Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add tests for all four sides ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1486/files - new: https://git.openjdk.org/jfx/pull/1486/files/2046b04e..2c4914ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1486&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1486&range=01-02 Stats: 54 lines in 1 file changed: 31 ins; 5 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1486.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1486/head:pull/1486 PR: https://git.openjdk.org/jfx/pull/1486 From angorya at openjdk.org Tue Jun 25 21:56:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 21:56:16 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> Message-ID: On Tue, 25 Jun 2024 21:49:54 GMT, Markus Mack wrote: >> a separate PR would be best. I am getting lost - do we have a ticket for that issue already or do we need to create one? > > I think we need to create that as it turned out it's not the same as the minor tick problem fixed by this PR. but wait: this may not be a different issue. I see a slightly different behavior relative to the master branch: - select bubble chart page in the monkey tester - add series with duplicate category now I see the minor tick marks bunched up in the middle of Y Axis: ![Screenshot 2024-06-25 at 14 49 42](https://github.com/openjdk/jfx/assets/107069028/5d85367b-baee-4d4a-9450-3f7da0af49c5) Edit: no, it is present in the master branch. sorry for confusion. I'll create a ticket. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653615381 From mmack at openjdk.org Tue Jun 25 21:56:15 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 25 Jun 2024 21:56:15 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> Message-ID: On Tue, 25 Jun 2024 21:43:58 GMT, Andy Goryachev wrote: >> yes, the BarChart issue (which I actually want to get fixed) will need additional fixes in other classes. I could add those to this PR, but probably it's best to handle them in another ticket+PR to keep this PR affecting all `Chart`s minimal? > > a separate PR would be best. I am getting lost - do we have a ticket for that issue already or do we need to create one? I think we need to create that as it turned out it's not the same as the minor tick problem fixed by this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653612865 From angorya at openjdk.org Tue Jun 25 22:09:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 22:09:14 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 21:41:54 GMT, Markus Mack wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 156: >> >>> 154: NumberAxis yAxis = (NumberAxis)chart.getYAxis(); >>> 155: >>> 156: List majorTickYValues = yAxis.getChildrenUnmodifiable().stream() >> >> does this code captures the ticks before the first frame of animation or after the first frame? >> >> should we also check after the animation ran its course? (I assume animation does work with the StubToolkit) > > this is after the animation is finished, I added a clarifying comment to the test code. thank you ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653631212 From angorya at openjdk.org Tue Jun 25 22:16:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 22:16:15 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: <5KkZZPVd0bBLZcFhUMXgz1EvJD90eczzlv_1BV6syKY=.427775fd-ae24-48e3-a54d-ccee2b256b47@github.com> On Tue, 25 Jun 2024 21:46:25 GMT, Markus Mack wrote: >> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. >> Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. >> >> I've added a test that fails with the previous code, specifically checking the tick mark spacing. >> Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). > > Markus Mack has updated the pull request incrementally with two additional commits since the last revision: > > - cleanup imports > - add clarifying comment to test Simple enough fix, I think 1 reviewer is sufficient, but feel free. Also tested with AreaChart, BubbleChart, ScatterChart, StackedAreaChart. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1489#pullrequestreview-2139969721 From mmack at openjdk.org Tue Jun 25 22:16:16 2024 From: mmack at openjdk.org (Markus Mack) Date: Tue, 25 Jun 2024 22:16:16 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> Message-ID: On Tue, 25 Jun 2024 21:51:36 GMT, Andy Goryachev wrote: >> I think we need to create that as it turned out it's not the same as the minor tick problem fixed by this PR. > > but wait: this may not be a different issue. I see a slightly different behavior relative to the master branch: > > - select bubble chart page in the monkey tester > - add series with duplicate category > > now I see the minor tick marks bunched up in the middle of Y Axis: > > ![Screenshot 2024-06-25 at 14 49 42](https://github.com/openjdk/jfx/assets/107069028/5d85367b-baee-4d4a-9450-3f7da0af49c5) > > Edit: no, it is present in the master branch. sorry for confusion. I'll create a ticket. > > Edit2: my workspaces got mixed up. the issue with minor tick marks is fixed; the ticket for the problem mentioned in this comment already exists: > https://bugs.openjdk.org/browse/JDK-8334873 ok, good, I did not manage to reproduce the minor tick problem on the Y axis in the bar chart unless I switch back to master. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653636522 From angorya at openjdk.org Tue Jun 25 22:22:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 22:22:15 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <5TEkajfTcmnjhDj6NZzRJ34Fte8hEGOY0D5411mstfE=.872fa937-361d-460a-bc59-e393f13d1da0@github.com> Message-ID: <7zRBmUJJcvhFTmTsd-Wtw4dG9hJqVNi_B8RvnEIcG2w=.7769d162-69d7-471c-be7d-440c95f04eb1@github.com> On Tue, 25 Jun 2024 22:13:34 GMT, Markus Mack wrote: >> but wait: this may not be a different issue. I see a slightly different behavior relative to the master branch: >> >> - select bubble chart page in the monkey tester >> - add series with duplicate category >> >> now I see the minor tick marks bunched up in the middle of Y Axis: >> >> ![Screenshot 2024-06-25 at 14 49 42](https://github.com/openjdk/jfx/assets/107069028/5d85367b-baee-4d4a-9450-3f7da0af49c5) >> >> Edit: no, it is present in the master branch. sorry for confusion. I'll create a ticket. >> >> Edit2: my workspaces got mixed up. the issue with minor tick marks is fixed; the ticket for the problem mentioned in this comment already exists: >> https://bugs.openjdk.org/browse/JDK-8334873 > > ok, good, I did not manage to reproduce the minor tick problem on the Y axis in the bar chart unless I switch back to master. thank you for finding and fixing these issues! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653642167 From mhanl at openjdk.org Tue Jun 25 22:51:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 22:51:13 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 21:46:25 GMT, Markus Mack wrote: >> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. >> Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. >> >> I've added a test that fails with the previous code, specifically checking the tick mark spacing. >> Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). > > Markus Mack has updated the pull request incrementally with two additional commits since the last revision: > > - cleanup imports > - add clarifying comment to test Left one comment, looks good to me otherwise as well! modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 30: > 28: import javafx.scene.shape.MoveTo; > 29: import javafx.scene.shape.Path; > 30: import org.junit.jupiter.api.Assertions; Note: This mixes JUnit 4 with JUnit 5 API. AFAIK, this is nothing we want, so it is better to use the already imported `assertEquals` (from JUnit 4) below. ------------- PR Review: https://git.openjdk.org/jfx/pull/1489#pullrequestreview-2140011083 PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1653662369 From mhanl at openjdk.org Tue Jun 25 23:10:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 23:10:28 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v7] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Doc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/dc24b7f7..96310dbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=05-06 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From angorya at openjdk.org Tue Jun 25 23:10:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 23:10:28 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v7] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 23:07:29 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Doc Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2140057055 From mhanl at openjdk.org Tue Jun 25 23:10:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 23:10:28 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Sun, 26 May 2024 13:02:23 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Add a test for changing the stylesheet and always process CSS for that matter Question: Since I add a new protected method to `PopupWindow` (`applyStylesheetFromOwner`), this needs a CSR, right? Another approach would be to access this method via a Helper class, in this case maybe: `PopupWindowHelper`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2190162025 From mhanl at openjdk.org Tue Jun 25 23:10:28 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 25 Jun 2024 23:10:28 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 14:51:03 GMT, Andy Goryachev wrote: >> Either here or in the new method I think. What is your opinion? > > I wasn't sure; I suppose you have it right. > > I would have added the new JBS ticket id since RT- prefix is no more, but it is ok as it is. Changed to the JDK number, in case this lookup is needed in the future ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1653684893 From angorya at openjdk.org Tue Jun 25 23:10:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 23:10:28 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: <1S5wzXq11E_3Dlpn8pQCt1QtndF_piez0yD2fdmU8Gw=.6e1c8d6a-1230-4289-a468-a23783bd3232@github.com> On Tue, 25 Jun 2024 23:02:44 GMT, Marius Hanl wrote: >> I wasn't sure; I suppose you have it right. >> >> I would have added the new JBS ticket id since RT- prefix is no more, but it is ok as it is. > > Changed to the JDK number, in case this lookup is needed in the future thank you ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1653690402 From angorya at openjdk.org Tue Jun 25 23:15:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 25 Jun 2024 23:15:16 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 23:07:28 GMT, Marius Hanl wrote: > in this case maybe: `PopupWindowHelper`. good point! using a helper class would avoid CSR. question is - do we really need to expose this method (for custom popup windows, for example), or not? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2190176392 From kcr at openjdk.org Tue Jun 25 23:49:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 25 Jun 2024 23:49:16 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v7] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 23:10:28 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Doc I just took a quick look and yes, without changes, this would need a CSR. Using a Helper method would be one way to avoid it. Also, I think a second reviewer would be good here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2190214813 From mmack at openjdk.org Wed Jun 26 06:33:43 2024 From: mmack at openjdk.org (Markus Mack) Date: Wed, 26 Jun 2024 06:33:43 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v3] In-Reply-To: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> > This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. > Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. > > I've added a test that fails with the previous code, specifically checking the tick mark spacing. > Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). Markus Mack has updated the pull request incrementally with one additional commit since the last revision: use JUnit4 assertEquals ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1489/files - new: https://git.openjdk.org/jfx/pull/1489/files/1a853794..81b4be6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1489&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1489&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1489.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1489/head:pull/1489 PR: https://git.openjdk.org/jfx/pull/1489 From mmack at openjdk.org Wed Jun 26 06:33:43 2024 From: mmack at openjdk.org (Markus Mack) Date: Wed, 26 Jun 2024 06:33:43 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v2] In-Reply-To: References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: On Tue, 25 Jun 2024 22:48:26 GMT, Marius Hanl wrote: >> Markus Mack has updated the pull request incrementally with two additional commits since the last revision: >> >> - cleanup imports >> - add clarifying comment to test > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 30: > >> 28: import javafx.scene.shape.MoveTo; >> 29: import javafx.scene.shape.Path; >> 30: import org.junit.jupiter.api.Assertions; > > Note: This mixes JUnit 4 with JUnit 5 API. > AFAIK, this is nothing we want, so it is better to use the already imported `assertEquals` (from JUnit 4) below. right, I've changed this to JUnit 4 and removed the JUnit 5 import. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1489#discussion_r1654195502 From mhanl at openjdk.org Wed Jun 26 07:05:19 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 26 Jun 2024 07:05:19 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v3] In-Reply-To: <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> Message-ID: On Wed, 26 Jun 2024 06:33:43 GMT, Markus Mack wrote: >> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. >> Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. >> >> I've added a test that fails with the previous code, specifically checking the tick mark spacing. >> Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > use JUnit4 assertEquals Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1489#pullrequestreview-2140899917 From duke at openjdk.org Wed Jun 26 07:44:16 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 26 Jun 2024 07:44:16 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` @arapte Please review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2191032629 From duke at openjdk.org Wed Jun 26 07:45:28 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 26 Jun 2024 07:45:28 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8322619: Add test > - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" > > This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. @arapte Please review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2191033066 From mhanl at openjdk.org Wed Jun 26 10:22:16 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 26 Jun 2024 10:22:16 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 23:13:01 GMT, Andy Goryachev wrote: > question is - do we really need to expose this method (for custom popup windows, for example), or not? I can not really see why this is needed, other than maybe to not copy any style from the owner. It is hard to guess a usecase, so hiding this for now is better. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2191338086 From mhanl at openjdk.org Wed Jun 26 10:43:30 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 26 Jun 2024 10:43:30 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v8] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Use Helper class instead ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/96310dbe..bd57e79d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=06-07 Stats: 18 lines in 3 files changed: 10 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From lkostyra at openjdk.org Wed Jun 26 10:50:18 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 26 Jun 2024 10:50:18 GMT Subject: RFR: 8311124: [Windows] User installed font 8281327 fix does not work for all cases In-Reply-To: References: Message-ID: <8-gwwLb8hCaO2rBjkkbRl5BKl71cu4Te_4jRnwd3BDI=.01f06234-0513-48f8-8443-a944274629dc@github.com> On Mon, 24 Jun 2024 22:01:09 GMT, Phil Race wrote: > The problem is due to per-user install fonts on windows having full paths so they may be too long. > This is identical to the JDK fix that was done some time ago https://github.com/openjdk/jdk/pull/13359 > I've tested that per-user fonts still work and so do the system-wide installed fonts. Looks good, gave it a brief test and seems to introduce no regressions. ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1487#pullrequestreview-2141444956 From angorya at openjdk.org Wed Jun 26 14:36:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Jun 2024 14:36:20 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v8] In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 10:43:30 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Use Helper class instead Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2142074027 From angorya at openjdk.org Wed Jun 26 14:39:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Jun 2024 14:39:21 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v3] In-Reply-To: <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> Message-ID: On Wed, 26 Jun 2024 06:33:43 GMT, Markus Mack wrote: >> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. >> Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. >> >> I've added a test that fails with the previous code, specifically checking the tick mark spacing. >> Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > use JUnit4 assertEquals Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1489#pullrequestreview-2142083510 From angorya at openjdk.org Wed Jun 26 15:30:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Jun 2024 15:30:26 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v14] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Mon, 10 Jun 2024 15:06:30 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - tolerance > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 23 more: https://git.openjdk.org/jfx/compare/c8b96e4e...b9a105ee Happy birthday to me #1156 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2191995184 From angorya at openjdk.org Wed Jun 26 17:58:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Jun 2024 17:58:26 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v15] In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - ... and 24 more: https://git.openjdk.org/jfx/compare/101e5175...e48038c7 ------------- Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=14 Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From kcr at openjdk.org Wed Jun 26 18:10:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 18:10:15 GMT Subject: RFR: 8311124: [Windows] User installed font 8281327 fix does not work for all cases In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 22:01:09 GMT, Phil Race wrote: > The problem is due to per-user install fonts on windows having full paths so they may be too long. > This is identical to the JDK fix that was done some time ago https://github.com/openjdk/jdk/pull/13359 > I've tested that per-user fonts still work and so do the system-wide installed fonts. Looks good. I verified that the patch is the same as the corresponding JDK patch, which has been in production for almost a year. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1487#pullrequestreview-2142620917 From arapte at openjdk.org Wed Jun 26 18:19:17 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 26 Jun 2024 18:19:17 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 21:57:32 GMT, Kevin Rushforth wrote: > This PR is a follow-on to #1474. > > Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: > > * `JAVAC_WERROR` : `true` > * `TOOL_JAVAC_WERROR` : `false` > * `TEST_JAVAC_WERROR` : `false` > > They can be overridden on the command line. > > I had to do the following two things for the build to pass: > > 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. > 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. > > I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: > > * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) > * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) Marked as reviewed by arapte (Reviewer). A few observations on usage: 1. `gradle -PLINT=all` command would fail, or if we enable any other lint warning which if occurs would fail the build. 2. `gradle -PTEST_JAVAC_WERROR=true :controls:test` does not fail even if a warning is present, as by default lint warnings are disabled for test. We need to enable any specific warning that we are looking for; an example as `gradle -PTEST_LINT=options,unchecked -PTEST_JAVAC_WERROR=true :controls:test` 3. Currently, `gradle -PTEST_LINT=all,-options -PTEST_JAVAC_WERROR=true :controls:test` fails. (with any test task) ------------- PR Review: https://git.openjdk.org/jfx/pull/1475#pullrequestreview-2142646395 PR Comment: https://git.openjdk.org/jfx/pull/1475#issuecomment-2192362979 From prr at openjdk.org Wed Jun 26 18:23:16 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 26 Jun 2024 18:23:16 GMT Subject: Integrated: 8311124: [Windows] User installed font 8281327 fix does not work for all cases In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 22:01:09 GMT, Phil Race wrote: > The problem is due to per-user install fonts on windows having full paths so they may be too long. > This is identical to the JDK fix that was done some time ago https://github.com/openjdk/jdk/pull/13359 > I've tested that per-user fonts still work and so do the system-wide installed fonts. This pull request has now been integrated. Changeset: d9c88630 Author: Phil Race URL: https://git.openjdk.org/jfx/commit/d9c88630fad0e9cd4a93ac0901141f4ae7939be0 Stats: 20 lines in 1 file changed: 6 ins; 7 del; 7 mod 8311124: [Windows] User installed font 8281327 fix does not work for all cases Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1487 From mmack at openjdk.org Wed Jun 26 18:26:15 2024 From: mmack at openjdk.org (Markus Mack) Date: Wed, 26 Jun 2024 18:26:15 GMT Subject: Integrated: 8314754: Minor ticks are not getting updated both the axes in LineChart In-Reply-To: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> Message-ID: <6TTAkV-Xaj0GUxp3hDVGpiyyojvfFb-lKdXVmXJ63fY=.064225da-a3b6-47b5-b937-6f2737b51e60@github.com> On Tue, 25 Jun 2024 15:14:14 GMT, Markus Mack wrote: > This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. > Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. > > I've added a test that fails with the previous code, specifically checking the tick mark spacing. > Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). This pull request has now been integrated. Changeset: b80b106d Author: Markus Mack Committer: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b80b106df9eee12fc42d85cf9386975dc56c5a57 Stats: 41 lines in 2 files changed: 39 ins; 2 del; 0 mod 8314754: Minor ticks are not getting updated both the axes in LineChart Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1489 From kcr at openjdk.org Wed Jun 26 18:55:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 18:55:16 GMT Subject: RFR: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 21:57:32 GMT, Kevin Rushforth wrote: > This PR is a follow-on to #1474. > > Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: > > * `JAVAC_WERROR` : `true` > * `TOOL_JAVAC_WERROR` : `false` > * `TEST_JAVAC_WERROR` : `false` > > They can be overridden on the command line. > > I had to do the following two things for the build to pass: > > 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. > 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. > > I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: > > * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) > * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) Thanks for the reviews and the additional observations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1475#issuecomment-2192419456 From kcr at openjdk.org Wed Jun 26 18:55:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 18:55:16 GMT Subject: Integrated: 8334161: Enable -Werror for javac tasks to fail on any warnings In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 21:57:32 GMT, Kevin Rushforth wrote: > This PR is a follow-on to #1474. > > Enable `javac -Werror` so that javac warnings, including but not limited to javac lint warnings, will cause the build to fail. As with the fix for [JDK-8327255](https://bugs.openjdk.org/browse/JDK-8327255), we define three new properties to enable `-Werror`, one for each type of java compilation task: sdk classes, test classes (including shims), and tool classes (including JSLC). The defaults for `-Werror` for these three groups are: > > * `JAVAC_WERROR` : `true` > * `TOOL_JAVAC_WERROR` : `false` > * `TEST_JAVAC_WERROR` : `false` > > They can be overridden on the command line. > > I had to do the following two things for the build to pass: > > 1. Disable `-Werror` for the `javafx.graphics` module until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed. The warning generated when using `sun.misc.Unsafe` in JDK 22 or later cannot be suppressed, so we must not use `-Werror` when compiling the graphics module. > 2. Define module-specific `extraLintOptions` in the swing module to disable the "options" lint warning, which is enabled by default. That warning is generated because we (necessarily) use `--source 21` instead of `--release 21` for the Swing module, and don't set the location of the system modules. > > I tested this, both locally and via GHA, in the following two branches, each of which introduces an error, the first tests that a removal warning will fail the build and the second tests that a missing explicit constructor will fail the build: > > * [test-Werror-removal](https://github.com/kevinrushforth/jfx/tree/test-Werror-removal) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664971290) > * [test-Werror-implicit-ctor](https://github.com/kevinrushforth/jfx/tree/test-Werror-implicit-ctor) : [GHA workflow](https://github.com/kevinrushforth/jfx/actions/runs/9664924813) This pull request has now been integrated. Changeset: 0d2a0a46 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0d2a0a462e500b9bb7ac4fc4f45beff9a378ea60 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod 8334161: Enable -Werror for javac tasks to fail on any warnings Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1475 From kcr at openjdk.org Wed Jun 26 20:47:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 20:47:13 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 09:02:43 GMT, Ao Qi wrote: > This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. > > Error log: > > > /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." > 140 | #error "Unsupported platform: need implementation of currentStackPointer." > | ^~~~~ > make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 Looks fine. @HimaBinduMeda said she will also review it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1482#pullrequestreview-2142936019 From kcr at openjdk.org Wed Jun 26 20:54:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 20:54:16 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 08:01:49 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Added sleep in tests / format javadoc Looks good. I'll review the CSR and then you can "Finalize" it. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2142946665 From kcr at openjdk.org Wed Jun 26 20:54:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 20:54:17 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v3] In-Reply-To: References: Message-ID: On Tue, 2 Apr 2024 14:20:14 GMT, Lukasz Kostyra wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> improve tests > > LGTM, tests also seem to be fine on my end (checked on Windows and Ubuntu 22.04 LTS) @lukostyra Please re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2192607358 From angorya at openjdk.org Wed Jun 26 21:52:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 26 Jun 2024 21:52:36 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration Message-ID: This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. Problem ======= Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. Solution ====== Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. Advantages ========= 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. NOTES: - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled ------------- Commit messages: - Merge branch 'master' into 8335218.eclipse - remove gradle - Merge branch 'master' into ag.eclipse.plain - removed gradle from eclipse projects Changes: https://git.openjdk.org/jfx/pull/1491/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335218 Stats: 26 lines in 4 files changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1491.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1491/head:pull/1491 PR: https://git.openjdk.org/jfx/pull/1491 From kcr at openjdk.org Wed Jun 26 22:39:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 26 Jun 2024 22:39:14 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled Reviewers: @nlisker This will need discussion among and review by the Eclipse users on the list. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2192730889 From hmeda at openjdk.org Thu Jun 27 05:13:15 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 27 Jun 2024 05:13:15 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 09:02:43 GMT, Ao Qi wrote: > This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. > > Error log: > > > /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." > 140 | #error "Unsupported platform: need implementation of currentStackPointer." > | ^~~~~ > make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 Changes look fine. ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1482#pullrequestreview-2144209115 From aoqi at openjdk.org Thu Jun 27 07:03:13 2024 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 27 Jun 2024 07:03:13 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 11:24:34 GMT, Kevin Rushforth wrote: >> This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. >> >> Error log: >> >> >> /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." >> 140 | #error "Unsupported platform: need implementation of currentStackPointer." >> | ^~~~~ >> make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 > > Reviewers: @jaybhaskar @kevinrushforth Thanks, @kevinrushforth and @HimaBinduMeda ! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1482#issuecomment-2193944610 From lkostyra at openjdk.org Thu Jun 27 10:41:18 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 27 Jun 2024 10:41:18 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: References: Message-ID: <_UGgNledBmc9soLnBx7bjOXk8RdZxqHycxeKT_wtA-E=.0d23a4dc-f092-4baf-bfd5-442b0aad94af@github.com> On Tue, 25 Jun 2024 08:01:49 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Added sleep in tests / format javadoc Change looks good, but I'm still seeing failures on my macOS system (Sonoma 14.5, MacBook Pro M1 Max): SizeToSceneTest > testInitialSizeOnSizeToSceneThenFullscreen() FAILED org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeOnSizeToSceneThenFullscreen(SizeToSceneTest.java:150) SizeToSceneTest > testInitialSizeAfterShowFullscreenThenSizeToScene() FAILED org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeAfterShowFullscreenThenSizeToScene(SizeToSceneTest.java:186) SizeToSceneTest > testInitialSizeAfterShowSizeToSceneThenFullscreen() FAILED org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeAfterShowSizeToSceneThenFullscreen(SizeToSceneTest.java:162) SizeToSceneTest > testInitialSizeOnFullscreenThenSizeToScene() FAILED org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) at app//test.javafx.stage.SizeToSceneTest.testInitialSizeOnFullscreenThenSizeToScene(SizeToSceneTest.java:128) Windows and Ubuntu 22.04 LTS work fine for me. ------------- PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2144980246 From kcr at openjdk.org Thu Jun 27 11:26:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Jun 2024 11:26:16 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 08:01:49 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Added sleep in tests / format javadoc Based on those failures it would be a good idea to add tolerance to the check for >= visual bounds. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2194427989 From mhanl at openjdk.org Thu Jun 27 11:51:19 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 27 Jun 2024 11:51:19 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: <_UGgNledBmc9soLnBx7bjOXk8RdZxqHycxeKT_wtA-E=.0d23a4dc-f092-4baf-bfd5-442b0aad94af@github.com> References: <_UGgNledBmc9soLnBx7bjOXk8RdZxqHycxeKT_wtA-E=.0d23a4dc-f092-4baf-bfd5-442b0aad94af@github.com> Message-ID: On Thu, 27 Jun 2024 10:38:42 GMT, Lukasz Kostyra wrote: > Change looks good, but I'm still seeing failures on my macOS system (Sonoma 14.5, MacBook Pro M1 Max): I'm confused, the screen height is reported as 1085? Looks like the width, but I still would not expect a width like that. Thats why the condition is written the other way around. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2194470583 From aoqi at openjdk.org Thu Jun 27 11:54:17 2024 From: aoqi at openjdk.org (Ao Qi) Date: Thu, 27 Jun 2024 11:54:17 GMT Subject: Integrated: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 09:02:43 GMT, Ao Qi wrote: > This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. > > Error log: > > > /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." > 140 | #error "Unsupported platform: need implementation of currentStackPointer." > | ^~~~~ > make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 This pull request has now been integrated. Changeset: ca04c87d Author: Ao Qi Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Reviewed-by: kcr, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/1482 From mhanl at openjdk.org Thu Jun 27 13:43:37 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 27 Jun 2024 13:43:37 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v9] In-Reply-To: References: Message-ID: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: add delta for assertStageScreenBounds ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1382/files - new: https://git.openjdk.org/jfx/pull/1382/files/fe69b6f7..fc6a6816 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1382&range=07-08 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1382.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1382/head:pull/1382 PR: https://git.openjdk.org/jfx/pull/1382 From duke at openjdk.org Thu Jun 27 17:27:58 2024 From: duke at openjdk.org (duke) Date: Thu, 27 Jun 2024 17:27:58 GMT Subject: RFR: 8334739: XYChart and (Stacked)AreaChart properties return incorrect beans [v2] In-Reply-To: References: Message-ID: <_KU5rGisnaEJH10rvoJbwaUHxqQC1YwzOqIBxSAWV5o=.515dd8d4-df31-47f7-86a4-c67926b21a97@github.com> On Fri, 21 Jun 2024 16:57:38 GMT, Markus Mack wrote: >> This PR makes the `XYChart` axes properties return the correct parent XYChart object. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > Set correct bean for properties in AreaChart / StackedAreaChart @drmarmac Your change (at version 761c82a2320b628dffb4a0d90005bc448914913e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1485#issuecomment-2187229750 From duke at openjdk.org Thu Jun 27 17:27:59 2024 From: duke at openjdk.org (duke) Date: Thu, 27 Jun 2024 17:27:59 GMT Subject: RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Fri, 21 Jun 2024 09:02:43 GMT, Ao Qi wrote: > This problem has been fixed [upstream](https://github.com/WebKit/WebKit/pull/23282). This patch merges the fix in advance. > > Error log: > > > /some_dir/jfx/modules/javafx.web/src/main/native/Source/WTF/wtf/StackPointer.cpp:140:2: error: #error "Unsupported platform: need implementation of currentStackPointer." > 140 | #error "Unsupported platform: need implementation of currentStackPointer." > | ^~~~~ > make[2]: *** [Source/WTF/wtf/CMakeFiles/WTF.dir/build.make:1098: Source/WTF/wtf/CMakeFiles/WTF.dir/StackPointer.cpp.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [CMakeFiles/Makefile2:360: Source/WTF/wtf/CMakeFiles/WTF.dir/all] Error 2 @theaoqi Your change (at version 24867e266ace3e3f78ca90180f4c47191fb8a626) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1482#issuecomment-2193946269 From duke at openjdk.org Thu Jun 27 17:28:04 2024 From: duke at openjdk.org (duke) Date: Thu, 27 Jun 2024 17:28:04 GMT Subject: RFR: 8314754: Minor ticks are not getting updated both the axes in LineChart [v3] In-Reply-To: <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> References: <8sZ_n3XCc4H2mj7dqZUwr36ty2TY9b9bPZ2YbmU00tk=.c04914ce-bcb1-4c8a-bda6-91f41dea6f0f@github.com> <2eULjGRm0FrW2Yx95bF0tWtKahVigxkO5ZUXOCdiwEc=.81a87c92-d94a-4695-a5e2-e9f62e48fd22@github.com> Message-ID: On Wed, 26 Jun 2024 06:33:43 GMT, Markus Mack wrote: >> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick mark layout code in subclasses) is called during `Chart` `Axis` layout when needed. >> Previously, it was only called when tick mark length or range was changed, which is not happening during axis animations, causing minor ticks to become outdated when animations are enabled. >> >> I've added a test that fails with the previous code, specifically checking the tick mark spacing. >> Alternatively the test could be implemented by accessing ValueAxis.minorTickMarkValues, which would need to be made at least package-private however (with a shim). This implementation checks the tick mark `Path` shape instead, which is already publicly accessible (but could be considered an implementation detail). > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > use JUnit4 assertEquals @drmarmac Your change (at version 81b4be6abc9bd47d6b5163d1d7e32f9b138a1d57) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1489#issuecomment-2192372025 From duke at openjdk.org Thu Jun 27 17:28:13 2024 From: duke at openjdk.org (duke) Date: Thu, 27 Jun 2024 17:28:13 GMT Subject: RFR: 8088923: IOOBE when adding duplicate categories to the BarChart [v5] In-Reply-To: <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> References: <9Bom7BYySyx7zbrdx2apiGJZ9S0EPAlq5PGSQw1hMuo=.d5d3b9fc-b870-4502-aa9f-6fc278947738@github.com> <7v4_6yQqhOM9RV5gcdqcpjk8_4M4KKgaDQckaxMxSKo=.85b33b7c-ad19-4d4a-ab9f-f21ac5b10c12@github.com> Message-ID: On Sat, 22 Jun 2024 10:55:28 GMT, Markus Mack wrote: >> This PR provides the test case given in the JBS issue, and a simple fix for the index calculation when inserting data after previous data with duplicate categories. >> >> Also, I've added a comment to `BarChart`s javadoc, clarifying the behavior that was apparently assumed (but broken) previously. >> >> The index lookup is skipped for performance reasons if there are no duplicates, corresponding to the previous implementation. >> Further optimizations would be possible, but probably are not really helpful without more extensive changes. The previous code already loops over all categories to check if they are present, typically nested in a loop adding many data items, thus already scaling quadratically when adding lots of mostly unique data points. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > add javadoc clarification @drmarmac Your change (at version 7a943fcf132be5aae85488ac7d2128741a965a15) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1476#issuecomment-2187226908 From angorya at openjdk.org Thu Jun 27 17:31:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:15 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale Message-ID: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . Removed earlier manual tester in favor of the monkey tester. It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). ------------- Commit messages: - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge branch 'master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - Merge remote-tracking branch 'origin/master' into 8299753.resize - tolerance - ... and 24 more: https://git.openjdk.org/jfx/compare/101e5175...e48038c7 Changes: https://git.openjdk.org/jfx/pull/1156/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299753 Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1156.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156 PR: https://git.openjdk.org/jfx/pull/1156 From kpk at openjdk.org Thu Jun 27 17:31:19 2024 From: kpk at openjdk.org (Karthik P K) Date: Thu, 27 Jun 2024 17:31:19 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). Tested the fix in Windows 11 and MacOS 13.3.1. The changes fixes the issue in Windows and in mac, the behavior is as expected with and without the change. Provided couple of minor comments inline. Left a inline comment. Otherwise looks good to me Tested the changes in Windows 11 with different scale values. The fix works as expected. I will review the code soon and complete the review. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 112: > 110: distribute(delta, pref); > 111: } > 112: } else if (delta > 0.0) { Do we need delta = 0.0 condition here? modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 176: > 174: while (delta < -halfPixel) { > 175: double d = -pixel; > 176: if(smallShrink(d, desired)) { Minor: Add space after `if` -> `if (` modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 184: > 182: while (delta > halfPixel) { > 183: double d = pixel; > 184: if(smallGrow(d, desired)) { Add space after `if` -> `if (` ------------- Changes requested by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1495003754 Marked as reviewed by kpk (Committer). PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1506543354 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1848411826 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1247456039 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1239728406 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1239728609 From jhendrikx at openjdk.org Thu Jun 27 17:31:24 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:31:24 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). I only reviewed this partially. My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. The `ResizeHelper` is short-lived, and created/recreated many times during a resize operation. I'm not even sure why it is being instantiated at all (it literally is created and discarded in a single method). The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). I'd expect: 1. User starts a resize 2. All sizes and positions are stored -- this may be a good time to create something like the `ResizeHelper`. This `ResizeHelper` should never modify the initial sizes, as they're needed for each new calculation until the drag ends. 3. User drags the cursor all over the place 4. Depending on where the cursor is + the initial stored values, a new set of column sizes is calculated and displayed; the algorithm should not have "memory" effects of non-final column sizes of positions where the cursor was before 5. When the drag ends, the final position is exactly what would have happened if the drag was a single instant move, in other words, moving the cursor from `0 -> 100` should be the same as if it was moved from `0 -> -10 -> 90 -> 200 -> 100` I haven't checked completely how the column resizing works, but I don't see how this could possible be a good algorithm currently. So I'm left wondering what value this change then brings as I think these changes would more than likely all be discarded once the UX is implemented correctly. A direct JUnit test on this complicated code that verifies all the edge cases would be something I'd like to see added as a minimum, but looking at the code, I don't see this being a good algorithm at all... > > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. > > please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope _at the moment_, as this is a follow-up for a specific issue. It's hard to point to a specific problem when most of the algorithm used would be unnecessary if it used the initial conditions + current resize position as its basis for calculating the column sizes. My problem with this implementation is that it takes what is fundamentally a very simple algorithm (columns have sizes X,Y,Z and Y is resized 10 pixels larger, what should the layout be?) and turns it into a frame rate dependent, mouse movement dependent delta calculation. The initial conditions are discarded, and so a single drag resize of 10 pixels is NOT the same as a drag resize that captured several individual steps (1 + 2 + 3 + 4 pixels), while it really should be... On top of that, if indeed the algorithm is flawed, as I think it is, then there is no way to really fix it apart from some cosmetic changes. This then would be a lot of wasted effort. As I noted, there is no JUnit test for this code as of yet, and for such a complicated algorithm to be verified to be correct, I think it would need one to pass review. If we're willing to forego that, then I suppose a casual fix is in the cards, but I can't really see whether or not it would be correct (within its fundamental limitations) without extensive manual testing. > > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). > > This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. Yes, it would be needed with this algorithm as it is dependent on mouse cursor speed and frame rate as it has no idea of what the initial positions were and how it arrived at the current state. > For example, I tried to use your SpaceDistributor from #1111 and it suffered from the same problem as bypassing the small delta path (by setting SMALL_DELTA=0) - when the user resizes the columns slowly, the same column gets the pixel and grows wider than the rest. It would not be sufficient to just replace `ResizeHelper` with something that uses the space distributor as the information it needs would still be lost. When writing algorithms that resize a UI, using the current size of the elements in your UI + a resize amount will never result in a consistent looking resize. It always must be based on their size constraints (which can be min/pref/max based for controls that can't be individually resized) or the actual sizes when the action started (for splitters or columns). Once the action is finished, only then do the new sizes become the initial sizes for the next action -- not at every mouse event or frame that elapses. `HBox` for example doesn't use its **current** sizes to calculate its "new" size -- it always goes back to the basic min/pref/max sizes, then looks at the space available and computes new sizes based on only that information. If it used the current sizes as its base, you would notice that in certain scenario's the final sizes (if you slowly vs quickly resized a window) would not necessarily always be the same for the same available width -- that's exactly what I think is happening with the column sizes; it's not deterministic and can't be because it lacks the information to do so and hence has to resort to `SMALL_DELTA` tricks to differentiate between "fast" and "slow" resizes. Relying on such things (which can vary with mouse hardware, current framerate, CPU/GPU load, amount of visible `Node`s) makes for an inconsistent resize experience, even when the column was resized by the exact same amount of pixels when the resize ends. This can I think be fixed relatively easily; all it really would take is to track when the drag starts, store the sizes, use these sizes to calculate new sizes each time, and when the drag ends, discard the stored sizes. The `ResizeHelper` would then only need a single much simpler method that takes an array of sizes, the resizing mode, the space available and which column was resized and by how much -- or if you want, you can associate the `ResizeHelper` with the drag resize start, and use the same helper while the resize is in progress. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 58: > 56: ConstrainedColumnResize.ResizeMode mode) { > 57: this.rf = rf; > 58: this.snap = (rf.getTableControl().isSnapToPixel() ? rf.getTableControl() : null); Obtaining the `Region` here is a bit hacky, this may be out of scope, but I would say `snap` should be a boolean, and the `snapXXX` helper methods in this class should call `ScaledMath`. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 77: > 75: double cmin = snapCeil(c.getMinWidth()); // always honor min width! > 76: double cmax = snapFloor(c.getMaxWidth()); // TableColumnBase.doSetWidth() clamps to (min,max) range > 77: min[i] = cmin; Looking at `doSetWidth` I see that it clamps using unsnapped values, so the column can still be given an unsnapped size. When scale is 1.0, and the column for example has its min/max width set to 20.1 and 20.9, then snapCeil is 21 and snapFloor is 20 (so maximum is less than minimum, which may already be a bit dubious). When `doSetWidth` is called it will be clamped, resulting in `20.1` or `20.9`. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 125: > 123: private void distribute(double delta, double[] desired) { > 124: double threshold = snapRound(SMALL_DELTA); > 125: if (Math.abs(delta) > threshold) { The threshold is pretty arbitrary, I don't think it benefits from snap rounding here. I'd be more inclined to eliminate the difference between these two functions; I would expect that if a user drags a column resizer for 100 pixels, that it should make no difference whether that was a slow drag or a fast one, and the end visuals and column sizes should be exactly the same regardless. ------------- PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-1509558936 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622392841 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249477980 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249466719 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1249493706 From jhendrikx at openjdk.org Thu Jun 27 17:31:28 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:31:28 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs Message-ID: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. # Behavior |Listener...|ExpressionHelper|ListenerManager| |---|---|---| |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| ## Nested notifications: | |ExpressionHelper|ListenerManager| |---|---|---| |Type|Depth first (call stack increases for each nested level)|(same)| |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| |Vetoing Possible?|No|Yes| |Old Value correctness|Only for listeners called before listeners making nested changes|Always| # Performance |Listener|ExpressionHelper|ListenerManager| |---|---|---| |Addition|Array based, append in empty slot, resize as needed|(same)| |Removal|Array based, shift array, resize as needed|(same)| |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| |Notifying Invalidation Listeners|1 ns each|(same)| |Notifying Change Listeners|1 ns each (*)|2-3 ns each| (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values # Memory Use Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| |---|---|---|---| |No Listeners|none|none|none| |Single InvalidationListener|16 bytes overhead|none|none| |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| # About nested changes Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This all occurs on the same thread, and a nested change is nothing more than the same property being modified, triggering its listeners again deeper in the call stack with another notification, while higher up the call stack a notification is still being handled: (top of stack) fireValueChangedEvent (property A) <-- nested notification setValue (property A) <-- listener modifies property A changed (Listener 1) <-- a listener called by original notification fireValueChangedEvent (property A) <-- original notification ## How do nested changes look? Let's say we have three listeners, where the middle listener changes values to uppercase. When changing a property with the initial value "A" to a lowercase "b" the listeners would see the following events: ### ExpressionHelper |Nesting Level|Time|Listener 1|Listener 2|Listener 3|Comment| |---|---|---|---|---|---| | 0 |T1 |A -> b| | | | | 0 |T2 | |A -> b| |Value is changed to B| | 1 |T3 |b -> B| | | A nested loop started deeper on the call stack | | 1 |T4 | |b -> B| | | | 1 |T5 | | |b -> B| | | 0 |T6 | | |A -> B|Top level loop is resumed| Note how the values received by the 3rd listener are non-sensical. It receives two changes both of which changes to B from old values that are out of order. ### ListenerManager (new) This how ListenerManager sends out these events: |Nesting Level|Time|Listener 1|Listener 2|Listener 3|Comment| |---|---|---|---|---|---| | 0 |T1 |A -> b| | | | | 0 |T2 | |A -> b| |Value is changed to B| | 1 |T3 |b -> B| | | A nested loop started deeper on the call stack | | 1 |T4 | |b -> B| | The nested loop is terminated early at this point | | 0 |T5 | | |A -> B|Top level loop is resumed| Note how the 3rd listener now receives an event that reflects what actually happened from its perspective. Also note that less events overall needed to be send out. # About Invocation Order A lot of code depends on the fact that an earlier registered listener of the same type is called **before** a later registered later of the same type. For listeners of different types it is a bit less clear. What is clear however is that invalidation and change listeners are defined by separate interfaces. Mixing their invocations (to conserve registration order) would not make sense. Historically, invalidation listeners are called before change listeners. No doubt, code will be (unknowingly) relying on this in today's JavaFX applications so changing this is not recommended. Perhaps there is reason to say that invalidation listeners should be called first as they're defined by the super interface of `ObservableValue` which introduces change listeners. # About Listener Add/Remove performance Many discussions have happened in the past to improve the performance of removing listeners, ranging from using maps to ordered data structures with better remove performance. Often these solutions would subtly change the notification order, or increase the overhead per listener significantly. But these discussions never really looked at the other consequences of having tens of thousands of listeners. Even if listeners could be removed in something approaching O(1) time (additions are already O(1) and so are not the issue), what about the performance of notifying that many listeners? That will still be O(n), and so even if JavaFX could handle addition and removal of that many listeners comfortably, actually using a property with that many listeners is still impossible as it would block the FX thread for far too long when sending out that many notifications. Therefore, I'm of the opinion that "fixing" this "problem" is pointless. Instead, having that many listeners should be considered a design flaw in the application. A solution that registers only a single listener that updates a shared model may be much more appropriate. # About Old Value Correctness ...and why it is important. A change listener provides a callback that gives the old and the new value. One may reasonably expect that these values are never the same, and one may reasonably expect that the given old value is the same as the previous invocation's new value (if there was a previous invocation). In JavaFX, many change listeners are used for important tasks, ranging from reverting changes in order to veto something, to registering and unregistering listeners on properties. Many of those change listeners do not care about the old value, but there are a significant number that use it and rely on it being correct. A common example is the registering of a listener on the "new" value, and removing the same listener from the "old" value in order to maintain a link to some other property that changes location: (obs, old, current) -> { if (old != null) { old.removeListener(x); } if (current != null) { current.addListener(x); } } The above code looks bug free, and it would be if the provided old values are always correct. Unfortunately, this does not have to be the case. When a nested change is made (which can be made by a user registered listener on the same property), `ExpressionHelper` makes no effort to ensure that for all registered listener the received old and new values make sense. This leads to listeners being notified twice with the same "new" value for example, but with a different old value. Imagine the above listener receives the following change events: scene1 becomes scene3 scene2 becomes scene3 The above code would remove its listeners from `scene1` and `scene2`, and register two listeners on `scene3`. This leads to the listener being called twice when something changes. When later the scene changes to `scene4`, it receives: scene3 becomes scene4 Because it registered its listener twice on `scene3`, and only removes one of them, it now has listeners on both `scene3` and `scene4`. Clearly it is incredibly important that changes make sense, or even simple code that looks innocuous becomes problematic. # The PR The `ListenerManager` differs from `ExpressionHelper` in the following ways: - Provides correct old/new values to `ChangeListener`s under all circumstances - Unnecessary change events are never sent - Single invalidation or change listeners are inlined directly into the observable class (in other words, properties with only a single listener don't take up any extra space at all) - Performance is slightly worse when calling **change** listeners (but remember that `ExpressionHelper` is not following the contract). - Removed listeners are never called after being removed (even if they were part of the initial list when the notification triggered) - Added listeners are only called when a new non-nested (top level) notification starts - Locking and maintaining the listener list works a bit differently -- the main takeaway is that the list indices remain the same when modified during nested modifications, which allows using the same list no matter how deep the nesting - No reference is stored to the ObservableValue and no copy is kept of the current value - Memory use when there is more than 1 listener should be similar, and better when not - Although complicated, the code is I think much better separated, and more focused on accomplishing a single task: - `ListenerManager` manages the listener storage in property classes, and the transformation between the listener variants (it either uses listeners directly, or uses a `ListenerList` when there are multiple listeners). - `ListenerListBase` handles the locking and compacting of its listener lists. - `ListenerList` which extends `ListenerListBase` is only concerned with the recursion algorithm for notification. - `ArrayManager` handles resizing and reallocating of arrays. - There are variants of `ListenerList` and `ListenerManager` which can cache their old values when its not possible to supply these (this has a cost, and is what `ExpressionHelper` does by default). The notification mechanism deals with nested notifications by tracking how many listeners were notified already before the nested notification occurs. For example, if 5 listeners were notified, and then listener 5 makes a nested change, then in that nested change only the first 5 listeners are notified again (if they still exist). The nested loop is then terminated early, at which point the top level loop resumes: it continues where it left of and notifies listener 6 and so on. This ensures that all notifications are always correct, and that listeners that "veto" changes can effectively block later listeners from seeing those at all. For example, if the first listener always uppercases any received values, then any succeeding listeners will always see only uppercase values. The first listener receives two notifications (`X -> a` and `a -> A`), and the second receives only `X -> A`. Contrast this with the old `ExpressionHelper`, which sends odd notifications to the second listener (`a -> A` and `X -> A`, in that order). Unfortunately, due to a somewhat weird design choice in the PropertyBase classes, the strategy of not having to cache the "current value" (or old value) can't be used (it can only be used for Bindings for now). So there is another variant of this helper, called `OldValueCachingListenerHelper`, with some slight differences: - Has an extra field for storing the old value when there are any `ChangeListener`s active - Can't store a `ChangeListener` inline; a minimal wrapper is needed to track the old value (ExpressionHelper does the same) ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into feature/nested-emission-with-correct-old-values - Fix generic warnings - Fix merge - Merge remote-tracking branch 'upstream/master' into - Prevent removal of weak listeners during unlock - Use an overridable method to store latest value - Merge the recursive notification loop code - Small bug fix in OldValueCachingListenerList - Improve doc - Move listener call code to ListListenerBase - ... and 17 more: https://git.openjdk.org/jfx/compare/54005125...ffa9b299 Changes: https://git.openjdk.org/jfx/pull/1081/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290310 Stats: 4358 lines in 39 files changed: 4195 ins; 7 del; 156 mod Patch: https://git.openjdk.org/jfx/pull/1081.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081 PR: https://git.openjdk.org/jfx/pull/1081 From mstrauss at openjdk.org Thu Jun 27 17:31:55 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:31:55 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... This change is a great improvement over the current implementation, I'm looking forward to it. Some comments below: `ListenerManager` is an obvious improvement, as it fixes incorrect behavior and allows listeners to veto changes. However, the behavior of `ListenerManager` is also an implementation detail and not documented anywhere. This leads me to the following questions: 1. How will users know that they can now do all of the things that were previously broken? Do we need a specification for what is allowed and what's not allowed? 2. Should this behavior be required for all valid `ObservableValue` implementations? (This would render many existing implementations defective.) 3. If `ObservableValue` implementations are not required to replicate the `ListenerManager` behavior, we should probably make it easily discoverable whether any particular implementation (most of them are properties) supports nested changes/vetoing. In most of the public API, there's no obvious way to see (without looking at the source code) whether a property implementation extends one of the `*PropertyBase` classes. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 58: > 56: * Constructs a new instance. > 57: * > 58: * @param accessor an {@link Accessor}, cannot be {@code null} There is no `accessor` parameter. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 94: > 92: * > 93: * @param instance the instance it is located in, cannot be {@code null} > 94: * @param array the occupied slots of the array to set The parameter is named `occupiedSlots`, not `array`. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 168: > 166: * @param instance a reference to the instance where the array is stored, cannot be {@code null} > 167: * @param index an index to remove, cannot be negative, or greater than or equal to the number of occupied slots > 168: * @returns the element that was removed, can be {@code null} if the element at the given index was {@code null} Should be `@return`. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 217: > 215: * @param instance a reference to the instance where the array is stored, cannot be {@code null} > 216: * @param index an index, cannot be negative, or greater than or equal to the number of occupied slots > 217: * @returns the element at the given index, can be {@code null} if the element at the given index was {@code null} Should be `@return`. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 238: > 236: * @param index an index to set, cannot be negative, or greater than or equal to the number of occupied slots > 237: * @param element an element to set, can be {@code null} > 238: * @returns the element that was previously at the given index, can be {@code null} if the element at the given index was {@code null} Should be `@return`. modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 374: > 372: while (needed > max) { > 373: min = mid; > 374: mid = max; These two lines don't seem to be useful, as neither `min` nor `mid` are ever accessed after this point. modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 243: > 241: > 242: /** > 243: * Gets the {@link ChangeLisener} at the given index. This can be {@code null} if the Typo: `ChangeListener` modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 84: > 82: * @throws NullPointerException when listener is {@code null} > 83: */ > 84: public void addListener(I instance, ChangeListener listener) { The code of this method is a duplicate of `addListener(I, InvalidationListener)`. Maybe you could use a common implementation for both overloads. modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 125: > 123: > 124: /** > 125: * Notifies the listeners managed in the given instance.

Minor: unncessary `

` modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 143: > 141: */ > 142: public void fireValueChanged(I instance, T oldValue) { > 143: Object data = getData(instance); The `data` value could be passed into this method, which would save a (potentially not devirtualized) method call. modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 145: > 143: Object data = getData(instance); > 144: > 145: if (data instanceof ListenerList) { Why is `ListenerList` checked first, when most observables only have a single `InvalidationListener`? modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 101: > 99: * notification otherwise {@code false} > 100: */ > 101: public boolean notifyListeners(ObservableValue observableValue) { The code in this method is _almost_ identical to `ListenerList.notifyListeners(ObservableValue, T)`. Given that this method is somewhat complex, I think it would be good to use a common implementation. This will help with code review, and decrease the chance that both methods diverge further with future modifications. modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 164: > 162: } > 163: > 164: private void callInvalidationListener(ObservableValue instance, InvalidationListener listener) { This method is identical to `ListenerList.callInvalidationListener`. modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 173: > 171: } > 172: > 173: private void callChangeListener(ObservableValue instance, ChangeListener changeListener, T oldValue, T newValue) { Again, _almost_ identical to `ListenerList.callChangeListener`. modules/javafx.base/src/main/java/javafx/beans/property/ObjectPropertyBase.java line 91: > 89: @Override > 90: public void addListener(InvalidationListener listener) { > 91: LISTENER_MANAGER.addListener((ObjectPropertyBase) this, listener); I think the unchecked casts here can be removed if `ListenerManagerBase` is declared as `ListenerManagerBase>`, and `OldValueCachingListenerManager` accordingly. Then the `LISTENER_MANAGER` instance can be parameterized as `OldValueCachingListenerManager>`. modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyObjectPropertyBase.java line 66: > 64: @Override > 65: public void addListener(InvalidationListener listener) { > 66: LISTENER_MANAGER.addListener((ReadOnlyObjectPropertyBase) this, listener); See the comment for `ObjectPropertyBase`. modules/javafx.base/src/main/java/javafx/beans/value/ObservableValueBase.java line 70: > 68: @Override > 69: public void addListener(InvalidationListener listener) { > 70: LISTENER_MANAGER.addListener((ObservableValueBase) this, listener); See the comment for `ObjectPropertyBase`. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ArrayManagerTest.java line 3: > 1: package test.com.sun.javafx.binding; > 2: > 3: import static org.junit.Assert.assertNull; Wrong import modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ArrayManagerTest.java line 91: > 89: > 90: @Test > 91: void setSshouldRejectSettingIllegalIndices() { Typo: `Sshould` ------------- PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-1386650763 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2018017130 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686027 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686153 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686217 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686291 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686304 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686565 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167686624 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167687366 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167687470 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272690289 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272692011 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167688825 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167688937 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167688953 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167690228 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167690295 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167690187 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167690735 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167690436 From angorya at openjdk.org Thu Jun 27 17:31:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:24 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). fixed, thanks! @hjohn would you mind taking a look at this? using the ideas from your SpaceDistributor @kevinrushforth please take a look. thanks! please review keep alive keep alive Happy birthday to me #1156 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1604462569 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1610013011 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1664515679 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1771286377 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2107764343 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2158600774 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2191995184 From nlisker at openjdk.org Thu Jun 27 17:32:01 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 27 Jun 2024 17:32:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... John and I discussed this off-list. I will write a short review of this change. ### Behavior The solution implements has the following behaviors, which are compared to the current (partially-flawed) ones: * Listeners are invoked in the order they were registered, with invalidation listeners being invoked before change listeners. This is also the current behavior. The behavior of invoking all listeners according to the order of registrations will be investigated. * Listeners that are removed during event propagation will be removed immediately, and will not receive the event (if they hadn't already). This differs from the current behavior of removing the listeners only after the event finished (buggy implementation). * Listeners that are added during event propagation will be effectively added after the event finishes, and will not receive the event during which they were added. This is also the current behavior (buggy implementation). The behavior of adding the listeners immediately, as is done with removal, will be investigated. * Nested events are invoked "depth-first", meaning that the parent event propagation is halted until the nested event finishes (see below). This differs from the current behavior that takes the "breadth-first" approach - each event finishes before the nested one starts (buggy implementation). * Nested events are only handled by listeners who received the parent event already so that they can react to the new change. Listeners that did not receive the parent event will only get a single (updated) event so that they don't react to irrelevant values. This allows vetoing, This differs from the current behavior that sends all events to all listeners (buggy implementation). ### Examples Suppose 5 change listeners are registered when an event starts. **Removal during an event** L1 gets the event L2 gets the event and removes L4 L3 gets the event and removes L2 (L2 already got the event) L4 does not get the event (removed by L2) L5 gets the event final listeners: L1, L3, L5 **Addition during an event** L1 gets the event L2 gets the event and adds L6 L3-L5 get the event L6 does not get the event (added by L2) final listeners: L1 - L6 **Nested event** (value change during an event) The observable value changes from 0 to 1 L1 gets 0->1 L2 gets 0->1 L3 gets 0->1 and sets the value to 2 (vetoing) L1-L3 get 1->2 (nested event - listeners can react to the new change) L4-L5 get 0->2 (parent event continues with the updated value) **Recursive change** (see https://continuously.dev/blog/2015/02/10/val-a-better-observablevalue.html) The code IntegerProperty p = new SimpleIntegerProperty(0); // L1 p.addListener((obs, old, val) -> { if (val.intValue() > 0) { p.set(val.intValue() - 1); } }); // L2 p.addListener((obs, old, val) -> System.out.println(old + " -> " + val)); p.set(2); will trigger L1 0->2 (set 1) L1 2->1 (set 0) L1 2->0 L2 is not triggered because the updated event is 0->0 Nothing is printed instead of the current behavior that will print 1->0 2->0 0->0 ### Equality check Change events require a comparison method for the old and new value. The 2 candidates are reference equality (`==`) and object equality (`Objects#equals`). There is some inconsistency in JavaFX about how this equality check is made (it is made in a few places on a few different types). It makes sense to do `==` with primitive types, and `equals` with `String` and the primitive wrappers. For other types, it depends on their characteristics. The "safer" option is `==` because a change that is triggered by `!=` can then be tested for `!oldValue.equals(newValue)` in the listener and be vetoed; the opposite is not possible. This might mean that the user will have to give the comparison method that is desired. Currently, `==` is used except for `String`. The behavior is preserved in this change, but will be investigated further in order to allows for more sensible change events. ### Performance Performance both in memory and speed is either equal or slightly worse than the current one. This is because the current behavior is wrong and fixing it entails more complications. In practice, the difference should be small. Registering many listeners on the same observable is not recommended and has caused issues in the past as well. Performance is a WIP and benchmarks will be posted later. It's the first item on my review list for FX 23. Hope to get the time for the review queue in 1-2 weeks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1507215618 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1934971092 From jhendrikx at openjdk.org Thu Jun 27 17:31:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:31:37 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: <07JDRMxcdryYit4bsUbbJrldyiQIGF7WuHQpsvVZNDs=.10d42bd9-e731-4be3-9106-c4f03b42ba57@github.com> On Tue, 27 Jun 2023 18:23:29 GMT, Andy Goryachev wrote: > @hjohn would you mind taking a look at this? using the ideas from your SpaceDistributor Will take a look this weekend ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1614422355 From angorya at openjdk.org Thu Jun 27 17:31:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:44 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Sun, 2 Jul 2023 12:53:05 GMT, John Hendrikx wrote: > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope *at the moment*, as this is a follow-up for a specific issue. > The `ResizeHelper` is short-lived, and created/recreated many times during a resize operation. I'm not even sure why it is being instantiated at all (it literally is created and discarded in a single method). convenience - it does have some data, and it's easier to keep code along with the data. > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. For example, I tried to use your SpaceDistributor from #1111 and it suffered from the same problem as bypassing the small delta path (by setting SMALL_DELTA=0) - when the user resizes the columns slowly, the same column gets the pixel and grows wider than the rest. >> > My observation is that this algorithm seems unable to provide a proper user resizing experience as it seems to discard important information it would need to do so. >> >> please elaborate, or point to a specific problem. It is entirely possible that a better algorithm might exist, but it might be out of scope _at the moment_, as this is a follow-up for a specific issue. > > It's hard to point to a specific problem when most of the algorithm used would be unnecessary if it used the initial conditions + current resize position as its basis for calculating the column sizes. My problem with this implementation is that it takes what is fundamentally a very simple algorithm (columns have sizes X,Y,Z and Y is resized 10 pixels larger, what should the layout be?) and turns it into a frame rate dependent, mouse movement dependent delta calculation. The initial conditions are discarded, and so a single drag resize of 10 pixels is NOT the same as a drag resize that captured several individual steps (1 + 2 + 3 + 4 pixels), while it really should be... > > On top of that, if indeed the algorithm is flawed, as I think it is, then there is no way to really fix it apart from some cosmetic changes. This then would be a lot of wasted effort. As I noted, there is no JUnit test for this code as of yet, and for such a complicated algorithm to be verified to be correct, I think it would need one to pass review. If we're willing to forego that, then I suppose a casual fix is in the cards, but I can't really see whether or not it would be correct (within its fundamental limitations) without extensive manual testing. > >> > The `SMALL_DELTA` constant that changes behavior on how large a "drag" was registered is a red flag; this shouldn't matter. The sizes should always be based on what they were initially (at the start of the drag), and where the cursor is currently, regardless of what path the cursor took to get there (ie. there should be no memory effects, the algorithm should only need the initial sizes + current position). >> >> This is not my experience. Specifically, the difference in behavior between small changes (when the users resizes the columns slowly and we get small deltas of 1 pixel) and large changes (e.g. when initially resizing the table, or the user moves the mouse quickly) are significant. > > Yes, it would be needed with this algorithm as it is dependent on mouse cursor speed and frame rate as it has no idea of what the initial positions were and how it arrived... Thank you for a detailed write up, @hjohn . One thing to note: the new code is a modification of the earlier work on constrained column resize policies, that logic is unaffected. The only difference is to recognize the fact that in an over-constrained situation sone constraints must be relaxed, and that eliminates multiple passes. Another consideration is that we are not re-writing Tree/TableView skin column resizing code. The fact that the current public APIs do not provide us with the initial condition and instead invoke the policy resize methods giving small deltas is a limitation this PR is not going to address. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 58: > >> 56: ConstrainedColumnResize.ResizeMode mode) { >> 57: this.rf = rf; >> 58: this.snap = (rf.getTableControl().isSnapToPixel() ? rf.getTableControl() : null); > > Obtaining the `Region` here is a bit hacky, this may be out of scope, but I would say `snap` should be a boolean, and the `snapXXX` helper methods in this class should call `ScaledMath`. Here i would disagree. I specifically do not want to replicate the snap code in the Region, since the Region publishes its snapping API. If there is a change in the snapping APIs in the Region, that change would need to be replicated again here, which I think is a bad idea. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 77: > >> 75: double cmin = snapCeil(c.getMinWidth()); // always honor min width! >> 76: double cmax = snapFloor(c.getMaxWidth()); // TableColumnBase.doSetWidth() clamps to (min,max) range >> 77: min[i] = cmin; > > Looking at `doSetWidth` I see that it clamps using unsnapped values, so the column can still be given an unsnapped size. When scale is 1.0, and the column for example has its min/max width set to 20.1 and 20.9, then snapCeil is 21 and snapFloor is 20 (so maximum is less than minimum, which may already be a bit dubious). When `doSetWidth` is called it will be clamped, resulting in `20.1` or `20.9`. For some reason, I've decided to leave that as is, but since you pointed it out, I think it ought to be fixed. I am going to implement proper snapping logic in ResizeFeaturesBase.setColumnWidth() using private APIs, with the intent to eventually convert them to public APIs with https://bugs.openjdk.org/browse/JDK-8311527 > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 125: > >> 123: private void distribute(double delta, double[] desired) { >> 124: double threshold = snapRound(SMALL_DELTA); >> 125: if (Math.abs(delta) > threshold) { > > The threshold is pretty arbitrary, I don't think it benefits from snap rounding here. I'd be more inclined to eliminate the difference between these two functions; I would expect that if a user drags a column resizer for 100 pixels, that it should make no difference whether that was a slow drag or a fast one, and the end visuals and column sizes should be exactly the same regardless. theoretically, may be. I could not achieve it with the algorithm that distributes space for large deltas, as it breaks down with small deltas, see my previous comment. snapRound(SMALL_DELTA) is indeed unnecessary. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622127738 PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622420462 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253385294 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253382973 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1253390837 From jhendrikx at openjdk.org Thu Jun 27 17:32:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Thu, 13 Apr 2023 15:58:32 GMT, Nir Lisker wrote: > John and I discussed this off-list. I will write a short review of this change. I have some small corrections I think. > * Nested events are invoked "depth-first", meaning that the parent event propagation is halted until the nested event finishes (see below). **This differs from the current behavior that takes the "breadth-first" approach** - each event finishes before the nested one starts (buggy implementation). Current behavior in `ExpressionHelper` is also depth first. > ### Equality check > Change events require a comparison method for the old and new value. The 2 candidates are reference equality (`==`) and object equality (`Objects#equals`). There is some inconsistency in JavaFX about how this equality check is made (it is made in a few places on a few different types). It makes sense to do `==` with primitive types, and `equals` with `String` and the primitive wrappers. For other types, it depends on their characteristics. The "safer" option is `==` because a change that is triggered by `!=` can then be tested for `!oldValue.equals(newValue)` in the listener and be vetoed; the opposite is not possible. This might mean that the user will have to give the comparison method that is desired. > > Currently, `==` is used except for `String`. The behavior is preserved in this change, but will be investigated further in order to allows for more sensible change events. Just to add here, there are actually two checks involved. When you "set" the value on a property, all properties do a reference equality check (apart from String) to determine whether to fire their listeners. This means that `InvalidationListener`s always fire in these circumstances. Change listeners however are protected by a 2nd check that is part of `ExpressionHelper`. This check uses `equals` for all property types. This means that the behavior of an `InvalidationListener` + `get` is sometimes subtly different from using a `ChangeListener`. When looking only at change listeners, this behavior makes sense for any type that is either primitive, immutable or mutable without overriding `equals`. For types that are mutable **and** override `equals`, the odd situation can occur that no change fires because the two instances are equal, but that the instance reference did change. When such a type is mutable, any further mutations could be missed. Simple example: List a = new ArrayList<>(); List b = a.clone(); ObjectProperty prop = new SimpleObjectProperty<>(a); ObjectProperty copy = new SimpleObjectProperty<>(a); // keep properties in sync: prop.addListener((obs, o, n) -> copy.set(n)); prop.get().equals(copy.get()); // true :-) // change first property: prop.set(b); // no change fired, they're equals! b.add("Hello"); prop.get().equals(copy.get()); // false, as prop has reference B, while copy has reference A still... It doesn't happen too often that properties are used with a type that is mutable with its own `equals` implementation, so this usually works correctly; for cases where you do want to use a mutable type with its own `equals` in an `ObjectProperty` though, I think having a variant of `ObjectProperty` with a reference equality check for its change listeners call may be sufficient. > ### Performance > Performance both in memory and speed is either equal or slightly worse than the current one. This is because the current behavior is wrong and fixing it entails more complications. In practice, the difference should be small. Registering many listeners on the same observable is not recommended and has caused issues in the past as well. Performance is a WIP and benchmarks will be posted later. The implementation is able to avoid using a wrapper for single invalidation/change listeners, which improves memory use a bit for the second most common state properties are in (having 1 listener only -- the most common state being having no listeners at all). As for adding/removing many listeners, I've have changed my stance on this and I don't think we should cater to situations that can have 10.000's of listeners -- even if add/remove performance was much improved, that won't make notifying such high amounts of listeners any better. Having such high amounts of listeners on a single property is a sign that something is wrong with the design, and even if it were to perform reasonably (which it won't due to the sheer amount of listener calls), it would be better to investigate how to avoid adding so many listeners, perhaps by adding a single listener and distributing the requested information more directly (via a shared model for example). This implementation will have similar performance when it comes to adding/removing listeners as the current implementation. It grows and shrinks the listener list on demand, with the major difference being that when the list is locked (due to an ongoing notification) it will avoid modifying the lists in such a way that indices of current listeners change (removals are `null`ed out). After the list unlocks, the list is compacted if there were any listener additions/removals, and `null`s (and weak listeners) are removed at that time. For this reason it may win out in some cases where listeners are added/removed during notifications, as it does not need to make copies of the listener list, but that is going to be a very rare occurrence. @nlisker I think I addressed all the issues, do you think it can move forward? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1507339488 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1625396623 From jhendrikx at openjdk.org Thu Jun 27 17:32:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <9AkS8BwqBtz0zusSbwZSPehjIxq0YgkpLudQGw96DEU=.8e3af06c-916c-4fd0-8e68-a2444ca4884d@github.com> On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... # Benchmarks Here are are some performance tests. The main take away is that invalidation performs roughly the same as before, while change listener notifications, which have acquired some more complexity, are about twice as slow. Also worth nothing is that the methods timed are generally so fast that a branch mispredication can have a big impact on the absolute performance. For example, when I re-order the method that "switches" on the data type (ListenerList, InvalidationListener or ChangeListener) I can get slightly better performance for some of these, losing performance somewhere else. I've picked a balance for now that makes the code easiest to read. The branch mispredication is also the reason that a single `ChangeListener` performs about as good as a `ListenerList` with up to 3 listeners (but of course, the single listener case consumes less memory). ExpressionHelper ListenerManager Benchmark (inv_chg_ListenerCounts) Mode Cnt Score Error Units Score Error Units FireValueChanged.binding 0, 0 avgt 10 2.247 ? 0.022 ns/op 2.335 ? 0.021 ns/op FireValueChanged.binding 0, 1 avgt 10 8.858 ? 0.136 ns/op 17.715 ? 0.092 ns/op FireValueChanged.binding 1, 0 avgt 10 2.551 ? 0.080 ns/op 2.267 ? 0.028 ns/op FireValueChanged.binding 0, 2 avgt 10 10.278 ? 0.148 ns/op 12.049 ? 0.103 ns/op FireValueChanged.binding 2, 0 avgt 10 4.831 ? 0.064 ns/op 5.560 ? 0.104 ns/op FireValueChanged.binding 2, 2 avgt 10 11.517 ? 0.114 ns/op 14.409 ? 0.511 ns/op FireValueChanged.binding 0, 3 avgt 10 11.301 ? 0.096 ns/op 13.756 ? 0.308 ns/op FireValueChanged.binding 3, 0 avgt 10 6.411 ? 0.246 ns/op 6.822 ? 0.105 ns/op FireValueChanged.binding 3, 3 avgt 10 13.410 ? 0.151 ns/op 16.564 ? 0.305 ns/op FireValueChanged.binding 0, 20 avgt 10 17.952 ? 0.182 ns/op 36.591 ? 0.344 ns/op FireValueChanged.binding 20, 0 avgt 10 11.817 ? 0.105 ns/op 12.869 ? 0.115 ns/op FireValueChanged.binding 20, 20 avgt 10 26.356 ? 0.344 ns/op 50.574 ? 2.497 ns/op FireValueChanged.longBinding 0, 0 avgt 10 1.337 ? 0.029 ns/op 2.221 ? 0.022 ns/op FireValueChanged.longBinding 0, 1 avgt 10 5.707 ? 0.084 ns/op 14.803 ? 0.051 ns/op FireValueChanged.longBinding 1, 0 avgt 10 1.408 ? 0.011 ns/op 2.355 ? 0.029 ns/op FireValueChanged.longBinding 0, 2 avgt 10 7.890 ? 0.080 ns/op 13.723 ? 0.329 ns/op FireValueChanged.longBinding 2, 0 avgt 10 4.082 ? 0.054 ns/op 5.419 ? 0.107 ns/op FireValueChanged.longBinding 2, 2 avgt 10 8.306 ? 0.133 ns/op 13.915 ? 0.206 ns/op FireValueChanged.longBinding 0, 3 avgt 10 8.695 ? 0.118 ns/op 16.345 ? 0.172 ns/op FireValueChanged.longBinding 3, 0 avgt 10 4.379 ? 0.063 ns/op 6.642 ? 0.155 ns/op FireValueChanged.longBinding 3, 3 avgt 10 10.434 ? 0.242 ns/op 16.890 ? 0.188 ns/op FireValueChanged.longBinding 0, 20 avgt 10 14.948 ? 0.172 ns/op 57.031 ? 0.631 ns/op FireValueChanged.longBinding 20, 0 avgt 10 11.345 ? 0.106 ns/op 12.995 ? 0.162 ns/op FireValueChanged.longBinding 20, 20 avgt 10 24.327 ? 0.606 ns/op 64.793 ? 0.903 ns/op FireValueChanged.property 0, 0 avgt 10 3.645 ? 0.101 ns/op 3.654 ? 0.053 ns/op FireValueChanged.property 0, 1 avgt 10 8.631 ? 0.131 ns/op 19.572 ? 0.224 ns/op FireValueChanged.property 1, 0 avgt 10 4.208 ? 0.041 ns/op 3.742 ? 0.066 ns/op FireValueChanged.property 0, 2 avgt 10 11.540 ? 0.345 ns/op 15.681 ? 0.240 ns/op FireValueChanged.property 2, 0 avgt 10 6.447 ? 0.231 ns/op 7.544 ? 0.165 ns/op FireValueChanged.property 2, 2 avgt 10 13.335 ? 0.267 ns/op 15.447 ? 0.365 ns/op FireValueChanged.property 0, 3 avgt 10 12.325 ? 0.237 ns/op 17.656 ? 0.488 ns/op FireValueChanged.property 3, 0 avgt 10 7.334 ? 0.087 ns/op 8.295 ? 0.151 ns/op FireValueChanged.property 3, 3 avgt 10 15.640 ? 0.264 ns/op 18.467 ? 0.489 ns/op FireValueChanged.property 0, 20 avgt 10 18.696 ? 0.346 ns/op 51.939 ? 0.965 ns/op FireValueChanged.property 20, 0 avgt 10 13.002 ? 0.163 ns/op 14.507 ? 0.334 ns/op FireValueChanged.property 20, 20 avgt 10 27.254 ? 0.328 ns/op 48.335 ? 0.916 ns/op Keep it open Keep it open ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1510471173 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1687501586 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1725415864 From mstrauss at openjdk.org Thu Jun 27 17:31:48 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:31:48 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev wrote: > Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . > > Removed earlier manual tester in favor of the monkey tester. > > It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622458602 From kcr at openjdk.org Thu Jun 27 17:32:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 27 Jun 2024 17:32:25 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v9] In-Reply-To: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> References: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> Message-ID: <0DU3FsSrnI0uzW-y9glRLpa7ygfCj5S36H1KP_vkgXY=.40d970fd-b488-4bc8-a643-d79e943e0696@github.com> On Thu, 27 Jun 2024 13:43:37 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add delta for assertStageScreenBounds Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2146051876 From angorya at openjdk.org Thu Jun 27 17:31:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:52 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: <0H2UuQQapuIvPTJww95dZSABt3l_9BpEjB8KX2tw-y8=.1ab17800-43df-4318-8447-57a414ecbce6@github.com> On Wed, 5 Jul 2023 20:31:09 GMT, Michael Strau? wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. > > Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. > > I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. I respectfully disagree, @mstr2 . This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622464854 From mhanl at openjdk.org Thu Jun 27 17:32:03 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 27 Jun 2024 17:32:03 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.44b21bd3-ea53-4072-ab69-1b96cc811797@github.com> On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... I completely forgot about this PR, but it looks very interesting, especially about the nested events. If helpful, I can test this soon in a bigger application, especially for any regressions. And of course also review the code, but need more time for that. Tested with a big application, did not find any regression. All listeners still work as expected, tested especially a lot of 'if something is selected, this button should be enabled/disabled' and the like. I did not checked the code yet, just a little bit. One question: Should I test something special/do you see a case which could cause a problem here? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1934958209 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1986169590 From mstrauss at openjdk.org Thu Jun 27 17:31:54 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:31:54 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Wed, 5 Jul 2023 20:31:09 GMT, Michael Strau? wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. > > Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. > > I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. > I respectfully disagree, @mstr2 . > > This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. It isn't just a theoretical issue. The proposed patch fails to keep the divider precisely at the cursor location, depending on frame rate and mouse movement speed. This is how the behavior manifests on my machine: https://github.com/openjdk/jfx/assets/43553916/79cf04be-bd18-4cfe-9c34-912978ee96ee ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1622726851 From jhendrikx at openjdk.org Thu Jun 27 17:32:03 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:03 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.44b21bd3-ea53-4072-ab69-1b96cc811797@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <2MzH3ZuU2xSg6bNY3i2ANGTZ3deVgKxVZwQkdjdYmuc=.44b21bd3-ea53-4072-ab69-1b96cc811797@github.com> Message-ID: On Thu, 8 Feb 2024 21:25:41 GMT, Marius Hanl wrote: > I completely forgot about this PR, but it looks very interesting, especially about the nested events. If helpful, I can test this soon in a bigger application, especially for any regressions. And of course also review the code, but need more time for that. @Maran23 both will be appreciated; I've tested this with my own FX applications for a while, and haven't encountered anything unexpected. > Tested with a big application, did not find any regression. All listeners still work as expected, tested especially a lot of 'if something is selected, this button should be enabled/disabled' and the like. I did not checked the code yet, just a little bit. One question: Should I test something special/do you see a case which could cause a problem here? I think testing it with a big application is excellent (I do the same here with my own large application), and I'm happy to hear you did not spot any regressions! This change does change (unspecified) behavior a little bit, although I think well within the documented contract of how change listeners operate (ie. applications should not be relying on the unspecified behavior). It will be hard to notice any change directly, as the changes are all related to advanced usage of listeners (adding/removing listeners during listener callbacks) or nested changes (the same property gets changed **during** a callback, directly or indirectly). 1. During a listener callback, you remove a listener that is currently being notified (ie. yourself, or any listener that may have triggered your callback that is further up the call stack) - Before this change, there is a chance that such a removed listener may still be called a few more times, despite it being removed in nested cases; its doubtful anyone is relying on that behavior, and (IMHO) these extra callbacks are more likely to break things, because things have been cleaned up (who assumes that their listener might still get called after removal?) 2. During a listener callback, you add a listener that is currently being notified (this can't be yourself, but it could be a listener on a property that triggered your callback that is further up the stack) - Before this change, this newly added listener may start participating in the current nested listener notification (ie. it would start participating halfway during a chain of nested changes). After this change, such a newly added listener would only be notified on the **next** top level change. It's unlikely anyone is relying on this behavior. 3. During a listener callback, you change the value the property it is attached to (or any property that may have led to your callback being called further up the callstack). - The most "common" scenario for this is veto-ing changes. For example, a property that can't be empty may get set to a non-empty value (or its original value) in a listener, triggering another notification. Your listener would not notice any differences (it would get called immediately with the change that you just did), but any listeners added after yours may not "see" the empty value because it was changed to something else before they were called. They will only see the new value (and the corresponding **correct** old value since last they were called) -- they may also be not called at all if the value was changed back to its original, and so they would be completely unaware of the temporary change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1937078085 PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-1986734228 From jhendrikx at openjdk.org Thu Jun 27 17:32:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 25 Mar 2024 13:32:11 GMT, Michael Strau? wrote: > `ListenerManager` is an obvious improvement, as it fixes incorrect behavior and allows listeners to veto changes. However, the behavior of `ListenerManager` is also an implementation detail and not documented anywhere. This leads me to the following questions: > > 1. How will users know that they can now do all of the things that were previously broken? Do we need a specification for what is allowed and what's not allowed? Currently the specification is vague enough that there's a lot of wiggle room. For example, we don't specify whether invalidation listeners are called before change listeners, yet a lot of code will be relying on that unknowingly. We also don't specify whether successive change listener calls should always be a change (ie. never get `A -> A`), or that it should match with what the previous change reported (ie. if called with `? -> B`, then the next call must be `B -> ?`). IMHO we should though. I would specify for example that: - Invalidation listeners are called before Change listeners (reason: invalidation listeners are a lower level concept defined in a higher level interface). They definitely should not be mixed (they're defined by two different interfaces). - Change listeners should (obviously as this MR fixes this) guarantee the old value makes sense: - Old value will be equal to previous new value (essential for patterns that use the old value to unregister a related listener) - Never called when old value equals new value (it's not a change then) -- this allows vetoing, and generally saves unnecessary calls We should probably also specify the order of calls (as code will again unknowingly be relying on this already): - A listener registered after a listener of the same type will always be called after earlier registered listeners (code relies on this in various ways, even in FX itself) - Listeners of different types follow a fixed order: invalidation first, changes second (code relies on this already) - The behavior of `ObservableValue`s that contain mutable values (ie. lists/sets/maps/atomics) will be undefined if those values are mutated while held by an observable (same as when you mutate keys that are currently part of a `Set`). We can also specify some behavior with regards to when an event can be received when adding and removing listeners, although I think that's less of an issue. > 2. Should this behavior be required for all valid `ObservableValue` implementations? (This would render many existing implementations defective.) It's hard to require anything in an interface, but I think the interface should specify this regardless. Just look at an interface like `Set` that requires a specific way of implementing `hashCode`. You can violate it easily, but you will suffer the consequences when comparing sets of different types. Same with custom implementations of `ObservableValue`. You take a risk when using some unvetted 3rd party implementation. At a minimum all implementations in JavaFX should follow the specification. This will likely cover most implementations of `ObservableValue`, leaving only a few custom implementations that are not 100% spec compliant (note: a lot of the problems only occur with nested changes, which occur only in complicated code that triggers a cascade of changes, usually layout/skin/css related). A problem there are the Set/List/Map `ObservableValue` implementations. They are not observable values, they are observable collections that deserve their own interface. Invalidation listeners are fine, but value listeners make no sense. I've looked into these before, and all I can say is that they take great liberties with what is considered a "change" (ignoring even the most basic specifications). I'd recommend deprecating the observable value parts of these, and moving users towards either invalidation or the collection specific change listeners. > 3. If `ObservableValue` implementations are not required to replicate the `ListenerManager` behavior, we should probably make it easily discoverable whether any particular implementation (most of them are properties) supports nested changes/vetoing. In most of the public API, there's no obvious way to see (without looking at the source code) whether a property implementation extends one of the `*PropertyBase` classes. I think if the implementation is in `javafx.*` it should be correct. Anyone can violate any interface (just look at custom collection implementations which often fail to follow the spec). We could provide a more lenient abstract base class or helper to make it easier to conform to the spec. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 58: > >> 56: * Constructs a new instance. >> 57: * >> 58: * @param accessor an {@link Accessor}, cannot be {@code null} > > There is no `accessor` parameter. Thanks for all the Javadoc checks; I've turned on some IDE warnings for these as it turns out they're harder to get right than I thought :) I fixed a couple more as well. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ArrayManager.java line 374: > >> 372: while (needed > max) { >> 373: min = mid; >> 374: mid = max; > > These two lines don't seem to be useful, as neither `min` nor `mid` are ever accessed after this point. Well spotted, they indeed are not needed in the 2nd loop. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 143: > >> 141: */ >> 142: public void fireValueChanged(I instance, T oldValue) { >> 143: Object data = getData(instance); > > The `data` value could be passed into this method, which would save a (potentially not devirtualized) method call. Thanks, I'll look into that, it might speed up the 1 listener cases a bit. The same applies to OldValueCachingListenerManager#getValue I think. I know it isn't possible for the add/remove calls, as the data may change if they're nested, but for `fireValueChanged` I never really checked after going to this strategy. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 145: > >> 143: Object data = getData(instance); >> 144: >> 145: if (data instanceof ListenerList) { > > Why is `ListenerList` checked first, when most observables only have a single `InvalidationListener`? For some (unclear to me) reason this order performs better in my benchmark, even for the cases that only have a single invalidation listener. I've tweaked this method extensively, with different orders, and this was about the best I could get it. That said, the differences are small, and we can go with a more logical order. > modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 101: > >> 99: * notification otherwise {@code false} >> 100: */ >> 101: public boolean notifyListeners(ObservableValue observableValue) { > > The code in this method is _almost_ identical to `ListenerList.notifyListeners(ObservableValue, T)`. > Given that this method is somewhat complex, I think it would be good to use a common implementation. > This will help with code review, and decrease the chance that both methods diverge further with future modifications. I agree with you there, and I've been looking what would be a good way to achieve this. I will take another look soon. My primary concern is that this is a somewhat critical path, and I would want to ensure that it doesn't cause too much performance regressions (I've already been optimizing all of this code with the help of a JMH test) > modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 164: > >> 162: } >> 163: >> 164: private void callInvalidationListener(ObservableValue instance, InvalidationListener listener) { > > This method is identical to `ListenerList.callInvalidationListener`. Yes, it would be good to just put these static somewhere. They don't really fit well in the manager class (as the List class which doesn't depend on manager would need to call them there), and the other way around is also odd, given that I only need to call them when not in "list" mode. Still, putting them package private in the ListenerListBase could work.... > modules/javafx.base/src/main/java/javafx/beans/property/ObjectPropertyBase.java line 91: > >> 89: @Override >> 90: public void addListener(InvalidationListener listener) { >> 91: LISTENER_MANAGER.addListener((ObjectPropertyBase) this, listener); > > I think the unchecked casts here can be removed if `ListenerManagerBase` is declared as `ListenerManagerBase>`, and `OldValueCachingListenerManager` accordingly. Then the `LISTENER_MANAGER` instance can be parameterized as `OldValueCachingListenerManager>`. Thanks, I gave up on that one a bit, I was looking for a better solution, but never got the generics quite the way I wanted them there, but your change works. I was primarily aiming to keep the casts as much out of the inner loops as possible. I still need to do one cast at this line, but it is a huge improvement: @Override public void addListener(ChangeListener listener) { LISTENER_MANAGER.addListener(this, (ChangeListener) listener); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2018972993 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167744831 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167744922 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272805838 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1272801049 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167754712 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167755526 PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167753159 From angorya at openjdk.org Thu Jun 27 17:31:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:54 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: <2y6CsiR4R_zKOCJPZIj3y_Os_y9G2ZAnyvDqdaTjgQk=.005df9ef-befc-4bbc-99db-57ff10ea9f86@github.com> On Thu, 6 Jul 2023 00:23:09 GMT, Michael Strau? wrote: >> I agree with John that a layout algorithm that uses incremental calculations will always be flawed in principle. The correct approach is to store the initial configuration, and then for each configuration change, go back to the initial configuration and recompute the layout solution. >> >> Now, we might still accept a bugfix for a flawed algorithm. But JDK-8299753 is an enhancement, not a bugfix. I'm not sure what to make of this: it's obviously a flawed approach, and basing an enhancement on a flawed approach means that someone would have to come back to this issue in the future and solve it correctly. >> >> I don't think that the issue at hand is so severe that it's a forced move to integrate this interim solution. > >> I respectfully disagree, @mstr2 . >> >> This fix is not an interim solution - unlike any theoretical considerations of "flawed approach", in practice this code does work as expected with integer and fractional scales, and, given our situation, it's highly unlikely that any alternative solutions will ever be considered, especially those that would affect existing public APIs. > > It isn't just a theoretical issue. The proposed patch fails to keep the divider precisely at the cursor location, depending on frame rate and mouse movement speed. This is how the behavior manifests on my machine: > > https://github.com/openjdk/jfx/assets/43553916/79cf04be-bd18-4cfe-9c34-912978ee96ee Thank you for the video, @mstr2 This is an intrinsic problem with the Tree/TableView - you can observe it even with the UNCONSTRAINED_RESIZE_POLICY. You both are right in that it's impossible to fix this without remembering the initial MOUSE_PRESSED position. I wonder if it's possible to fix it without making API changes. However, fixing this is out of scope for this PR. This PR deals with correctly handling of fractional scale (within the constraints of the current resize policy API) and cursor decoupling even when moving very slowly. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1623937662 From angorya at openjdk.org Thu Jun 27 17:31:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 17:31:54 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Fri, 30 Jun 2023 05:38:35 GMT, Karthik P K wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Left a inline comment. > Otherwise looks good to me @karthikpandelu @hjohn @kevinrushforth could you please review? > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ResizeHelper.java line 112: > >> 110: distribute(delta, pref); >> 111: } >> 112: } else if (delta > 0.0) { > > Do we need delta = 0.0 condition here? excellent question. we don't - zero delta means no change, so no action is needed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1834391879 PR Review Comment: https://git.openjdk.org/jfx/pull/1156#discussion_r1248011392 From mstrauss at openjdk.org Thu Jun 27 17:32:05 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:32:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Mon, 24 Jul 2023 22:09:49 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 143: >> >>> 141: */ >>> 142: public void fireValueChanged(I instance, T oldValue) { >>> 143: Object data = getData(instance); >> >> The `data` value could be passed into this method, which would save a (potentially not devirtualized) method call. > > Thanks, I'll look into that, it might speed up the 1 listener cases a bit. The same applies to OldValueCachingListenerManager#getValue I think. I know it isn't possible for the add/remove calls, as the data may change if they're nested, but for `fireValueChanged` I never really checked after going to this strategy. Have you considered passing `data` directly into the method? What is your conclusion? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1361519194 From jhendrikx at openjdk.org Thu Jun 27 17:32:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Sun, 16 Apr 2023 07:43:05 GMT, John Hendrikx wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 101: >> >>> 99: * notification otherwise {@code false} >>> 100: */ >>> 101: public boolean notifyListeners(ObservableValue observableValue) { >> >> The code in this method is _almost_ identical to `ListenerList.notifyListeners(ObservableValue, T)`. >> Given that this method is somewhat complex, I think it would be good to use a common implementation. >> This will help with code review, and decrease the chance that both methods diverge further with future modifications. > > I agree with you there, and I've been looking what would be a good way to achieve this. I will take another look soon. My primary concern is that this is a somewhat critical path, and I would want to ensure that it doesn't cause too much performance regressions (I've already been optimizing all of this code with the help of a JMH test) While looking that code over to see if it could be merged without impacting the general case, I discovered a small bug in the OldValueCaching version. After I fixed it, the code was even more similar than it was already. The only different still is the fact that the latest value must be kept track of whenever ObservableValue#getValue is called. I've now added an extra parameter to the generic version to allow for storing the latest value when it is queried (and not storing it if it's not needed). This seems to have a minimal performance impact only, so I think the trade off is acceptable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167895136 From mstrauss at openjdk.org Thu Jun 27 17:32:05 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:32:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: <7AQ0bfREYbXW3bhhBpoE5m3b1LcGdgIhPfqr9-Wx5bo=.9abd3162-4528-4349-8225-74ce24537995@github.com> On Sun, 16 Apr 2023 12:34:44 GMT, John Hendrikx wrote: >> I agree with you there, and I've been looking what would be a good way to achieve this. I will take another look soon. My primary concern is that this is a somewhat critical path, and I would want to ensure that it doesn't cause too much performance regressions (I've already been optimizing all of this code with the help of a JMH test) > > While looking that code over to see if it could be merged without impacting the general case, I discovered a small bug in the OldValueCaching version. After I fixed it, the code was even more similar than it was already. The only different still is the fact that the latest value must be kept track of whenever ObservableValue#getValue is called. > > I've now added an extra parameter to the generic version to allow for storing the latest value when it is queried (and not storing it if it's not needed). This seems to have a minimal performance impact only, so I think the trade off is acceptable. Have you considered adding a method like `void valueUpdated(T value) {}` to `ListenerList`? This will require `ListenerList` to have a type variable `T` (which `OldValueCachingListenerList` adds anyway). This method could then be called instead of `latestValueTracker.accept(newValue)`, and `OldValueCachingListenerList` can override it and store the value. The advantage of that would be that we don't need the `latestValueTracker` field. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167979736 From jhendrikx at openjdk.org Thu Jun 27 17:32:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 27 Jun 2024 17:32:05 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <7AQ0bfREYbXW3bhhBpoE5m3b1LcGdgIhPfqr9-Wx5bo=.9abd3162-4528-4349-8225-74ce24537995@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> <7AQ0bfREYbXW3bhhBpoE5m3b1LcGdgIhPfqr9-Wx5bo=.9abd3162-4528-4349-8225-74ce24537995@github.com> Message-ID: On Sun, 16 Apr 2023 17:20:08 GMT, Michael Strau? wrote: >> While looking that code over to see if it could be merged without impacting the general case, I discovered a small bug in the OldValueCaching version. After I fixed it, the code was even more similar than it was already. The only different still is the fact that the latest value must be kept track of whenever ObservableValue#getValue is called. >> >> I've now added an extra parameter to the generic version to allow for storing the latest value when it is queried (and not storing it if it's not needed). This seems to have a minimal performance impact only, so I think the trade off is acceptable. > > Have you considered adding a method like `void valueUpdated(T value) {}` to `ListenerList`? This will require `ListenerList` to have a type variable `T` (which `OldValueCachingListenerList` adds anyway). > > This method could then be called instead of `latestValueTracker.accept(newValue)`, and `OldValueCachingListenerList` can override it and store the value. The advantage of that would be that we don't need the `latestValueTracker` field. Yeah, I'll test that out, it's better not to have that extra field in that class. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1167981446 From mstrauss at openjdk.org Thu Jun 27 17:46:23 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 27 Jun 2024 17:46:23 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 22:10:38 GMT, Markus Mack wrote: > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. Good idea to deduplicate the code in `dataItemAdded` and `seriesAdded`. The patch looks good. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1488#pullrequestreview-2146094390 From kevin.rushforth at oracle.com Thu Jun 27 17:53:29 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Jun 2024 10:53:29 -0700 Subject: Old PR review emails from Skara Message-ID: <19f7df78-7328-43ad-8226-45d0fdeff57d@oracle.com> I'm not sure why Skara is replaying some old RFR messages from last year and earlier this year. It's either a glitch, or the bot is finally sending old messages that were not sent earlier for some reason. -- Kevin From mmack at openjdk.org Thu Jun 27 20:26:45 2024 From: mmack at openjdk.org (Markus Mack) Date: Thu, 27 Jun 2024 20:26:45 GMT Subject: RFR: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data Message-ID: This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. It covers all cases mentioned in the JBS ticket and adds a unit test. The settable `barGap` and `categoryGap` now should also behave as expected. There's a change regarding consistent placement of bars when there is more than one series: Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. There's a test for this situation as well. Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). ------------- Commit messages: - testTickMarksMatchBarPositionsAfterAnimation - testBarPositionsWithMultipleIncompleteSeries - BarChart: Fix bar position when there are missing data items in other series - BarChart: Fix sign error in bar offset layout calculation - CategoryAxis: Ensure requestAxisLayout is called and measureInvalid=true when animated properties change Changes: https://git.openjdk.org/jfx/pull/1492/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1492&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8198830 Stats: 119 lines in 3 files changed: 113 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1492.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1492/head:pull/1492 PR: https://git.openjdk.org/jfx/pull/1492 From angorya at openjdk.org Thu Jun 27 23:41:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 27 Jun 2024 23:41:26 GMT Subject: RFR: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data In-Reply-To: References: Message-ID: <9hC7-1m6fBkpRx150cZxWHYewYw69q2LjvIR0e5BPew=.b290cd3f-b1ec-4482-b271-847c2143a4ed@github.com> On Thu, 27 Jun 2024 20:22:24 GMT, Markus Mack wrote: > This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. > It covers all cases mentioned in the JBS ticket and adds a unit test. > > The settable `barGap` and `categoryGap` now should also behave as expected. > > There's a change regarding consistent placement of bars when there is more than one series: > Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. > This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. > There's a test for this situation as well. > > Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). modules/javafx.controls/src/main/java/javafx/scene/chart/CategoryAxis.java line 74: > 72: /** This is the position of the first category along this axis */ > 73: private final DoubleProperty firstCategoryPos = > 74: new SimpleDoubleProperty(this, "firstCategoryPos", 0) { question: shouldn't line 74 be indented 4 spaces instead 8? also, we probably should update copyright year in all the touched files, like so: * Copyright (c) 2010, 2024, Oracle and/or its affiliates. All rights reserved. (I'll do a full review tomorrow) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1492#discussion_r1657926068 From arapte at openjdk.org Fri Jun 28 05:48:27 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 28 Jun 2024 05:48:27 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` Providing a few comments on test. I might need a day or two more for testing/reviewing the fix. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 68: > 66: primaryStage.show(); > 67: > 68: launchLatch.countDown(); This countDown() should be called after stage is shown to ensure the stage shown before proceeding. `primaryStage.setOnShown(e -> Platform.runLater(launchLatch::countDown));` tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 75: > 73: public static void setupOnce() { > 74: Util.launch(launchLatch, MyApp.class); > 75: assertEquals(0, launchLatch.getCount()); Util.launch() asserts if launchLatch.countDown() does not occur in 15 seconds, so this line can be removed. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 90: > 88: StackPane root = myApp.root; > 89: > 90: runAndWait(() -> { All such calls can be changed to use `Util.runAndWait()` tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 103: > 101: }); > 102: > 103: Thread.sleep(500); Could use `Util.waitForIdle(Scene)` instead of sleep. It would reduce the test time and should work. We can consider a sleep if `Util.waitForIdle(Scene)` does not work. Similarly please see if other sleep calls can be removed. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 149: > 147: throw new RuntimeException(e); > 148: } > 149: } Please use the `Util.runAndWait()` instead of adding this method. So this method can be removed and all calls can be changed to Util.runAndWait(). Please do remove any imports that become unused afterwards. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 188: > 186: return result; > 187: } > 188: } Please add an empty line at the end. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2147056008 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658155426 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658158260 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658169114 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658173122 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658166372 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658161537 From mmack at openjdk.org Fri Jun 28 07:39:46 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 28 Jun 2024 07:39:46 GMT Subject: RFR: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data [v2] In-Reply-To: References: Message-ID: > This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. > It covers all cases mentioned in the JBS ticket and adds a unit test. > > The settable `barGap` and `categoryGap` now should also behave as expected. > > There's a change regarding consistent placement of bars when there is more than one series: > Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. > This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. > There's a test for this situation as well. > > Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). Markus Mack has updated the pull request incrementally with two additional commits since the last revision: - fix indentation - update copyright ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1492/files - new: https://git.openjdk.org/jfx/pull/1492/files/cb47e3c0..606a0628 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1492&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1492&range=00-01 Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jfx/pull/1492.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1492/head:pull/1492 PR: https://git.openjdk.org/jfx/pull/1492 From john.hendrikx at gmail.com Fri Jun 28 07:46:21 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Fri, 28 Jun 2024 09:46:21 +0200 Subject: Old PR review emails from Skara In-Reply-To: <19f7df78-7328-43ad-8226-45d0fdeff57d@oracle.com> References: <19f7df78-7328-43ad-8226-45d0fdeff57d@oracle.com> Message-ID: <024d35a9-0639-dcf6-d9b5-d44fc2f21ced@gmail.com> One of those PR's was mine, but I didn't touch it at all, I initially thought there were new comments. --John On 27/06/2024 19:53, Kevin Rushforth wrote: > I'm not sure why Skara is replaying some old RFR messages from last > year and earlier this year. It's either a glitch, or the bot is > finally sending old messages that were not sent earlier for some reason. > > -- Kevin > From azvegint at openjdk.org Fri Jun 28 07:57:51 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 07:57:51 GMT Subject: RFR: 8326712: Robot tests fail on XWayland Message-ID: Most of the headful test failures on XWayland are due to screen capture is not working. Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience.
So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. For ease of review, you can skip the changes in the first two commits: - First commit is a direct copy of files from OpenJDK - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). properties added: - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) - `javafx.robot.screenshotDebug` prints debug info if it is set to `true`
What are the remaining issues? 1. After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. So a change is required on OpenJDK side to fix this issue. 2. Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. 3. Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). This is to reduce overhead in case of frequent consecutive screen captures. There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `javafx.scene.robot.Robot#getPixelColor()` are called within 1 second. ------------- Commit messages: - Merge branch 'master' into xwayland/8326712_robot_tests - Use the secondary path for token storage only if it is writable and there is no writable file on the primary path. - make @SuppressWarnings("removal") individual - remove HEADLESS check - use "javafx." prefix for the properties - comment removal - distinguish JFX logs - AWT->JFX naming - Reuse awt tokens - Change properties prefixes from "fx." to "jfx." - ... and 6 more: https://git.openjdk.org/jfx/compare/ca04c87d...3aa56a2c Changes: https://git.openjdk.org/jfx/pull/1490/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326712 Stats: 14833 lines in 103 files changed: 14820 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1490.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1490/head:pull/1490 PR: https://git.openjdk.org/jfx/pull/1490 From kcr at openjdk.org Fri Jun 28 07:57:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 07:57:52 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... I did a cursory review, just looking at the changes since the first two commits, and it looks fine. Preliminary testing looks good. I think this is ready to take out of Draft. We'll want extra pairs of eyes on this one (so at least two "R"eviewers). I'd also like Gluon to verify that it builds on their CI system. Reviewers: @kevinrushforth @prrace @tiainen @azvegint When you do take it out of Draft, please write up something in the Description about the changes as a help to those who will be reviewing it. Also, can you merge in the latest master? In particular, I want to see a GHA run with the `javac -Werror` fix. modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkRobot.java line 39: > 37: import java.security.PrivilegedAction; > 38: > 39: @SuppressWarnings("removal") Maybe this can go on the individual elements that use the security manager? To do this, you might need to create a local "tmp" variable and then assign that to `screenshotMethod`. (either way, don't worry about the files you copied from AWT) modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 117: > 115: > 116: // use secondary path only if it already exists and writable > 117: Path path = Files.isWritable(secondaryPath) If both exist and are writable, then wouldn't you want to default to the primary path? If so, then I think the test should be something like `Files.isWritable(secondaryPath) && !Files.isWritable(primaryPath)`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1490#pullrequestreview-2146168288 PR Comment: https://git.openjdk.org/jfx/pull/1490#issuecomment-2195459814 PR Comment: https://git.openjdk.org/jfx/pull/1490#issuecomment-2195470151 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657594947 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657655951 From azvegint at openjdk.org Fri Jun 28 07:57:52 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 07:57:52 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Thu, 27 Jun 2024 18:15:53 GMT, Kevin Rushforth wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). >> This is to reduce overhead in case of frequent consecutive screen captures. >> >> There is a crash when an AWT ScreenCast session o... > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkRobot.java line 39: > >> 37: import java.security.PrivilegedAction; >> 38: >> 39: @SuppressWarnings("removal") > > Maybe this can go on the individual elements that use the security manager? To do this, you might need to create a local "tmp" variable and then assign that to `screenshotMethod`. > (either way, don't worry about the files you copied from AWT) Done for all cases. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 117: > >> 115: >> 116: // use secondary path only if it already exists and writable >> 117: Path path = Files.isWritable(secondaryPath) > > If both exist and are writable, then wouldn't you want to default to the primary path? If so, then I think the test should be something like `Files.isWritable(secondaryPath) && !Files.isWritable(primaryPath)`. Sure, it sounds reasonable, updated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658305497 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658306065 From prr at openjdk.org Fri Jun 28 07:57:52 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 28 Jun 2024 07:57:52 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/ScreencastHelper.java line 70: > 68: AccessController.doPrivileged((PrivilegedAction) () -> { > 69: final String str = > 70: System.getProperty("fx.robot.screenshotDebug", "false"); fx - > javafx modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 69: > 67: > 68: private static final String REL_NAME = > 69: ".fx/robot/screencast-tokens.properties"; should be .javafx However I think we can try to READ .awt (and .java) first and if it exists try to use that. Perhaps WRITE .javafx ? If we don't understand what is at .awt or .java then we would then READ .javafx and if it is not there or doesn't work CREATE .javafx The overall intent is that if a user authorised Java for AWT then we don't need to re-ask them for FX so long as we can parse what is there and it works modules/javafx.graphics/src/main/native-glass/gtk/fp_pipewire.h line 26: > 24: */ > 25: > 26: #ifdef HEADLESS There is no HEADLESS build for JavaFX. I see the same ifdef in other C files in this PR. I guess its harmless so I'll let Kevin decide what we should do tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java line 37: > 35: public class SwingNodeJDialogTest extends SwingNodeBase { > 36: > 37: @Test(timeout = 15000) Is this in milliseconds ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1655461505 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1655467715 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1655452918 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1655458869 From azvegint at openjdk.org Fri Jun 28 07:57:52 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 07:57:52 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 20:14:26 GMT, Phil Race wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). >> This is to reduce overhead in case of frequent consecutive screen captures. >> >> There is a crash when an AWT ScreenCast session o... > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/ScreencastHelper.java line 70: > >> 68: AccessController.doPrivileged((PrivilegedAction) () -> { >> 69: final String str = >> 70: System.getProperty("fx.robot.screenshotDebug", "false"); > > fx - > javafx Done. > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 69: > >> 67: >> 68: private static final String REL_NAME = >> 69: ".fx/robot/screencast-tokens.properties"; > > should be .javafx > However I think we can try to READ .awt (and .java) first and if it exists try to use that. > Perhaps WRITE .javafx ? > If we don't understand what is at .awt or .java then we would then READ .javafx and if it is not there or > doesn't work CREATE .javafx > > The overall intent is that if a user authorised Java for AWT then we don't need to re-ask them for FX so long as we can parse what is there and it works Updated to check two locations: 1. `.java/.robot/screencast-tokens.properties` - the default, should be used by both OpenJDK and JavaFx 2. `.awt/robot/screencast-tokens.properties` - this is currently the only location used by OpenJDK, but it should be changed to the first location after [JDK-8335267](https://bugs.openjdk.org/browse/JDK-8335267) is resolved. If there is a writable file at location `#2`, we won't try to read or write to location `#1`. > tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeJDialogTest.java line 37: > >> 35: public class SwingNodeJDialogTest extends SwingNodeBase { >> 36: >> 37: @Test(timeout = 15000) > > Is this in milliseconds ? Yes. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657436086 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657452752 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657435430 From azvegint at openjdk.org Fri Jun 28 07:57:53 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 07:57:53 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/ScreencastHelper.java line 220: > 218: throw new SecurityException( > 219: "Screen Capture in the selected area was not allowed" > 220: ); @kevinrushforth I think this SecurityException should be removed, as it is not mentioned in the javadoc for the `getPixelColor` or `getScreenCapture`. And we also do not want to throw another runtime exception. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658303570 From kcr at openjdk.org Fri Jun 28 07:57:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 07:57:53 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 20:06:33 GMT, Phil Race wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). >> This is to reduce overhead in case of frequent consecutive screen captures. >> >> There is a crash when an AWT ScreenCast session o... > > modules/javafx.graphics/src/main/native-glass/gtk/fp_pipewire.h line 26: > >> 24: */ >> 25: >> 26: #ifdef HEADLESS > > There is no HEADLESS build for JavaFX. I see the same ifdef in other C files in this PR. > I guess its harmless so I'll let Kevin decide what we should do I don't have a strong opinion. This file is unchanged relative to the original in AWT. The other three already have some changes, so I'd probably lean toward removing it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1657628078 From jvos at openjdk.org Fri Jun 28 07:57:53 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Jun 2024 07:57:53 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> On Thu, 27 Jun 2024 18:26:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/fp_pipewire.h line 26: >> >>> 24: */ >>> 25: >>> 26: #ifdef HEADLESS >> >> There is no HEADLESS build for JavaFX. I see the same ifdef in other C files in this PR. >> I guess its harmless so I'll let Kevin decide what we should do > > I don't have a strong opinion. This file is unchanged relative to the original in AWT. The other three already have some changes, so I'd probably lean toward removing it. With the headless platform that I started in the sandbox project, there is the concept of headless, but rather than compiling native code with `#ifdef HEADLESS` the current approach is to avoid those native compilations at all. However, I don't exclude that some parts of a file might make sense for a headless glass platform, where other parts should not be considered. In that case, the `ifdef HEADLESS` and in general the compile option `-DHEADLESS` would make sense. While this is not needed at this moment (and not even sure it will ever be needed), I am slightly in favor of keeping it here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658253705 From azvegint at openjdk.org Fri Jun 28 08:03:23 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 08:03:23 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> References: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> Message-ID: On Fri, 28 Jun 2024 07:04:18 GMT, Johan Vos wrote: >> I don't have a strong opinion. This file is unchanged relative to the original in AWT. The other three already have some changes, so I'd probably lean toward removing it. > > With the headless platform that I started in the sandbox project, there is the concept of headless, but rather than compiling native code with `#ifdef HEADLESS` the current approach is to avoid those native compilations at all. > However, I don't exclude that some parts of a file might make sense for a headless glass platform, where other parts should not be considered. In that case, the `ifdef HEADLESS` and in general the compile option `-DHEADLESS` would make sense. > While this is not needed at this moment (and not even sure it will ever be needed), I am slightly in favor of keeping it here. I already did the removal earlier, but I can bring it back once we come to an agreement. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658317416 From psadhukhan at openjdk.org Fri Jun 28 08:54:32 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 28 Jun 2024 08:54:32 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException Message-ID: Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... so when GlassScene.updateSceneState is called, it results in NPE. Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state ------------- Commit messages: - 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException Changes: https://git.openjdk.org/jfx/pull/1493/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1493&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334593 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1493.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1493/head:pull/1493 PR: https://git.openjdk.org/jfx/pull/1493 From jvos at openjdk.org Fri Jun 28 09:46:24 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 28 Jun 2024 09:46:24 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 07:49:26 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). >> This is to reduce overhead in case of frequent consecutive screen captures. >> >> There is a crash when an AWT ScreenCast session o... > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/ScreencastHelper.java line 220: > >> 218: throw new SecurityException( >> 219: "Screen Capture in the selected area was not allowed" >> 220: ); > > @kevinrushforth > I think this SecurityException should be removed, as it is not mentioned in the javadoc for the `getPixelColor` or `getScreenCapture`. And we also do not want to throw another runtime exception. If the SecurityException is not thrown, how does the caller of `getRGBPixels` knows that the result will not be correct because of the missing permission? (as opposed to being incorrect due to a failure) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658438482 From duke at openjdk.org Fri Jun 28 09:51:37 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Jun 2024 09:51:37 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` eduardsdv has updated the pull request incrementally with three additional commits since the last revision: - JDK-8322619: Fix waiting for the stage - JDK-8322619: Improve output message in test - JDK-8322619: Avoid using of Thread.sleep(..) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1451/files - new: https://git.openjdk.org/jfx/pull/1451/files/8aed95aa..a2383fd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=00-01 Stats: 32 lines in 1 file changed: 6 ins; 4 del; 22 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From duke at openjdk.org Fri Jun 28 09:51:38 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Jun 2024 09:51:38 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 05:17:41 GMT, Ambarish Rapte wrote: >> eduardsdv has updated the pull request incrementally with three additional commits since the last revision: >> >> - JDK-8322619: Fix waiting for the stage >> - JDK-8322619: Improve output message in test >> - JDK-8322619: Avoid using of Thread.sleep(..) > > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 68: > >> 66: primaryStage.show(); >> 67: >> 68: launchLatch.countDown(); > > This countDown() should be called after stage is shown to ensure the stage shown before proceeding. > `primaryStage.setOnShown(e -> Platform.runLater(launchLatch::countDown));` Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 75: > >> 73: public static void setupOnce() { >> 74: Util.launch(launchLatch, MyApp.class); >> 75: assertEquals(0, launchLatch.getCount()); > > Util.launch() asserts if launchLatch.countDown() does not occur in 15 seconds, so this line can be removed. Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 90: > >> 88: StackPane root = myApp.root; >> 89: >> 90: runAndWait(() -> { > > All such calls can be changed to use `Util.runAndWait()` Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 103: > >> 101: }); >> 102: >> 103: Thread.sleep(500); > > Could use `Util.waitForIdle(Scene)` instead of sleep. It would reduce the test time and should work. We can consider a sleep if `Util.waitForIdle(Scene)` does not work. Similarly please see if other sleep calls can be removed. Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 149: > >> 147: throw new RuntimeException(e); >> 148: } >> 149: } > > Please use the `Util.runAndWait()` instead of adding this method. So this method can be removed and all calls can be changed to Util.runAndWait(). > Please do remove any imports that become unused afterwards. Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 188: > >> 186: return result; >> 187: } >> 188: } > > Please add an empty line at the end. Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658440382 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658440585 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658444155 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658444269 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658443932 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1658443599 From duke at openjdk.org Fri Jun 28 10:08:24 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Jun 2024 10:08:24 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: <-0QmzhYi3xK2bmES3ZKP36-bY3tFm3cEWK9rffOD3d4=.8e2fcb9d-ab08-4ba4-b21c-16e38c5073cc@github.com> References: <-0QmzhYi3xK2bmES3ZKP36-bY3tFm3cEWK9rffOD3d4=.8e2fcb9d-ab08-4ba4-b21c-16e38c5073cc@github.com> Message-ID: <08RtIj0xnswMhrw0xnH3G3eJX9BA8Yg1lAlg55sAxHY=.7d2f9f05-4f24-423d-8028-0856afaeb63c@github.com> On Sat, 18 May 2024 14:11:36 GMT, Kevin Rushforth wrote: >>> At a minimum I think the tests that are part of this PR should be included in FX whichever fix ends up being integrated. >> >> The test has already been added to both PRs. >> >>> I'm only wondering if the code in ``paintImpl`` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again. >> >> Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful. >> >> I'm fine with each of them. What do the others think? > >> > I'm only wondering if the code in `paintImpl` should always clear the dirty bits even if an exception occurs during painting, to harden it against potential bugs and not end up trying to repaint again and again likely getting the same exception again and again. >> >> Hm, that can indeed happen. On the other hand, if the dirty flag is reset even in the case of an exception, parts of the UI may not be updated for a long time until a node in that area receives a change. The question is which of these two options is the least harmful. >> >> I'm fine with each of them. What do the others think? > > I'd probably lean towards addressing this in a follow-up issue, if there turns out to be a need. > > @arapte can you look at this when you review it? @kevinrushforth The build fails on Linux. Can you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2196559621 From azvegint at openjdk.org Fri Jun 28 10:08:27 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 10:08:27 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 09:44:03 GMT, Johan Vos wrote: > If the SecurityException is not thrown, how does the caller of getRGBPixels knows that the result will not be correct because of the missing permission? (as opposed to being incorrect due to a failure) He won't know it. An indirect result of failure can be a black image. The [current documentation](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java#L240) documentation specifies only IllegalStateException and NullPointerException. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658462409 From fkirmaier at openjdk.org Fri Jun 28 10:13:56 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 28 Jun 2024 10:13:56 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8322619: Adjust test: remove Thread.sleep(), runAndWait() ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1310/files - new: https://git.openjdk.org/jfx/pull/1310/files/e3163f30..b23c0838 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=04-05 Stats: 31 lines in 1 file changed: 6 ins; 4 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From duke at openjdk.org Fri Jun 28 10:25:58 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Jun 2024 10:25:58 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` eduardsdv 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 remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag - JDK-8322619: Fix waiting for the stage - JDK-8322619: Improve output message in test - JDK-8322619: Avoid using of Thread.sleep(..) - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1451/files - new: https://git.openjdk.org/jfx/pull/1451/files/a2383fd9..e3bd58f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=01-02 Stats: 65198 lines in 336 files changed: 37377 ins; 14876 del; 12945 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From fkirmaier at openjdk.org Fri Jun 28 10:34:58 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Fri, 28 Jun 2024 10:34:58 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v7] In-Reply-To: References: Message-ID: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. Florian Kirmaier 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 seven additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8322544-render-culling - JDK-8322619: Adjust test: remove Thread.sleep(), runAndWait() - JDK-8322619: Add test - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. - JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0 - reverted accidental change in the .idea folder - JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1310/files - new: https://git.openjdk.org/jfx/pull/1310/files/b23c0838..770b1f7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1310&range=05-06 Stats: 389969 lines in 7881 files changed: 227761 ins; 103938 del; 58270 mod Patch: https://git.openjdk.org/jfx/pull/1310.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1310/head:pull/1310 PR: https://git.openjdk.org/jfx/pull/1310 From duke at openjdk.org Fri Jun 28 10:42:27 2024 From: duke at openjdk.org (eduardsdv) Date: Fri, 28 Jun 2024 10:42:27 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv 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 remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag > - JDK-8322619: Fix waiting for the stage > - JDK-8322619: Improve output message in test > - JDK-8322619: Avoid using of Thread.sleep(..) > - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. Ok. I solved the build by merging from the master branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2196608177 From kcr at openjdk.org Fri Jun 28 13:15:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 13:15:28 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> Message-ID: On Fri, 28 Jun 2024 08:01:09 GMT, Alexander Zvegintsev wrote: >> With the headless platform that I started in the sandbox project, there is the concept of headless, but rather than compiling native code with `#ifdef HEADLESS` the current approach is to avoid those native compilations at all. >> However, I don't exclude that some parts of a file might make sense for a headless glass platform, where other parts should not be considered. In that case, the `ifdef HEADLESS` and in general the compile option `-DHEADLESS` would make sense. >> While this is not needed at this moment (and not even sure it will ever be needed), I am slightly in favor of keeping it here. > > I already did the removal earlier, but I can bring it back once we come to an agreement. Johan makes a good point, so go ahead and add it back. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658725278 From kcr at openjdk.org Fri Jun 28 13:23:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 13:23:25 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 10:05:48 GMT, Alexander Zvegintsev wrote: >> If the SecurityException is not thrown, how does the caller of `getRGBPixels` knows that the result will not be correct because of the missing permission? (as opposed to being incorrect due to a failure) > >> If the SecurityException is not thrown, how does the caller of getRGBPixels knows that the result will not be correct because of the missing permission? (as opposed to being incorrect due to a failure) > > He won't know it. An indirect result of failure can be a black image. > The [current documentation](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java#L240) documentation specifies only IllegalStateException and NullPointerException. Since `SecurityException` is deprecated, we should not throw that. In a similar situation on macOS (user has not enabled screen capture), we return a blank (all black) image, so I think that's what we would do here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658735775 From sykora at openjdk.org Fri Jun 28 13:57:23 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Fri, 28 Jun 2024 13:57:23 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... The build still works as expected and documented on our CI infrastructure. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1490#pullrequestreview-2148098931 From tsayao at openjdk.org Fri Jun 28 13:57:23 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Fri, 28 Jun 2024 13:57:23 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... Just of out curiosity, please don't mind it too much: Why the piperwire include files are included? Since the infraestucture should be present for it to work (pipewire is quite new and not present on older linux distributions) a runtime check is needed anyways. What's the advantage of calling dbus functions directly and not use libportal? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1490#issuecomment-2196980520 From kcr at openjdk.org Fri Jun 28 13:57:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 13:57:23 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> Message-ID: On Fri, 28 Jun 2024 13:12:57 GMT, Kevin Rushforth wrote: >> I already did the removal earlier, but I can bring it back once we come to an agreement. > > Johan makes a good point, so go ahead and add it back. Worth noting is that this `HEADLESS` check is just an assertion to verify that the build logic properly excludes the file from the build when building headless. It otherwise does nothing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1658790474 From kcr at openjdk.org Fri Jun 28 14:15:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 14:15:24 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: References: Message-ID: <7d7Tua0RylGyUJoQ81GlWgScWPdgxjMBtQJBSGvWSnw=.a66ca07b-dbdd-425f-90d4-2120cfc29d6c@github.com> On Fri, 28 Jun 2024 08:49:49 GMT, Prasanta Sadhukhan wrote: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state Can you add an automated test to cover this fix? Worth noting, this won't fully solve the problem that the reporter of this bug filed. The null check will prevent the NPE, but the scene will still not be visible. To allow removing and then re-adding the `JFXPanel`, we would need to not call `Window.hide` when the `JFXPanel` is removed. We should file a follow-on Enhancement to consider doing this, but that will need more discussion. The main point that would need to be solved is to figure out when to call `Window.hide` if not when the `JFXPanel` is removed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2197030820 From kcr at openjdk.org Fri Jun 28 15:10:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 15:10:24 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 08:49:49 GMT, Prasanta Sadhukhan wrote: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state @prsadhuk One more question: Do you know what changed in JavaFX 21 to trigger the NPE? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2197145846 From azvegint at openjdk.org Fri Jun 28 16:01:25 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 16:01:25 GMT Subject: RFR: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 13:54:54 GMT, Thiago Milczarek Sayao wrote: > Just of out curiosity, please don't mind it too much: > > Why the piperwire include files are included? Since the infraestucture should be present for it to work (pipewire is quite new and not present on older linux distributions) a runtime check is needed anyways. > > What's the advantage of calling dbus functions directly and not use libportal? This is mostly a copy and paste of the OpenJDK code, which should be able to be built on fairly old Linux distributions (consider OpenJDK backports to earlier versions), and we didn't want to add any new external dependencies there. So with this changeset, we are just bringing tested code with minimal changes to JFX. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1490#issuecomment-2197228454 From angorya at openjdk.org Fri Jun 28 16:34:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Jun 2024 16:34:27 GMT Subject: RFR: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 07:39:46 GMT, Markus Mack wrote: >> This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. >> It covers all cases mentioned in the JBS ticket and adds a unit test. >> >> The settable `barGap` and `categoryGap` now should also behave as expected. >> >> There's a change regarding consistent placement of bars when there is more than one series: >> Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. >> This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. >> There's a test for this situation as well. >> >> Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). > > Markus Mack has updated the pull request incrementally with two additional commits since the last revision: > > - fix indentation > - update copyright Thank you @drmarmac for fixing all this bug (and adding unit tests!) Verified that the bug is fixed, including the two scenarios mentioned in the comments, with animation on and off. The fix is pretty straightforward, I think one reviewer is sufficient. modules/javafx.controls/src/main/java/javafx/scene/chart/BarChart.java line 428: > 426: } > 427: > 428: index++; this is correct. not sure how the existing tests did not find this problem. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1492#pullrequestreview-2148450033 PR Review Comment: https://git.openjdk.org/jfx/pull/1492#discussion_r1659001879 From azvegint at openjdk.org Fri Jun 28 18:12:37 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 18:12:37 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: References: Message-ID: <7QJTGc4K0huX4wyNPqoizg22cAT7AwO5_WiUCRIuGNI=.84f00c04-4120-4b58-a751-24ed51589c0a@github.com> > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There is a crash when an AWT ScreenCast session overlaps with the FX ScreenCast session. E.g. `java.awt.Robot#getPixelColor()` and `jav... Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: - do not throw SecurityException - Revert "remove HEADLESS check" ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1490/files - new: https://git.openjdk.org/jfx/pull/1490/files/3aa56a2c..33fa5385 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=00-01 Stats: 31 lines in 6 files changed: 22 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1490.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1490/head:pull/1490 PR: https://git.openjdk.org/jfx/pull/1490 From azvegint at openjdk.org Fri Jun 28 18:12:37 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 18:12:37 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 13:20:57 GMT, Kevin Rushforth wrote: >>> If the SecurityException is not thrown, how does the caller of getRGBPixels knows that the result will not be correct because of the missing permission? (as opposed to being incorrect due to a failure) >> >> He won't know it. An indirect result of failure can be a black image. >> The [current documentation](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java#L240) documentation specifies only IllegalStateException and NullPointerException. > > Since `SecurityException` is deprecated, we should not throw that. > > In a similar situation on macOS (user has not enabled screen capture), we return a blank (all black) image, so I think that's what we would do here. Updated to return a blank image if permission is not granted. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1659136275 From azvegint at openjdk.org Fri Jun 28 18:12:37 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 28 Jun 2024 18:12:37 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: References: <4rIC9LGAWiC95eIdN40dyjQQL40tULBR6i1F6KhVYus=.5737426f-b824-493a-964f-a4dc40703600@github.com> Message-ID: On Fri, 28 Jun 2024 13:52:10 GMT, Kevin Rushforth wrote: >> Johan makes a good point, so go ahead and add it back. > > Worth noting is that this `HEADLESS` check is just an assertion to verify that the build logic properly excludes the file from the build when building headless. It otherwise does nothing. The `HEADLESS` check is back. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1659138998 From prr at openjdk.org Fri Jun 28 18:25:26 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 28 Jun 2024 18:25:26 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 18:07:52 GMT, Alexander Zvegintsev wrote: >> Since `SecurityException` is deprecated, we should not throw that. >> >> In a similar situation on macOS (user has not enabled screen capture), we return a blank (all black) image, so I think that's what we would do here. > > Updated to return a blank image if permission is not granted. > Since `SecurityException` is deprecated, we should not throw that. > > In a similar situation on macOS (user has not enabled screen capture), we return a blank (all black) image, so I think that's what we would do here. No, SecurityException is NOT deprecated and there are no plans to deprecate it. https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/SecurityException.html#%3Cinit%3E() This kind of platform reason for a "SecurityException" is precisely why it isn't deprecated even though the Java SecurityManager is deprecated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1659151356 From kcr at openjdk.org Fri Jun 28 18:43:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 28 Jun 2024 18:43:25 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: References: <4lj8RBmBG3qGBvdvIF7kT8WqdsWI1KpItmVDXIy6ICU=.8690377b-bea1-432f-9313-6ed18c707031@github.com> Message-ID: On Fri, 28 Jun 2024 18:22:36 GMT, Phil Race wrote: >> Updated to return a blank image if permission is not granted. > >> Since `SecurityException` is deprecated, we should not throw that. >> >> In a similar situation on macOS (user has not enabled screen capture), we return a blank (all black) image, so I think that's what we would do here. > > No, SecurityException is NOT deprecated and there are no plans to deprecate it. > > https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/SecurityException.html#%3Cinit%3E() > > This kind of platform reason for a "SecurityException" is precisely why it isn't deprecated even though the Java SecurityManager is deprecated. Thanks for the correction about "SecurityException" not being deprecated. I still think that for this PR, we should not throw an exception, since we A) don't specify it to do so, and B) don't do that on macOS in a nearly identical situation. We could consider a future RFE to change the spec (and maybe the behavior). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1659169563 From andy.goryachev at oracle.com Fri Jun 28 21:04:43 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 28 Jun 2024 21:04:43 +0000 Subject: Should we document Styleable properties? Message-ID: Dear fellow developers: Should we document which properties are styleable with CSS in javadoc? Would that be useful? Example: /** * Determines the caret blink period. This property cannot be set to {@code null}. *

* This is a {@link StyleableProperty} with the name {@code -fx-caret-blink-period}. *

alternative: * This property can be styled with CSS using {@code -fx-caret-blink-period} name. * @implNote The property object implements {@link StyleableProperty} interface. Other ideas are also welcome. -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Jun 28 21:10:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 28 Jun 2024 21:10:23 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 08:49:49 GMT, Prasanta Sadhukhan wrote: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state Since this problem straddles two different toolkits, I would suggest to specify a minimum of 2 reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2197662517 From duke at openjdk.org Sat Jun 29 15:02:24 2024 From: duke at openjdk.org (duke) Date: Sat, 29 Jun 2024 15:02:24 GMT Subject: RFR: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data [v2] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 07:39:46 GMT, Markus Mack wrote: >> This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. >> It covers all cases mentioned in the JBS ticket and adds a unit test. >> >> The settable `barGap` and `categoryGap` now should also behave as expected. >> >> There's a change regarding consistent placement of bars when there is more than one series: >> Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. >> This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. >> There's a test for this situation as well. >> >> Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). > > Markus Mack has updated the pull request incrementally with two additional commits since the last revision: > > - fix indentation > - update copyright @drmarmac Your change (at version 606a0628c586988cecd0a5c73342419d32953b80) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1492#issuecomment-2198222070 From mmack at openjdk.org Sat Jun 29 16:51:25 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 29 Jun 2024 16:51:25 GMT Subject: Integrated: 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data In-Reply-To: References: Message-ID: On Thu, 27 Jun 2024 20:22:24 GMT, Markus Mack wrote: > This PR fixes the placement of `BarChart` bars and category tick marks, particularly when adding data / multiple series and enabling animations. > It covers all cases mentioned in the JBS ticket and adds a unit test. > > The settable `barGap` and `categoryGap` now should also behave as expected. > > There's a change regarding consistent placement of bars when there is more than one series: > Now, for example, if there are two series S1 and S2, S1 bars will always be on the left and S2 bars will always be on the right side of the tick mark. > This means that if some data category (=x-value) is only present in S2, but not S1, the bar will still be drawn on the right. The previous behavior, if the marks weren't off completely, would have put it on the left which I'd say looks inconsistent. > There's a test for this situation as well. > > Note this does not fix [JDK-8334873](https://bugs.openjdk.org/browse/JDK-8334873) where bars get stuck while having different widths. There seem to be additional issues which seem not directly related to the changed code and are probably out of scope for this PR (unless we see some regressions). This pull request has now been integrated. Changeset: 1fb8755d Author: Markus Mack Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1fb8755dc6452bdb07685c02272ecfc578fb1eba Stats: 121 lines in 3 files changed: 113 ins; 2 del; 6 mod 8198830: BarChart: auto-range of CategoryAxis not working on dynamically setting data Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1492