Re: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+
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 can confirm that this change fixes a Problem for more users. Actually, i have a built with exactly the same change. So if this doesn't break anything, it would be great to see this integrated. - PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2134598427
Re: JavaFX TableView text in the cells of the columns seems to jump
Hi Andy Maybe a fix (quick?) could be a option to always show the scrollbar? I have used that option before in HTML/CSS: https://www.w3schools.com/howto/howto_css_force_scrollbars.asp Kind Regards Mads Den tirs. 26. mar. 2024 kl. 16.31 skrev Andy Goryachev < andy.goryac...@oracle.com>: > Hi there. > > > > Thank you for bringing this up in the mailing list (we ***do not*** > monitor stackoverflow). > > > > Do I understand it correctly from this stackoverflow posting that the > problem is a momentary adjustment of the columns when the vertical scroll > bar appears? And that it works correctly otherwise? > > > > If that's the case, yes - this is the expected behavior, at least given > the current design of the TableView skin. If one adds a change listener > to, let's say, the last column, one will see three updates: > > > >1. in TableColumnHeader.doColumnAutoSize() as a response to setting >the scene >2. TableColumnHeader.resizeColumnToFitContent(), called by >TableViewSkinBase.updateContentWidth() as a response to > Scene.doLayoutPass() >3. TableView.setContentWidth() as a response to >VirtualFlow.computeBarVisibility() when it decides the vertical scroll bar >needs to be shown. > > > > What I can't tell is whether steps 2 and 2 can be combined - in other > words, whether it is possible to know that the vertical scroll bar needs to > be shown before the layout pass is done. I am sure it can be in the case > of the fixed row height, but if the row heights depend on the content width > the things might get complicated. > > > > If it can, we can try to investigate, though it will be a low priority > enhancement (the table does work correctly save for a momentary flicker). > I am going to create a JBS ticket > https://bugs.openjdk.org/browse/JDK-8329104 to investigate. > > > > Cheers, > > -andy > > > > > > > > > > > > > > *From: *openjfx-dev on behalf of Mads < > mailtiltss...@gmail.com> > *Date: *Tuesday, March 26, 2024 at 05:58 > *To: *openjfx-dev@openjdk.org > *Subject: *JavaFX TableView text in the cells of the columns seems to jump > > Please see this Stack Overflow post where I have tried my best to document > what is going on: > > > https://stackoverflow.com/questions/77369768/javafx-tableview-text-in-the-cells-of-the-columns-seems-to-jump > > Seems to be an issue with CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS when > drawing the table for the first time and when vertical scrollbar is added? > > Is this how it is intended to be? > > Regards >
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into feature/selector-performance-improvement > - Merge remote-tracking branch 'upstream/master' into > feature/selector-performance-improvement > - Added 100% coverage test for FixedCapacitySet > - Move getStyleClassNames to location it was introduced to reduce diff > - Remove deprecations > - Add @Deprecated tag > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides > - Optimize performance of OpenAddressed Set just in case it is ever used > - Fix docs > - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java line 419: > 417: */ > 418: > 419: assert elements.length > requestedCapacity : "must have more > buckets than capacity"; This just asserts that the previous three lines of code were correct. Seems a bit excessive to me, if you really need this tested, I'd prefer a unit test. - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1616923824
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 09:43:28 GMT, Michael Strauß wrote: >> John Hendrikx has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'openjdk:master' into >> feature/selector-performance-improvement >> - Merge remote-tracking branch 'upstream/master' into >> feature/selector-performance-improvement >> - Added 100% coverage test for FixedCapacitySet >> - Move getStyleClassNames to location it was introduced to reduce diff >> - Remove deprecations >> - Add @Deprecated tag >> - Remove commented code in BitSetTest >> - Remove unnecessary addAll overrides >> - Optimize performance of OpenAddressed Set just in case it is ever used >> - Fix docs >> - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java > line 419: > >> 417: */ >> 418: >> 419: assert elements.length > requestedCapacity : "must have >> more buckets than capacity"; > > This just asserts that the previous three lines of code were correct. Seems a > bit excessive to me, if you really need this tested, I'd prefer a unit test. True, but I think it's a lot easier to follow than the logic before it. I see it a bit more as a hint to future maintainers (which might be me) that there are assumptions being made here that code relies on. - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617025821
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 11:01:21 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/FixedCapacitySet.java >> line 419: >> >>> 417: */ >>> 418: >>> 419: assert elements.length > requestedCapacity : "must have >>> more buckets than capacity"; >> >> This just asserts that the previous three lines of code were correct. Seems >> a bit excessive to me, if you really need this tested, I'd prefer a unit >> test. > > True, but I think it's a lot easier to follow than the logic before it. I see > it a bit more as a hint to future maintainers (which might be me) that there > are assumptions being made here that code relies on. I understand that, my objection is only with the `assert` keyword. I don't like test code in production code (which this is, it verifies that an assumption holds). I think only unit tests should contain test code, but it's a minor issue and I'll reapprove as-is. - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617055213
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into feature/selector-performance-improvement > - Merge remote-tracking branch 'upstream/master' into > feature/selector-performance-improvement > - Added 100% coverage test for FixedCapacitySet > - Move getStyleClassNames to location it was introduced to reduce diff > - Remove deprecations > - Add @Deprecated tag > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides > - Optimize performance of OpenAddressed Set just in case it is ever used > - Fix docs > - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab Marked as reviewed by mstrauss (Committer). - PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2082501449
Re: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling
On Sun, 26 May 2024 12:44:23 GMT, Marius Hanl wrote: > Yeah this is a 'known bug' for me, and has nothing to do with this fix. I do not see the issue without the fix though (at the same resolution). - PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2135380812
Integrated: 8332539: Update libxml2 to 2.12.7
On Fri, 24 May 2024 18:18:22 GMT, Hima Bindu Meda wrote: > Updated libxml to v2.12.7. Sanity testing looks fine. No issue seen This pull request has now been integrated. Changeset: dedcf1d2 Author:Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/dedcf1d236b5429dcf3c42f5fd1095b28d5da063 Stats: 67 lines in 9 files changed: 26 ins; 9 del; 32 mod 8332539: Update libxml2 to 2.12.7 Reviewed-by: kcr, sykora - PR: https://git.openjdk.org/jfx/pull/1464
RFR: 8087444: CornerRadii with different horizontal and vertical values treated as uniform
This PR fixes the incorrect computation of the `CornerRadii.uniform` flag for the 16-argument constructor. I've also added tests for all other constructors. - Commit messages: - fixed computation of uniform flag - failing test Changes: https://git.openjdk.org/jfx/pull/1465/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8087444 Stats: 82 lines in 2 files changed: 69 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1465.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1465/head:pull/1465 PR: https://git.openjdk.org/jfx/pull/1465
Re: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6]
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
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?
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1617617930
Re: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6]
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 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? 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? - PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1617624406 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1617620949
Re: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v6]
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 The behavior appears to be correct with the latest fix. - PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2135761002
Re: RFR: 8332863: Crash in JPEG decoder if we enable MEM_STATS
On Fri, 24 May 2024 06:48:50 GMT, Jayathirth D V wrote: > In IJG library's jmemmgr.c file we can define MEM_STATS(by default this flag > is not defined and we don't see any issue) to enable printing of memory > statistics log. But if we enable it, we get crash while disposing IJG stored > objects in jmemmgr->free-pool() function. > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0001269d5164, pid=47784, tid=259 > # > # JRE version: Java(TM) SE Runtime Environment (21.0+35) (build > 21+35-LTS-2513) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (21+35-LTS-2513, mixed mode, > sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) > # Problematic frame: > # C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > # > # No core dump will be written. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > --- T H R E A D --- > > Current thread (0x000121a42c00): JavaThread "JavaFX Application Thread" > [_thread_in_native, id=259, stack(0x00016d11c000,0x00016d918000) > (8176K)] > > Stack: [0x00016d11c000,0x00016d918000], sp=0x00016d912780, free > space=8153k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libjavafx_iio.dylib+0x49164] free_pool+0x88 > C [libjavafx_iio.dylib+0x49410] self_destruct+0x3c > C [libjavafx_iio.dylib+0xe888] jpeg_destroy+0x3c > C [libjavafx_iio.dylib+0x4bb1c] imageio_dispose+0x98 > C [libjavafx_iio.dylib+0x4b178] disposeIIO+0x2c > C [libjavafx_iio.dylib+0x4b140] > Java_com_sun_javafx_iio_jpeg_JPEGImageLoader_disposeNative+0x2c > > > This is happening because we delete the error handler before we actually > start deleting IJG stored objects and while freeing the IJG objects we try to > access cinfo->err->trace_level of error handler. This early deletion of error > handler is happening in jpegloader.c->imageio_dispose() function. > > I have moved deletion of error handler logic after we destroy IJG stored > objects in jpegloader.c->imageio_dispose(). This resolves this issue. > There is no regression test case because we need to enable MEM_STATS flag to > see this issue. > Ran graphics unit tests also and i don't see any issues with this change. This is a safe change, because `jpeg_destroy` doesn't change the `err` field that contains the application-provided error manager. - Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1463#pullrequestreview-2083527655
Re: RFR: 8087444: CornerRadii with different horizontal and vertical values treated as uniform
On Tue, 28 May 2024 16:15:25 GMT, Michael Strauß wrote:
> This PR fixes the incorrect computation of the `CornerRadii.uniform` flag for
> the 16-argument constructor.
>
> I've also added tests for all other constructors.
the change looks good. thank you for adding a comprehensive test!
modules/javafx.graphics/src/test/java/test/javafx/scene/layout/CornerRadiiTest.java
line 65:
> 63:
> 64: @Nested
> 65: class IsUniformTests {
just curious - what was the rationale for `@Nested` here, as the number of the
test cases is fairly small.
-
Marked as reviewed by angorya (Reviewer).
PR Review: https://git.openjdk.org/jfx/pull/1465#pullrequestreview-2083526426
PR Review Comment: https://git.openjdk.org/jfx/pull/1465#discussion_r1617694868
Re: RFR: 8087444: CornerRadii with different horizontal and vertical values treated as uniform
On Tue, 28 May 2024 17:55:24 GMT, Andy Goryachev wrote:
>> This PR fixes the incorrect computation of the `CornerRadii.uniform` flag
>> for the 16-argument constructor.
>>
>> I've also added tests for all other constructors.
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/CornerRadiiTest.java
> line 65:
>
>> 63:
>> 64: @Nested
>> 65: class IsUniformTests {
>
> just curious - what was the rationale for `@Nested` here, as the number of
> the test cases is fairly small.
I will add some more tests with
[JDK-8332895](https://bugs.openjdk.org/browse/JDK-8332895) (adding
interpolation support), and the `@Nested` nicely groups all tests for a given
functionality.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1465#discussion_r1617700166
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 11:25:51 GMT, Michael Strauß wrote: >> True, but I think it's a lot easier to follow than the logic before it. I >> see it a bit more as a hint to future maintainers (which might be me) that >> there are assumptions being made here that code relies on. > > I understand that, my objection is only with the `assert` keyword. I don't > like test code in production code (which this is, it verifies that an > assumption holds). I think only unit tests should contain test code, but it's > a minor issue and I'll reapprove as-is. I think (and please correct me if I am wrong) that by default java assertions are disabled. They are only enabled for the tests, see build.gradle :2106 :2628 - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617767401
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into feature/selector-performance-improvement > - Merge remote-tracking branch 'upstream/master' into > feature/selector-performance-improvement > - Added 100% coverage test for FixedCapacitySet > - Move getStyleClassNames to location it was introduced to reduce diff > - Remove deprecations > - Add @Deprecated tag > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides > - Optimize performance of OpenAddressed Set just in case it is ever used > - Fix docs > - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab Marked as reviewed by angorya (Reviewer). - PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2083661160
JavaFX applications fail to build with Maven 3.9.7
JavaFX applications fail to build with Maven 3.9.7, which was released on May 25. The Maven developers identified the JavaFX parent POM file as the source of the problem: Maven Central: org.openjfx:javafx:22.0.1 https://central.sonatype.com/artifact/org.openjfx/javafx/22.0.1 To see the errors, download the file and validate it with Maven as follows: $ curl -O https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom $ mvn -f javafx-22.0.1.pom validate [INFO] Scanning for projects... [ERROR] [ERROR] Some problems were encountered while processing the POMs: [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id linux-x86_64 @ line 36, column 17 [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id linux-aarch64 @ line 68, column 17 [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id macosx-x86_64 @ line 116, column 17 [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id macosx-aarch64 @ line 148, column 17 [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id windows-x86_64 @ line 180, column 17 [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id windows-x86 @ line 212, column 17 For details, please see: Maven 3.9.7 fails to activate profile? https://lists.apache.org/thread/qcbgby00xl27ljdv5yqp0gf1sbvwnq71 There's also already a bug report against Maven, although it seems the problem may be only on the JavaFX side: Maven MNG-8131 - Property replacement in dependency pom no longer works https://issues.apache.org/jira/browse/MNG-8131 I'm willing to look into this, but it might need someone who can work more quickly, since any JavaFX developer who upgrades to the latest Maven will hit this. (I don't yet know even where this POM file is created.) Let me know either way. Thanks, John
Re: RFR: 8087444: CornerRadii with different horizontal and vertical values treated as uniform
On Tue, 28 May 2024 16:15:25 GMT, Michael Strauß wrote: > This PR fixes the incorrect computation of the `CornerRadii.uniform` flag for > the 16-argument constructor. > > I've also added tests for all other constructors. LGTM modules/javafx.graphics/src/main/java/javafx/scene/layout/CornerRadii.java line 315: > 313: bottomRightHorizontalRadiusAsPercent || > bottomRightVerticalRadiusAsPercent || > 314: bottomLeftVerticalRadiusAsPercent || > bottomLeftHorizontalRadiusAsPercent; > 315: uniform = topLeftHorizontalRadius == topLeftVerticalRadius && I found the diff a bit troubling to read, but from what I gather, all the radii need to be equal to qualify for uniformity, and what you did here is add a `topLeftHorizontalRadius == topLeftVerticalRadius` (and percent version) to this check. You also already improved the readability by using `topLeftHorizontalRadius` everywhere. It might be even better to extract this one to a new variable, so it is even more clear that you're comparing all the other radii with the same value. - Marked as reviewed by jhendrikx (Committer). PR Review: https://git.openjdk.org/jfx/pull/1465#pullrequestreview-2083861912 PR Review Comment: https://git.openjdk.org/jfx/pull/1465#discussion_r161792
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into feature/selector-performance-improvement > - Merge remote-tracking branch 'upstream/master' into > feature/selector-performance-improvement > - Added 100% coverage test for FixedCapacitySet > - Move getStyleClassNames to location it was introduced to reduce diff > - Remove deprecations > - Add @Deprecated tag > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides > - Optimize performance of OpenAddressed Set just in case it is ever used > - Fix docs > - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab Marked as reviewed by mhanl (Committer). - PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2083884799
Re: RFR: 8322964: Optimize performance of CSS selector matching [v10]
On Tue, 28 May 2024 04:35:34 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Added 100% coverage test for FixedCapacitySet modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/FixedCapacitySetTest.java line 1: > 1: package test.com.sun.javafx.css; The Copyright is missing from this class and the `if` and `for` clauses have no space after. I think we usually do that, still minor of course. Tests are looking good to me! - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617913493
Re: RFR: 8087444: CornerRadii with different horizontal and vertical values treated as uniform
On Tue, 28 May 2024 21:15:47 GMT, John Hendrikx wrote: >> This PR fixes the incorrect computation of the `CornerRadii.uniform` flag >> for the 16-argument constructor. >> >> I've also added tests for all other constructors. > > modules/javafx.graphics/src/main/java/javafx/scene/layout/CornerRadii.java > line 315: > >> 313: bottomRightHorizontalRadiusAsPercent || >> bottomRightVerticalRadiusAsPercent || >> 314: bottomLeftVerticalRadiusAsPercent || >> bottomLeftHorizontalRadiusAsPercent; >> 315: uniform = topLeftHorizontalRadius == topLeftVerticalRadius && > > I found the diff a bit troubling to read, but from what I gather, all the > radii need to be equal to qualify for uniformity, and what you did here is > add a `topLeftHorizontalRadius == topLeftVerticalRadius` (and percent > version) to this check. > > You also already improved the readability by using `topLeftHorizontalRadius` > everywhere. It might be even better to extract this one to a new variable, > so it is even more clear that you're comparing all the other radii with the > same value. I tried that, but in my eyes it didn't clearly improve readability beyond the current version. - PR Review Comment: https://git.openjdk.org/jfx/pull/1465#discussion_r1617913798
Re: CFV: New OpenJFX Reviewer: John Hendrikx
Vote: YES Jose On Mon, May 27, 2024 at 7:20 AM Ajit Ghaisas wrote: > Vote: YES > > Regards, > Ajit > > > On 23-May-2024, at 4:54 AM, Kevin Rushforth > wrote: > > > > I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. > > > > John is an OpenJFX community member, who has contributed 39 commits [2] > to OpenJFX. John regularly participates in code reviews, especially in the > areas of JavaFX properties, scene graph and UI controls, offering valuable > feedback. > > > > Votes are due by June 5, 2024 at 23:59 UTC. > > > > Only current OpenJFX Reviewers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. Nomination to a > project Reviewer is described in [5]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.org/census#jhendrikx > > > > [2] > https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%22&type=commits > > > > [3] https://openjdk.java.net/census#openjfx > > > > [4] https://openjdk.java.net/bylaws#three-vote-consensus > > > > [5] https://openjdk.java.net/projects#project-reviewer > > > > --
Re: RFR: 8322964: Optimize performance of CSS selector matching [v13]
> Improves performance of selector matching in the CSS subsystem. This is done > by using custom set implementation which are highly optimized for the most > common cases where the number of selectors is small (most commonly 1 or 2). > It also should be more memory efficient for medium sized and large > applications which have many style names defined in various CSS files. > > Due to the optimization, the concept of `StyleClass`, which was only > introduced to assign a fixed bit index for each unique style class name > encountered, is no longer needed. This is because style classes are no longer > stored in a `BitSet` which required a fixed index per encountered style class. > > The performance improvements are the result of several factors: > - Less memory use when only very few style class names are used in selectors > and styles from a large pool of potential styles (a `BitSet` for potentially > 1000 different style names needed 1000 bits (worst case) as it was not > sparse). > - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) > - Specialized sets are append only (reduces code paths) and can be made read > only without requiring a wrapper > - Iterator creation is avoided when doing `containsAll` check thanks to the > inverse function `isSuperSetOf` > - Avoids making a copy of the list of style class names to compare (to > convert them to `StyleClass` and put them into a `Set`) -- this copy could > not be cached and was always discarded immediately after... > > The overall performance was tested using the JFXCentral application which > displays about 800 nodes on its start page with about 1000 styles in various > style sheets (and which allows to refresh this page easily). > > On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the > improvements in this PR, the fastest refresh had become 89 ms. The speed > improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up > the bulk of the time to refresh the JFXCentral main page (about 100 ms before > vs 70 ms after the change). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add copyright header - Changes: - all: https://git.openjdk.org/jfx/pull/1316/files - new: https://git.openjdk.org/jfx/pull/1316/files/d72aefab..cda93e50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1316&range=11-12 Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1316.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1316/head:pull/1316 PR: https://git.openjdk.org/jfx/pull/1316
Re: RFR: 8322964: Optimize performance of CSS selector matching [v10]
On Tue, 28 May 2024 21:37:43 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/FixedCapacitySetTest.java >> line 1: >> >>> 1: package test.com.sun.javafx.css; >> >> The Copyright is missing from this class and the `if` and `for` clauses have >> no space after. >> I think we usually do that, still minor of course. Tests are looking good to >> me! > > oops I missed that! I think we must include the standard copyright header > per OCA agreement. I always forget the header, thanks, I added it! - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617920591
Re: RFR: 8322964: Optimize performance of CSS selector matching [v10]
On Tue, 28 May 2024 21:31:53 GMT, Marius Hanl wrote: >> John Hendrikx has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added 100% coverage test for FixedCapacitySet > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/FixedCapacitySetTest.java > line 1: > >> 1: package test.com.sun.javafx.css; > > The Copyright is missing from this class and the `if` and `for` clauses have > no space after. > I think we usually do that, still minor of course. Tests are looking good to > me! oops I missed that! I think we must include the standard copyright header per OCA agreement. - PR Review Comment: https://git.openjdk.org/jfx/pull/1316#discussion_r1617917861
Re: RFR: 8322964: Optimize performance of CSS selector matching [v12]
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'openjdk:master' into feature/selector-performance-improvement > - Merge remote-tracking branch 'upstream/master' into > feature/selector-performance-improvement > - Added 100% coverage test for FixedCapacitySet > - Move getStyleClassNames to location it was introduced to reduce diff > - Remove deprecations > - Add @Deprecated tag > - Remove commented code in BitSetTest > - Remove unnecessary addAll overrides > - Optimize performance of OpenAddressed Set just in case it is ever used > - Fix docs > - ... and 11 more: https://git.openjdk.org/jfx/compare/31fe622c...d72aefab please add copyright header - Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2083892047
Re: RFR: 8322964: Optimize performance of CSS selector matching [v13]
On Tue, 28 May 2024 21:41:25 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Add copyright header thank you! sorry, I missed that earlier. - Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2083896658
Re: RFR: 8322964: Optimize performance of CSS selector matching [v13]
On Tue, 28 May 2024 21:44:36 GMT, John Hendrikx wrote: >> Improves performance of selector matching in the CSS subsystem. This is done >> by using custom set implementation which are highly optimized for the most >> common cases where the number of selectors is small (most commonly 1 or 2). >> It also should be more memory efficient for medium sized and large >> applications which have many style names defined in various CSS files. >> >> Due to the optimization, the concept of `StyleClass`, which was only >> introduced to assign a fixed bit index for each unique style class name >> encountered, is no longer needed. This is because style classes are no >> longer stored in a `BitSet` which required a fixed index per encountered >> style class. >> >> The performance improvements are the result of several factors: >> - Less memory use when only very few style class names are used in selectors >> and styles from a large pool of potential styles (a `BitSet` for potentially >> 1000 different style names needed 1000 bits (worst case) as it was not >> sparse). >> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+) >> - Specialized sets are append only (reduces code paths) and can be made read >> only without requiring a wrapper >> - Iterator creation is avoided when doing `containsAll` check thanks to the >> inverse function `isSuperSetOf` >> - Avoids making a copy of the list of style class names to compare (to >> convert them to `StyleClass` and put them into a `Set`) -- this copy could >> not be cached and was always discarded immediately after... >> >> The overall performance was tested using the JFXCentral application which >> displays about 800 nodes on its start page with about 1000 styles in various >> style sheets (and which allows to refresh this page easily). >> >> On JavaFX 20, the fastest refresh speed was 121 ms on my machine. With the >> improvements in this PR, the fastest refresh had become 89 ms. The speed >> improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up >> the bulk of the time to refresh the JFXCentral main page (about 100 ms >> before vs 70 ms after the change). > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Add copyright header Marked as reviewed by mstrauss (Committer). - PR Review: https://git.openjdk.org/jfx/pull/1316#pullrequestreview-2083924662
Re: RFR: 8311895: CSS Transitions [v21]
> Implementation of [CSS
> Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a).
>
> ### Future enhancements
> CSS transitions requires all participating objects to implement the
> `Interpolatable` interface. For example, targeting `-fx-background-color`
> only works if all background-related objects are interpolatable: `Color`,
> `BackgroundFill`, and `Background`.
>
> In a follow-up PR, the following types will implement the `Interpolatable`
> interface:
> `LinearGradient`, `RadialGradient`, `Stop`, `Background`, `BackgroundFill`,
> `BackgroundImage`, `BackgroundPosition`, `BackgroundSize`,
> `BackgroundStroke`, `BorderWidths`, `CornerRadii`, `Insets`.
>
> ### 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:
document css parser limitation
-
Changes:
- all: https://git.openjdk.org/jfx/pull/870/files
- new: https://git.openjdk.org/jfx/pull/870/files/f64ad706..8a938dc8
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=20
- incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=19-20
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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
Re: JavaFX applications fail to build with Maven 3.9.7
It looks as if this issue was reported in 2021, 2022, and 2023. The difference now is that, as of Maven 3.9.7, the failure occurs immediately when it tries to download the JavaFX dependencies. 2021-12-27 JDK-8279380: Duplicate profile id in JavaFX maven POM https://bugs.openjdk.org/browse/JDK-8279380 2022-12-22 JDK-8299352: Duplicate profile id in JavaFX maven POM https://bugs.openjdk.org/browse/JDK-8299352 2023-03-24 JDK-8305167: Duplicate profile ids in generated javafx-19.0.2.1.pom https://bugs.openjdk.org/browse/JDK-8305167 Those three bugs were closed as duplicates of the following: 2021-12-23 JDK-8279327: Maven Assembly Plugin Issues Warnings for JavaFx 17 Onwards https://bugs.openjdk.org/browse/JDK-8279327 Comments in that bug report suggest reporting the issue to the JavaFX Maven Plugin project, but I'm getting the error, and I don't use that plugin. I also don't use the Maven Assembly Plugin. The Maven developers tell me the error is in the JavaFX parent POM file itself. Is that published by Gluon? So far I've been unable to produce the Maven artifacts using tasks in the JavaFX Gradle build file. Thanks, John
RFR: 8332748: Grammatical errors in animation API docs
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. - Commit messages: - Fix gramatical errors in Transition javadoc comments Changes: https://git.openjdk.org/jfx/pull/1466/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1466&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8332748 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1466.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1466/head:pull/1466 PR: https://git.openjdk.org/jfx/pull/1466
