From hmeda at openjdk.java.net Fri Apr 1 07:41:11 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 07:41:11 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 Message-ID: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. The steps to update libxml are documented in UPDATING.txt. There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. Updated the code with the changes as per the fix mentioned in above link. Compiled and verified on Windows, Mac and Linux platforms. Sanity testing looks fine. ------------- Commit messages: - Remove whitespace - Restore COPYING - Update formatting - Formatting changes - Windows : libxml update to 2.9.13 - Update libxml to 2.9.13 for linux - Update libxml version to 2.9.13 Changes: https://git.openjdk.java.net/jfx/pull/764/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=764&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55633 lines in 103 files changed: 5734 ins; 24999 del; 24900 mod Patch: https://git.openjdk.java.net/jfx/pull/764.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/764/head:pull/764 PR: https://git.openjdk.java.net/jfx/pull/764 From kcr at openjdk.java.net Fri Apr 1 07:41:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 1 Apr 2022 07:41:11 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 In-Reply-To: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Thu, 31 Mar 2022 14:47:32 GMT, Hima Bindu Meda wrote: > We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. > The steps to update libxml are documented in UPDATING.txt. > There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. > Updated the code with the changes as per the fix mentioned in above link. > > Compiled and verified on Windows, Mac and Linux platforms. > Sanity testing looks fine. I'll do testing and a sanity check review tomorrow. Here are three meta issues: 1. As noted in [SKARA-1222](https://bugs.openjdk.java.net/browse/SKARA-1222), your patch introduces a sym-link that is causing jcheck to throw an exception. Given that we do not want any sym-links in the repo anyway, you will need to revert the file in question. 2. Once the above is fixed, you will note that jcheck reports some whitespace errors. 3. You need to update the version in [libxml2.md](https://github.com/openjdk/jfx/blob/f169dde501c58fe107ab6da7f35667efb4992b65/modules/javafx.web/src/main/legal/libxml2.md). 4. I see that the following files were deleted as part of this PR. Was this intentional? D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/AUTHORS D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/README ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From hmeda at openjdk.java.net Fri Apr 1 08:19:28 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 08:19:28 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: > We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. > The steps to update libxml are documented in UPDATING.txt. > There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. > Updated the code with the changes as per the fix mentioned in above link. > > Compiled and verified on Windows, Mac and Linux platforms. > Sanity testing looks fine. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Add README.md and update libxml2.md ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/764/files - new: https://git.openjdk.java.net/jfx/pull/764/files/8dca3c2e..92ba9af0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=764&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=764&range=00-01 Stats: 28 lines in 2 files changed: 27 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/764.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/764/head:pull/764 PR: https://git.openjdk.java.net/jfx/pull/764 From jvos at openjdk.java.net Fri Apr 1 08:26:48 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 1 Apr 2022 08:26:48 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: <8QbQ9ocUluDGYMs-Xl5uMlYD7EiEtXNwwfR9SxF4k4U=.d522ce16-86f5-4d2b-a04d-e20c94f8a5bd@github.com> On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add README.md and update libxml2.md This looks good. Just for my understanding: this is the 2.9.13-tagged plus the fix for the issue with xmlValidNormalizeString() with --without-valid-build (https://gitlab.gnome.org/GNOME/libxml2/-/commit/d05317cee5eb2bd35269b7706a8850c6c3097de3) ? I notice there was a followup patch (https://gitlab.gnome.org/GNOME/libxml2/-/commit/b057239b3f65c8dd9d472fc878214ea4b1d852d3) but that doesn't touch files we have, and since builds are compiling for me, it seems that we are all good now. ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From hmeda at openjdk.java.net Fri Apr 1 08:26:50 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 08:26:50 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Thu, 31 Mar 2022 20:11:51 GMT, Kevin Rushforth wrote: > 1. As noted in [SKARA-1222](https://bugs.openjdk.java.net/browse/SKARA-1222), your patch introduces a sym-link that is causing jcheck to throw an exception. Given that we do not want any sym-links in the repo anyway, you will need to revert the file in question. --- Fixed symlinks issue by reverting the file > 2. Once the above is fixed, you will note that jcheck reports some whitespace errors. -- Resolved > 3. You need to update the version in [libxml2.md](https://github.com/openjdk/jfx/blob/f169dde501c58fe107ab6da7f35667efb4992b65/modules/javafx.web/src/main/legal/libxml2.md). -- Updated ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From hmeda at openjdk.java.net Fri Apr 1 08:32:47 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 08:32:47 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: <8QbQ9ocUluDGYMs-Xl5uMlYD7EiEtXNwwfR9SxF4k4U=.d522ce16-86f5-4d2b-a04d-e20c94f8a5bd@github.com> References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> <8QbQ9ocUluDGYMs-Xl5uMlYD7EiEtXNwwfR9SxF4k4U=.d522ce16-86f5-4d2b-a04d-e20c94f8a5bd@github.com> Message-ID: On Fri, 1 Apr 2022 08:22:22 GMT, Johan Vos wrote: > This looks good. Just for my understanding: this is the 2.9.13-tagged plus the fix for the issue with xmlValidNormalizeString() with --without-valid-build (https://gitlab.gnome.org/GNOME/libxml2/-/commit/d05317cee5eb2bd35269b7706a8850c6c3097de3) ? -- Yes, just this patch is sufficient to resolve compilation error. > I notice there was a followup patch (https://gitlab.gnome.org/GNOME/libxml2/-/commit/b057239b3f65c8dd9d472fc878214ea4b1d852d3) but that doesn't touch files we have, and since builds are compiling for me, it seems that we are all good now. -- Yes , the followup patch is not needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From jvos at openjdk.java.net Fri Apr 1 09:43:46 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 1 Apr 2022 09:43:46 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add README.md and update libxml2.md Looks good and works fine on Mac/Linux/Windows ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/764 From hmeda at openjdk.java.net Fri Apr 1 09:52:48 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 09:52:48 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add README.md and update libxml2.md > 7. I see that the following files were deleted as part of this PR. Was this intentional? > > ``` > D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/AUTHORS > D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/ChangeLog > D modules/javafx.web/src/main/native/Source/ThirdParty/libxml/src/README > ``` -- The above files have been deleted in the release v2.9.13. Added README.md which contains information regarding Authors,License and libxml project ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From kcr at openjdk.java.net Fri Apr 1 15:21:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 1 Apr 2022 15:21:48 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add README.md and update libxml2.md Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/764 From arapte at openjdk.java.net Fri Apr 1 16:54:44 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 1 Apr 2022 16:54:44 GMT Subject: RFR: 8283328: Update libxml2 to 2.9.13 [v2] In-Reply-To: References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: On Fri, 1 Apr 2022 08:19:28 GMT, Hima Bindu Meda wrote: >> We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. >> The steps to update libxml are documented in UPDATING.txt. >> There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. >> Updated the code with the changes as per the fix mentioned in above link. >> >> Compiled and verified on Windows, Mac and Linux platforms. >> Sanity testing looks fine. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Add README.md and update libxml2.md Looks good, tested Mac M1 build and macos sanity check. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/764 From hmeda at openjdk.java.net Fri Apr 1 17:01:47 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 1 Apr 2022 17:01:47 GMT Subject: Integrated: 8283328: Update libxml2 to 2.9.13 In-Reply-To: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> References: <-_aq2n7LNp_SaVA-bBg841uuHnFuAALkR7YZGqyTujE=.b1e82f5e-c250-453d-ae74-acd40bdcc728@github.com> Message-ID: <4RYqOAcSou4VnHitStuAJsawJH902-iUZEpLatP7UrQ=.a5b46673-813e-4be1-9c3e-3c451d036ab6@github.com> On Thu, 31 Mar 2022 14:47:32 GMT, Hima Bindu Meda wrote: > We currently use libxml2 version 2.9.12. It should be updated to latest stable release, which is version 2.9.13. > The steps to update libxml are documented in UPDATING.txt. > There is compilation issue with the release 2.9.13, as mentioned here: https://gitlab.gnome.org/GNOME/libxml2/-/issues/349. > Updated the code with the changes as per the fix mentioned in above link. > > Compiled and verified on Windows, Mac and Linux platforms. > Sanity testing looks fine. This pull request has now been integrated. Changeset: b0f25212 Author: Hima Bindu Meda Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/b0f2521219efc1b0d0c45088736d5105712bc2c9 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Reviewed-by: jvos, kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/764 From jbhaskar at openjdk.java.net Sat Apr 2 08:35:58 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sat, 2 Apr 2022 08:35:58 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Message-ID: Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); Solution: traverse widths to calculate end point and increment start point. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' - 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com Changes: https://git.openjdk.java.net/jfx/pull/765/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284184 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/765.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/765/head:pull/765 PR: https://git.openjdk.java.net/jfx/pull/765 From duke at openjdk.java.net Sat Apr 2 10:23:23 2022 From: duke at openjdk.java.net (Paul) Date: Sat, 2 Apr 2022 10:23:23 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display [v2] In-Reply-To: References: Message-ID: > I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. > > Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. > > Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- > > > if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { > NSSize imgSize = {width / sx, height / sy}; > [image setSize: imgSize]; > } > > > The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. > > Before this fix:- > > Screenshot 2022-02-26 at 22 16 30 > > After this fix:- > > Screenshot 2022-02-26 at 22 18 17 Paul has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8181084 - Removing trailing whitespace. - Correctly scales hi-res icons in MacOS system menu items ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/743/files - new: https://git.openjdk.java.net/jfx/pull/743/files/9162aa44..3057f683 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=00-01 Stats: 63592 lines in 202 files changed: 10562 ins; 25364 del; 27666 mod Patch: https://git.openjdk.java.net/jfx/pull/743.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743 PR: https://git.openjdk.java.net/jfx/pull/743 From kcr at openjdk.java.net Sat Apr 2 13:58:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 2 Apr 2022 13:58:44 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 08:29:43 GMT, Jay Bhaskar wrote: > Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); > Solution: traverse widths to calculate end point and increment start point. I'll take a closer look at this next week. I see that you are reverting back to looping over the `widths` array, which will give a different visual result than the current code for dashed lines (of course, the current code, which was changed in [JDK-8280020](https://bugs.openjdk.java.net/browse/JDK-8280020), could be giving the wrong visual result in addition to causing the arithmetic overflow). Can you explain what the `widths` array represents? I also don't immediately see how this avoids the overflow, but that's another thing I'll look at. ------------- PR: https://git.openjdk.java.net/jfx/pull/765 From jbhaskar at openjdk.java.net Sat Apr 2 14:27:47 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Sat, 2 Apr 2022 14:27:47 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 08:29:43 GMT, Jay Bhaskar wrote: > Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); > Solution: traverse widths to calculate end point and increment start point. The TextDecorationPainter class is responsible to call GraphicsContextJava::drawLinesForText. Before that GraphicsContextJava::drawLinesForText the TextDecorationPainter class compute the rect based on the text decoration style, text origin. Before calling GraphicsContextJava::drawLinesForText, The TextDecorationPainter class creates arrays of intersection points from rect. // using DashArray = Vector; DashArray boundaries = translateIntersectionPointsToSkipInkBoundaries(intersections, underlineBoundingBox.height(), rect.width()); m_context.drawLinesForText(rect.location(), rect.height(), boundaries, m_isPrinting, style == TextDecorationStyle::Double, strokeStyle); So following code as fix for (const auto& width : widths) { FloatPoint endPoint = startPoint + FloatPoint(width, 0); drawLine( IntPoint(startPoint.x(), startPoint.y()), IntPoint(endPoint.x(), endPoint.y())); startPoint = endPoint; } avoid arithmetic overflow as in previous fix we were calculating end point FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); I have tested all style of line drawing , continuous , dashes , overflow and underline , it is working well with the recent fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/765 From kcr at openjdk.java.net Sat Apr 2 17:38:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 2 Apr 2022 17:38:59 GMT Subject: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Message-ID: This patch updates the compiler to Visual Studio 2022 version 17.1.0 on Windows, in order to match JDK 19 -- see [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). I ran a full build and test, including media and WebKit. ------------- Commit messages: - 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Changes: https://git.openjdk.java.net/jfx/pull/766/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=766&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283786 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/766.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/766/head:pull/766 PR: https://git.openjdk.java.net/jfx/pull/766 From mstrauss at openjdk.java.net Sun Apr 3 15:14:42 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 3 Apr 2022 15:14:42 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v8] In-Reply-To: References: Message-ID: > This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: - Update copyright headers - Merge branch 'master' into feature/focusvisible - fixed undeterministic test failures - minor wording change - restart github actions - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible - changes per discussion, added test - wording - Re-ordered methods - remove code comment - ... and 11 more: https://git.openjdk.java.net/jfx/compare/129c1ffa...bd57bbac ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/475/files - new: https://git.openjdk.java.net/jfx/pull/475/files/d9a715e3..bd57bbac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=475&range=06-07 Stats: 473015 lines in 7841 files changed: 268935 ins; 144862 del; 59218 mod Patch: https://git.openjdk.java.net/jfx/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/475/head:pull/475 PR: https://git.openjdk.java.net/jfx/pull/475 From sykora at openjdk.java.net Mon Apr 4 11:17:35 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Mon, 4 Apr 2022 11:17:35 GMT Subject: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on Windows, in order to match JDK 19 -- see [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. @kevinrushforth Which versions were chosen for the build tools, redistributables and the CRT? Do we still use the same ones as with Visual Studio 2019? ------------- PR: https://git.openjdk.java.net/jfx/pull/766 From jpereda at openjdk.java.net Mon Apr 4 11:49:37 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 4 Apr 2022 11:49:37 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: On Tue, 15 Mar 2022 18:57:50 GMT, Kevin Rushforth wrote: >> This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). >> >> When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. >> >> This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. >> >> This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. >> >> Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. >> >> In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. > > The GHA test failure on macOS was due to [JDK-8282449](https://bugs.openjdk.java.net/browse/JDK-8282449) and not anything in this PR. I filed a new bug to skip the failing tests until that bug can be fixed. See PR #754. @kevinrushforth Thanks for the test fix. Do I need to add a change in order to pass the tests again? ------------- PR: https://git.openjdk.java.net/jfx/pull/753 From kcr at openjdk.java.net Mon Apr 4 13:34:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 4 Apr 2022 13:34:34 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: <4XrXgBlDNgpZdd5lru9XqwgdTcTfRshP5BrkLh1rxDY=.57ce2312-5776-4437-bfc4-38a9227a913d@github.com> On Mon, 14 Mar 2022 14:49:41 GMT, Jose Pereda wrote: > This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). > > When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. > > This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. > > This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. > > Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. > > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. You would need to merge the latest master to pick up that fix, which will also trigger another GHA run. ------------- PR: https://git.openjdk.java.net/jfx/pull/753 From jpereda at openjdk.java.net Mon Apr 4 17:29:28 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 4 Apr 2022 17:29:28 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem [v2] In-Reply-To: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: > This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). > > When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. > > This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. > > This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. > > Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. > > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8193442-treeitemselection - Don't shift selection/focus if item is below removed element ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/753/files - new: https://git.openjdk.java.net/jfx/pull/753/files/ba820e59..d514e28a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=753&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=753&range=00-01 Stats: 59179 lines in 147 files changed: 8783 ins; 25281 del; 25115 mod Patch: https://git.openjdk.java.net/jfx/pull/753.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/753/head:pull/753 PR: https://git.openjdk.java.net/jfx/pull/753 From jpereda at openjdk.java.net Mon Apr 4 17:50:53 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 4 Apr 2022 17:50:53 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: <4XrXgBlDNgpZdd5lru9XqwgdTcTfRshP5BrkLh1rxDY=.57ce2312-5776-4437-bfc4-38a9227a913d@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> <4XrXgBlDNgpZdd5lru9XqwgdTcTfRshP5BrkLh1rxDY=.57ce2312-5776-4437-bfc4-38a9227a913d@github.com> Message-ID: On Mon, 4 Apr 2022 13:31:52 GMT, Kevin Rushforth wrote: >> This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). >> >> When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. >> >> This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. >> >> This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. >> >> Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. >> >> In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. > > You would need to merge the latest master to pick up that fix, which will also trigger another GHA run. @kevinrushforth Thanks, that worked and the tests pass (as it was expected). ------------- PR: https://git.openjdk.java.net/jfx/pull/753 From arapte at openjdk.java.net Tue Apr 5 05:01:03 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 5 Apr 2022 05:01:03 GMT Subject: RFR: 8281564: Update cmake to 3.22.3 Message-ID: Update cmake to 3.22.3 Verified build on all three platforms. The sanity test looks good. ------------- Commit messages: - cmake-update Changes: https://git.openjdk.java.net/jfx/pull/767/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=767&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281564 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/767.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/767/head:pull/767 PR: https://git.openjdk.java.net/jfx/pull/767 From aghaisas at openjdk.java.net Tue Apr 5 12:13:51 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 5 Apr 2022 12:13:51 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling [v4] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:22:23 GMT, Robert Lichtenberger wrote: >> This fix respects a row factory, if present. >> It will put the cell that is used to measure the column width as child below the row. >> In that way the row's style will be used. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8251480: TableColumnHeader: calc of cell width must respect row styling > > Assertion removed. Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/757 From rlichten at openjdk.java.net Tue Apr 5 13:16:48 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 5 Apr 2022 13:16:48 GMT Subject: Integrated: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 08:20:59 GMT, Robert Lichtenberger wrote: > This fix respects a row factory, if present. > It will put the cell that is used to measure the column width as child below the row. > In that way the row's style will be used. This pull request has now been integrated. Changeset: 18b9e941 Author: Robert Lichtenberger Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/18b9e94131dea0569d0df14ec96aa368a40fcbd0 Stats: 98 lines in 2 files changed: 93 ins; 1 del; 4 mod 8251480: TableColumnHeader: calc of cell width must respect row styling Reviewed-by: mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From kcr at openjdk.java.net Tue Apr 5 15:26:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Apr 2022 15:26:45 GMT Subject: RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 04:54:55 GMT, Ambarish Rapte wrote: > Update cmake to 3.22.3 > Verified build on all three platforms. > The sanity test looks good. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/767 From kcr at openjdk.java.net Tue Apr 5 16:11:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 5 Apr 2022 16:11:43 GMT Subject: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 11:14:27 GMT, Joeri Sykora wrote: > Which versions were chosen for the build tools, redistributables and the CRT? Do we still use the same ones as with Visual Studio 2019? Each version of Visual Studio has its own set of compilers and redistributables. Visual Studio 2022 version 17.1.0 corresponds to VC version `14.31.31103`. The redistributables should be in `redist/x64/Microsoft.VC143.CRT`. ------------- PR: https://git.openjdk.java.net/jfx/pull/766 From jvos at openjdk.java.net Tue Apr 5 20:10:43 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 5 Apr 2022 20:10:43 GMT Subject: RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: <8_JXBDrQtAqMKV1Gj5Ci6a0UQ08QIecono1SF5BvksE=.fd061f0d-eb88-4540-8c71-3cc067a9a1b5@github.com> On Tue, 5 Apr 2022 04:54:55 GMT, Ambarish Rapte wrote: > Update cmake to 3.22.3 > Verified build on all three platforms. > The sanity test looks good. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/767 From arapte at openjdk.java.net Wed Apr 6 02:03:37 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Apr 2022 02:03:37 GMT Subject: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: <6m9B5X7SG7NmNUXA7ZXFHLlmX8fXy_haE_XAN40dhIo=.fb88598e-3267-479b-a173-a437a1e94311@github.com> On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on Windows, in order to match JDK 19 -- see [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. lgtm. Verified build and sanity test. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/766 From arapte at openjdk.java.net Wed Apr 6 04:46:38 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 6 Apr 2022 04:46:38 GMT Subject: Integrated: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Tue, 5 Apr 2022 04:54:55 GMT, Ambarish Rapte wrote: > Update cmake to 3.22.3 > Verified build on all three platforms. > The sanity test looks good. This pull request has now been integrated. Changeset: d960d639 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/d960d639dc6e37de0cdb69075a31a17090b83a3d Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod 8281564: Update cmake to 3.22.3 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/767 From kcr at openjdk.java.net Wed Apr 6 15:45:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 15:45:43 GMT Subject: RFR: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was not considering that URI can have query parameters. Fixed by checking URI path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, since we do support URI without extensions as long as they provide correct mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype checks failed to determine stream type. All playlists of HLS based on spec should start with #EXTM3U. For some reason this particular stream has mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec it should be "audio/mpegurl". Thus check for signature was added in case if URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this bug report due to provided example uses separate audio stream via EXT-X-MEDIA tag and it is not supported. I filed separate issue for this. Looks good. Tested on Windows and Linux. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/750 From kcr at openjdk.java.net Wed Apr 6 15:50:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 15:50:57 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:48:53 GMT, John Hendrikx wrote: >> I added a test case for `SpinnerSkin` that checks the arrow positioning. >> >> While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. >> >> 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. >> >> 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. >> >> For point 2, here is the problem illustrated with actual widths on left and layout result on right: >> >> [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] >> [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] >> >> While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: >> >> [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] >> >> While I'm here I could fix this as well, and adjust the test case to match. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year This looks straight-forward enough that a single reviewer is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/748 From jhendrikx at openjdk.java.net Wed Apr 6 19:24:49 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 6 Apr 2022 19:24:49 GMT Subject: RFR: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly [v2] In-Reply-To: References: Message-ID: <7TYzQ10SH0chDxUH1rhVpbaGNvgOkhswJV7X-Kf4H6o=.73b6f6dc-ce35-4927-9b2f-46b64d153bb1@github.com> On Wed, 9 Mar 2022 07:48:53 GMT, John Hendrikx wrote: >> I added a test case for `SpinnerSkin` that checks the arrow positioning. >> >> While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. >> >> 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. >> >> 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. >> >> For point 2, here is the problem illustrated with actual widths on left and layout result on right: >> >> [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] >> [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] >> >> While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: >> >> [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] >> >> While I'm here I could fix this as well, and adjust the test case to match. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Hadn't noticed it was ready to be integrated. Here goes. ------------- PR: https://git.openjdk.java.net/jfx/pull/748 From jhendrikx at openjdk.java.net Wed Apr 6 20:02:53 2022 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 6 Apr 2022 20:02:53 GMT Subject: Integrated: 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly In-Reply-To: References: Message-ID: <6tquIzq7ZHpsRFDUTJ9HMz4QAbqrie0w0jNkWBKUc_o=.2ec2c371-c3fc-46f3-a7e1-e2b0c6895124@github.com> On Wed, 9 Mar 2022 07:37:31 GMT, John Hendrikx wrote: > I added a test case for `SpinnerSkin` that checks the arrow positioning. > > While adding the tests I discovered more problems with the positioning aside from the one mentioned in the JBS ticket. > > 1) Vertical split arrow placement also forgot to take the padding into account while placing the decrement arrow button -- I've taken the liberty to fix that problem as well in the same PR. > > 2) When arrows are placed next to each other either on the right or left, the arrow widths are not normalized to be the width of the widest arrow. All other placements will normalize either the width or height, except for these two. Specifically, when the arrows are **split** on the left and right they **are** normalized to the same width. > > For point 2, here is the problem illustrated with actual widths on left and layout result on right: > > [ <----- ] [ -> ] [ spinner ] --> [ <----- ] [ -> ] [ spinner ] > [ spinner ] [ <----- ] [ -> ] --> [ spinner ] [ <----- ] [ -> ] > > While for split horizontal it does normalize the width to that of the widest arrow, and so layout becomes: > > [ <----- ] [ spinner ] [ -> ] --> [ <----- ] [ spinner ] [ -> ] > > While I'm here I could fix this as well, and adjust the test case to match. This pull request has now been integrated. Changeset: ba4c9c68 Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ba4c9c688086857cbfe019c06e51b3d110cc84f7 Stats: 147 lines in 2 files changed: 144 ins; 0 del; 3 mod 8281723: Spinner with split horizontal arrows and a border places right arrow incorrectly Reviewed-by: mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/748 From kcr at openjdk.java.net Wed Apr 6 21:19:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 6 Apr 2022 21:19:56 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 08:29:43 GMT, Jay Bhaskar wrote: > Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); > Solution: traverse widths to calculate end point and increment start point. I instrumented the code, and discovered that in the failing case, the list of `widths` is empty. I see that other implementations of GraphicsContext have a check for this at the beginning of the method, and do an early return in that case. That seems a good idea regardless. So I recommend adding this around line 345: if (widths.size() == 0) return; That alone is sufficient to fix this bug. As for the change to loop over the widths array, I'm not sure about that part. I see code in some of the ports that treat the widths array as pairs of start / end values, but that doesn't match what I see in a simple strike-through test case where there is only a single width value. For the case of a simple underline (with or without dashing), the widths array is of length 2 with the first value being 0.0, which tends to support the definition used by the other ports. This will need more analysis. So I think the simplest (and safest) fix is to just add the check for size == 0, but leave the drawing part of the code unchanged, and file a follow-up bug to investigate. ------------- PR: https://git.openjdk.java.net/jfx/pull/765 From jbhaskar at openjdk.java.net Thu Apr 7 09:55:36 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 7 Apr 2022 09:55:36 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ [v2] In-Reply-To: References: Message-ID: > Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); > Solution: traverse widths to calculate end point and increment start point. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: check length of DashArray ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/765/files - new: https://git.openjdk.java.net/jfx/pull/765/files/feda90ec..5c503f5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=765&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=765&range=00-01 Stats: 10 lines in 1 file changed: 3 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/765.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/765/head:pull/765 PR: https://git.openjdk.java.net/jfx/pull/765 From aghaisas at openjdk.java.net Thu Apr 7 12:08:58 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 7 Apr 2022 12:08:58 GMT Subject: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v3] In-Reply-To: <90A5xjTv1oMbNGvVnxxfc3eBj1CnW8jpguVwwvlajeQ=.9b33c3a6-f34b-4af0-84ba-c3b7e9862b38@github.com> References: <90A5xjTv1oMbNGvVnxxfc3eBj1CnW8jpguVwwvlajeQ=.9b33c3a6-f34b-4af0-84ba-c3b7e9862b38@github.com> Message-ID: On Thu, 10 Feb 2022 10:16:36 GMT, Jose Pereda wrote: >> This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. >> >> It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8273339-changefrom > - Apply change only when cell selection is enabled > - Convert change from list of tablePosition to list of rows Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/710 From kcr at openjdk.java.net Thu Apr 7 12:15:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 7 Apr 2022 12:15:43 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ [v2] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 09:55:36 GMT, Jay Bhaskar wrote: >> Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); >> Solution: traverse widths to calculate end point and increment start point. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > check length of DashArray Looks good. I confirm that it fixes the crash. Can you file the follow-on bug to investigate our use of the `widths` list? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/765 From jbhaskar at openjdk.java.net Thu Apr 7 12:15:43 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 7 Apr 2022 12:15:43 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ [v2] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 09:55:36 GMT, Jay Bhaskar wrote: >> Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); >> Solution: traverse widths to calculate end point and increment start point. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > check length of DashArray Yes, i will file a new follow up bug ------------- PR: https://git.openjdk.java.net/jfx/pull/765 From arapte at openjdk.java.net Thu Apr 7 12:46:58 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 7 Apr 2022 12:46:58 GMT Subject: RFR: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ [v2] In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 09:55:36 GMT, Jay Bhaskar wrote: >> Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); >> Solution: traverse widths to calculate end point and increment start point. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > check length of DashArray Looks safe and minimal change. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/765 From jbhaskar at openjdk.java.net Thu Apr 7 12:53:43 2022 From: jbhaskar at openjdk.java.net (Jay Bhaskar) Date: Thu, 7 Apr 2022 12:53:43 GMT Subject: Integrated: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 08:29:43 GMT, Jay Bhaskar wrote: > Issue: Floating point overflow , when making end point for line drawing as FloatPoint endPoint = startPoint + FloatPoint(widths.last(), 0); > Solution: traverse widths to calculate end point and increment start point. This pull request has now been integrated. Changeset: 64da125f Author: Jay Bhaskar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/64da125f05f2a25038ce3370c8fe7c0baf0a354b Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/765 From jpereda at openjdk.java.net Thu Apr 7 12:56:43 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 7 Apr 2022 12:56:43 GMT Subject: Integrated: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 20:00:27 GMT, Jose Pereda wrote: > This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. > > It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. This pull request has now been integrated. Changeset: c55931f6 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/c55931f662ccbb4cdbb602a31d3d61231ebf79ca Stats: 148 lines in 5 files changed: 141 ins; 0 del; 7 mod 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/710 From almatvee at openjdk.java.net Fri Apr 8 06:57:07 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 8 Apr 2022 06:57:07 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 Message-ID: - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. - Tested on all platforms with all supported media streams. ------------- Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx/pull/768/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38793 lines in 410 files changed: 21828 ins; 6021 del; 10944 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768 From perini.davide at dpsoftware.org Sat Apr 9 17:38:56 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sat, 9 Apr 2022 19:38:56 +0200 Subject: How to change the default color used for selected elements? Message-ID: <6c4355f8-df38-e33a-7e92-066df5e7eeec@dpsoftware.org> Hi all, as title. How to change the default color used for selected elements? Is there a way to do it with CSS? Thank you! Davide From thiago.sayao at gmail.com Sun Apr 10 21:43:16 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 10 Apr 2022 18:43:16 -0300 Subject: Xlib backend Message-ID: Hi, I got simple samples running on the pure Xlib port of the Gtk backend. It still has gtk code, but mainly uses Xlib by now. Don't judge the code, I'm porting it gradually. https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib java @build/run.args -cp apps/toys/Hello/dist/Hello.jar hello.HelloCursors Window coordinates and sizes are still off a bit, so you might have to resize the window to redraw. -- Thiago. From daniel.peintner at gmail.com Mon Apr 11 06:15:39 2022 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Mon, 11 Apr 2022 08:15:39 +0200 Subject: Application getParameters() not returning Umlaute properly Message-ID: All, I run into a *strange* behaviour. In my application I associate a file extension which works fine. Clicking on the desktop opens the app and loads the file I clicked on. This works fine for Windows and Mac on its own. Assume a file named "Kostenscha?tzung.avax" is stored on MacOS and gets opened afterwards on Windows it fails. The filename on Windows is shown correctly but after clicking on it on Windows the following call [javafx.application.Application].getParameters().getRaw() --> reports -> [C:\...\Kostenscha?tzung.avax] As you can see the character "?" becomes "a?". Note: loading of the file fails because this file does not exist. Choosing the file via FileChooser and storing it again on Windows solves the problem. Have any of you ever encountered such an issue? Thanks for any insight, -- Daniel From john.hendrikx at gmail.com Mon Apr 11 07:11:13 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 11 Apr 2022 09:11:13 +0200 Subject: Application getParameters() not returning Umlaute properly In-Reply-To: References: Message-ID: <480c9428-c1db-2101-719d-17007377f909@gmail.com> On 11/04/2022 08:15, Daniel Peintner wrote: > All, > > I run into a *strange* behaviour. > > In my application I associate a file extension which works fine. Clicking > on the desktop opens the app and loads the file I clicked on. > > This works fine for Windows and Mac on its own. > > Assume a file named "Kostenscha?tzung.avax" is stored on MacOS and gets > opened afterwards on Windows it fails. The filename on Windows is shown > correctly but after clicking on it on Windows the following call Where is this file stored? On a shared NAS? With SMB? > [javafx.application.Application].getParameters().getRaw() > > --> reports -> > > [C:\...\Kostenscha?tzung.avax] > > As you can see the character "?" becomes "a?". That second character is a special unicode character that should be combined with the previous character. > Note: loading of the file fails because this file does not exist. > > Choosing the file via FileChooser and storing it again on Windows solves > the problem. What happens here is that the filename when you save it with Windows gets stored differently, even though they look the same. The accented character is no longer stored as "a" + separate umlaut (0x61 0xcc88) but as a composed character (0xc3a4). Try this in Java to see the two different codes which result in the same character: System.out.println("\u00e4 vs a\u0308"); See also here: https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x For some reason, the parameters provided via the command line don't seem to properly decode the second form (a + composing umlaut) but do understand the first form (precomposed a-umlaut). This could be JavaFX, but could be lower level as well.? You could see what happens if you do this with a non-JavaFX program, and get the parameters directly from a `main` method. --John From kevin.rushforth at oracle.com Mon Apr 11 15:41:01 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Apr 2022 08:41:01 -0700 Subject: Xlib backend In-Reply-To: References: Message-ID: Can you say more about the motivation for doing this? Given the eventual direction for Wayland support, even in X11 compatibility mode, I would expect more use of gtk and less use of Xlib, not the other way around. -- Kevin On 4/10/2022 2:43 PM, Thiago Milczarek Say?o wrote: > Hi, > > I got simple samples running on the pure Xlib port of the Gtk backend. > > It still has gtk code, but mainly uses Xlib by now. Don't judge the code, > I'm porting it gradually. > > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib > > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar hello.HelloCursors > > Window coordinates and sizes are still off a bit, so you might have to > resize the window to redraw. > > -- Thiago. From thiago.sayao at gmail.com Mon Apr 11 17:51:40 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 11 Apr 2022 14:51:40 -0300 Subject: Xlib backend In-Reply-To: References: Message-ID: Kevin, Sure, I was hoping for the question. "The focus of GTK has moved away from being a ?meta toolkit? that other toolkits can use as a ?backend?." Quoted from https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 The first attempt I have made is the logical one, gtk4: https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground Then I have discovered it's not possible to use gtk4 without Xlib and that many window management functions are gone (see the quotation link). In addition to this: - Gtk4 cannot draw directly on the window or set the background without gtk4 css; - It cannot even move the window, just tell the compositor it started a move. I also have played plenty with gtk3, it breaks a lot of things thru the 3.x release cycle, such as DND. So, I see no reason to use Gtk if Xlib fits better as a glass backend (has all the needed functions) and Gtk would use Xlib anyway and hide much needed functionality. Current glass Gtk backend already touches a lot of Xlib. Wayland is fully compatible with Xlib, so we can work on "both worlds" with it. Someday on the future a pure Wayland backend would be nice. I'm happy to answer any further questions. -- Thiago. Em seg., 11 de abr. de 2022 ?s 12:41, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > Can you say more about the motivation for doing this? Given the eventual > direction for Wayland support, even in X11 compatibility mode, I would > expect more use of gtk and less use of Xlib, not the other way around. > > -- Kevin > > On 4/10/2022 2:43 PM, Thiago Milczarek Say?o wrote: > > Hi, > > > > I got simple samples running on the pure Xlib port of the Gtk backend. > > > > It still has gtk code, but mainly uses Xlib by now. Don't judge the code, > > I'm porting it gradually. > > > > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib > > > > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar > hello.HelloCursors > > > > Window coordinates and sizes are still off a bit, so you might have to > > resize the window to redraw. > > > > -- Thiago. > > From arapte at openjdk.java.net Tue Apr 12 11:44:43 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 12 Apr 2022 11:44:43 GMT Subject: RFR: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was not considering that URI can have query parameters. Fixed by checking URI path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, since we do support URI without extensions as long as they provide correct mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype checks failed to determine stream type. All playlists of HLS based on spec should start with #EXTM3U. For some reason this particular stream has mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec it should be "audio/mpegurl". Thus check for signature was added in case if URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this bug report due to provided example uses separate audio stream via EXT-X-MEDIA tag and it is not supported. I filed separate issue for this. Tested on windows. lgtm. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/750 From fkirmaier at openjdk.java.net Tue Apr 12 11:51:37 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 12 Apr 2022 11:51:37 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I've added another testbutton to the testclass. When we jump to somewhere in the middle, the selected index is not at the top, but somewhere else. Depending on the application, this can be quite a bit. In the affected application - it sometimes still jumps to places closer to the wrong cell compared to the right cell. The cell #2 should be at the top, but isnt. Screenshot 2022-04-12 at 13 47 49 ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From mhanl at openjdk.java.net Tue Apr 12 12:23:54 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 12 Apr 2022 12:23:54 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 13:01:45 GMT, Robert Lichtenberger wrote: >> Might make sense to also adjust the TreeTableView sizing implementation? > >> Might make sense to also adjust the TreeTableView sizing implementation? > > Yes I think that may be a good idea. True to the idea of specific, narrow commits I've not integrated this into this PR but would be willing to open a new issue / produce a separate PR for TreeTableView. @effad Do you have time and interest to take a look at this for the `TreeTableView` as well? Just asking as otherwise I will have a look :) ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From fkirmaier at openjdk.java.net Tue Apr 12 12:42:41 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 12 Apr 2022 12:42:41 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: <_IkVHoLW58Mdmg2FfLueXHYourtn5hbEewkVPvpyhm0=.b091889a-4de3-4052-9cba-09561597f81c@github.com> On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. After some investigating, it also doesn't properly scroll to the Bottom. I've added a minimal modified button to the TestApplication. Screenshot 2022-04-12 at 14 35 50 Is this conceptional doable, to get properly working scrollTo implementation for varying cell sizes? ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From sykora at openjdk.java.net Tue Apr 12 13:57:52 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 12 Apr 2022 13:57:52 GMT Subject: RFR: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on Windows, in order to match JDK 19 -- see [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. Successfully managed to run a build and test with VS 2022 17.1.0. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/766 From kcr at openjdk.java.net Tue Apr 12 14:55:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Apr 2022 14:55:53 GMT Subject: Integrated: 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows In-Reply-To: References: Message-ID: On Sat, 2 Apr 2022 17:34:46 GMT, Kevin Rushforth wrote: > This patch updates the compiler to Visual Studio 2022 version 17.1.0 on Windows, in order to match JDK 19 -- see [JDK-8283723](https://bugs.openjdk.java.net/browse/JDK-8283723). > > I ran a full build and test, including media and WebKit. This pull request has now been integrated. Changeset: 6d126382 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6d126382ddd59757081a866517c36ff09ba20125 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod 8283786: Update to Visual Studio 2022 version 17.1.0 on Windows Reviewed-by: arapte, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/766 From kcr at openjdk.java.net Tue Apr 12 15:19:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Apr 2022 15:19:02 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v2] In-Reply-To: References: Message-ID: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8283402-gcc-11.2 - 8283402: Update to gcc 11.2 on Linux ------------- Changes: https://git.openjdk.java.net/jfx/pull/761/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=761&range=01 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/761.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/761/head:pull/761 PR: https://git.openjdk.java.net/jfx/pull/761 From almatvee at openjdk.java.net Tue Apr 12 21:04:56 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 12 Apr 2022 21:04:56 GMT Subject: Integrated: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was not considering that URI can have query parameters. Fixed by checking URI path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, since we do support URI without extensions as long as they provide correct mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype checks failed to determine stream type. All playlists of HLS based on spec should start with #EXTM3U. For some reason this particular stream has mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec it should be "audio/mpegurl". Thus check for signature was added in case if URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this bug report due to provided example uses separate audio stream via EXT-X-MEDIA tag and it is not supported. I filed separate issue for this. This pull request has now been integrated. Changeset: d1110f47 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9 Stats: 65 lines in 2 files changed: 27 ins; 3 del; 35 mod 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/750 From kcr at openjdk.java.net Tue Apr 12 23:21:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 12 Apr 2022 23:21:13 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 06:49:59 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. This still uses the system Glib library on Linux, right? What Linux platforms have you tried this on? It fails for me on my local Ubuntu 16.04 system. In file included from ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c:137: ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c: In function 'gst_buffer_new_m emdup': ../../../gstreamer-lite/gstreamer/gst/glib-compat-private.h:34:90: error: implicit declaration of function 'g_abort'; did you mean 'abort'? [-Werror=implicit-function-declaration] 34 | #define g_memdup2(ptr,sz) ((G_LIKELY(((guint64)(sz)) < G_MAXUINT)) ? g_memdup(ptr,sz) : (g_abort(),NULL)) | ^~~~~~~ We compile with `-Werror=implicit-function-declaration`, so this fails the build. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From daniel.peintner at gmail.com Wed Apr 13 06:18:44 2022 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Wed, 13 Apr 2022 08:18:44 +0200 Subject: Application getParameters() not returning Umlaute properly In-Reply-To: <480c9428-c1db-2101-719d-17007377f909@gmail.com> References: <480c9428-c1db-2101-719d-17007377f909@gmail.com> Message-ID: Hello John, all, Thanks for your information. Below are some more details and further feedback. > In my application I associate a file extension which works fine. Clicking > > on the desktop opens the app and loads the file I clicked on. > > > > This works fine for Windows and Mac on its own. > > > > Assume a file named "Kostenscha?tzung.avax" is stored on MacOS and gets > > opened afterwards on Windows it fails. The filename on Windows is shown > > correctly but after clicking on it on Windows the following call > Where is this file stored? On a shared NAS? With SMB? > I personally tried sharing it on a NAS and sending it via Email. In my case I cannot reproduce the issue. It works fine in both cases. The reporter of the problem used sending via Email. Even if I get the attachment (the file) I see the problem locally. > For some reason, the parameters provided via the command line don't seem > to properly decode the second form (a + composing umlaut) but do > understand the first form (precomposed a-umlaut). This could be JavaFX, > but could be lower level as well. You could see what happens if you do > this with a non-JavaFX program, and get the parameters directly from a > `main` method. > That's a good point and I confirm it is not a JavaFX issue per se. A simple launcher class reports the undesired character from the beginning on. public class Launcher { public static void main(String[] args) { System.out.println("Arguments: " + Arrays.toString(args)); // launching JavaFX ... } } I reached out to the reporter but did not get any more feedback for now. Thanks, -- Daniel > > --John > From almatvee at openjdk.java.net Wed Apr 13 07:48:44 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 13 Apr 2022 07:48:44 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v2] In-Reply-To: References: Message-ID: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v2] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/0d515159..b45b1fb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=00-01 Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768 From jvos at openjdk.java.net Wed Apr 13 09:05:55 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 09:05:55 GMT Subject: [jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 Message-ID: Update JavaFX release version to 18.0.1 in jfx18 branch ------------- Commit messages: - Update JavaFX release version to 18.0.1 in jfx18 branch Changes: https://git.openjdk.java.net/jfx/pull/769/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=769&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284812 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/769/head:pull/769 PR: https://git.openjdk.java.net/jfx/pull/769 From johan.vos at gluonhq.com Wed Apr 13 09:16:38 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 13 Apr 2022 11:16:38 +0200 Subject: backport requests for 18.0.1 Message-ID: Hi Kevin, I request approval to backport the following issues to the jfx18 branch, for JavaFX 18.0.1: JDK-8278980: Update WebKit to 613.1 JDK-8281459: WebKit 613.1 build broken on M1 JDK-8281711: Cherry-pick WebKit 613.1 stabilization fixes JDK-8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) - Johan From kcr at openjdk.java.net Wed Apr 13 11:17:28 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Apr 2022 11:17:28 GMT Subject: [jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 08:59:45 GMT, Johan Vos wrote: > Update JavaFX release version to 18.0.1 in jfx18 branch Starting with JavaFX 18, the JBS version number in [.jcheck/conf](https://github.com/openjdk/jfx/blob/jfx18/.jcheck/conf#L27) also needs to be updated per [UPDATING-VERSION.md](https://github.com/openjdk/jfx/blob/jfx18/UPDATING-VERSION.md). This reminds me that I had forgotten to request openjfx18.0.1 and openjfx18.0.2 JBS versions, so I did that. Can you update the fix version in `.jcheck/conf` to `openjfx18.0.1`? ------------- PR: https://git.openjdk.java.net/jfx/pull/769 From kcr at openjdk.java.net Wed Apr 13 11:23:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Apr 2022 11:23:29 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v2] In-Reply-To: References: Message-ID: <5KXpYT3kmMfsn1eRhMBHIUgHhQEZf8K1qrlpaE19Ccg=.015a69cc-ae6d-4705-8b69-1b8a798b1fef@github.com> On Wed, 13 Apr 2022 07:48:44 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v2] The updated version gets past the earlier error, but still fails: ../../../gstreamer-lite/gstreamer/gst/gstelementfactory.c:494:28: error: implicit declaration of function 'g_object_new_with_properties'; did you mean 'g_object_class_list_properties'? [-Werror=implicit-function-declaration] 494 | element = (GstElement *) g_object_new_with_properties (factory->type, n, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | g_object_class_list_properties ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From kevin.rushforth at oracle.com Wed Apr 13 11:33:03 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Apr 2022 04:33:03 -0700 Subject: backport requests for 18.0.1 In-Reply-To: References: Message-ID: <77064dd3-72d1-c13d-40c0-7806130c4634@oracle.com> Looks good. -- Kevin On 4/13/2022 2:16 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following issues to the jfx18 branch, > for JavaFX 18.0.1: > > JDK-8278980: Update WebKit to 613.1 > JDK-8281459: WebKit 613.1 build broken on M1 > JDK-8281711: Cherry-pick WebKit 613.1 stabilization fixes > JDK-8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) > > - Johan From jvos at openjdk.java.net Wed Apr 13 11:56:09 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 11:56:09 GMT Subject: [jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 [v2] In-Reply-To: References: Message-ID: <2QeEQOjNWPhdU_KkcJIa19Nzk4KZY7TxrnzsAysOZZA=.3413ee4f-5c6f-497a-991d-ab6451c1817c@github.com> > Update JavaFX release version to 18.0.1 in jfx18 branch Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Update version in .jcheck/conf to 18.0.1 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/769/files - new: https://git.openjdk.java.net/jfx/pull/769/files/5b378e98..f8032a38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=769&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=769&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/769/head:pull/769 PR: https://git.openjdk.java.net/jfx/pull/769 From kcr at openjdk.java.net Wed Apr 13 12:19:28 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Apr 2022 12:19:28 GMT Subject: [jfx18] RFR: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 [v2] In-Reply-To: <2QeEQOjNWPhdU_KkcJIa19Nzk4KZY7TxrnzsAysOZZA=.3413ee4f-5c6f-497a-991d-ab6451c1817c@github.com> References: <2QeEQOjNWPhdU_KkcJIa19Nzk4KZY7TxrnzsAysOZZA=.3413ee4f-5c6f-497a-991d-ab6451c1817c@github.com> Message-ID: On Wed, 13 Apr 2022 11:56:09 GMT, Johan Vos wrote: >> Update JavaFX release version to 18.0.1 in jfx18 branch > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Update version in .jcheck/conf to 18.0.1 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/769 From jvos at openjdk.java.net Wed Apr 13 12:25:27 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 12:25:27 GMT Subject: [jfx18] Integrated: 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 08:59:45 GMT, Johan Vos wrote: > Update JavaFX release version to 18.0.1 in jfx18 branch This pull request has now been integrated. Changeset: 87cb6594 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/87cb65949c468774bd6973198e45bb3e372f52f3 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8284812: Change JavaFX release version in jfx18 branch to 18.0.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/769 From jvos at openjdk.java.net Wed Apr 13 13:08:40 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 13:08:40 GMT Subject: [jfx18] RFR: 8278980: Update WebKit to 613.1 Message-ID: Co-authored-by: Ajit Ghaisas Co-authored-by: Jay Bhaskar Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, aghaisas ------------- Commit messages: - 8278980: Update WebKit to 613.1 Changes: https://git.openjdk.java.net/jfx/pull/770/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=770&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278980 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod Patch: https://git.openjdk.java.net/jfx/pull/770.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/770/head:pull/770 PR: https://git.openjdk.java.net/jfx/pull/770 From kcr at openjdk.java.net Wed Apr 13 13:09:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 13 Apr 2022 13:09:38 GMT Subject: [jfx18] RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 12:35:18 GMT, Johan Vos wrote: > Co-authored-by: Ajit Ghaisas > Co-authored-by: Jay Bhaskar > Co-authored-by: Kevin Rushforth > Reviewed-by: kcr, jvos, aghaisas Marked as reviewed by kcr (Lead). I can confirm that this is a clean patch, even though Skara doesn't record it as clean -- see [SKARA-1332](https://bugs.openjdk.java.net/browse/SKARA-1332). ------------- PR: https://git.openjdk.java.net/jfx/pull/770 From jvos at openjdk.java.net Wed Apr 13 13:22:23 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 13:22:23 GMT Subject: [jfx18] Integrated: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 12:35:18 GMT, Johan Vos wrote: > Co-authored-by: Ajit Ghaisas > Co-authored-by: Jay Bhaskar > Co-authored-by: Kevin Rushforth > Reviewed-by: kcr, jvos, aghaisas This pull request has now been integrated. Changeset: f19b57ae Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/f19b57ae44090d775d9adf52b2013933eba0aa02 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod 8278980: Update WebKit to 613.1 Reviewed-by: kcr Backport-of: 6f28d912024495278c4c35ab054bc2aab480b3e4 ------------- PR: https://git.openjdk.java.net/jfx/pull/770 From jvos at openjdk.java.net Wed Apr 13 13:49:39 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 13:49:39 GMT Subject: [jfx18] RFR: 8281459: WebKit 613.1 build broken on M1 Message-ID: Reviewed-by: kcr, jvos ------------- Commit messages: - 8281459: WebKit 613.1 build broken on M1 Changes: https://git.openjdk.java.net/jfx/pull/771/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281459 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/771.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/771/head:pull/771 PR: https://git.openjdk.java.net/jfx/pull/771 From jvos at openjdk.java.net Wed Apr 13 14:12:26 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 14:12:26 GMT Subject: [jfx18] Integrated: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 13:43:18 GMT, Johan Vos wrote: > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 66661d74 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/66661d74d01addf3b6481f0af7866c8454b6cfdf Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Backport-of: cdebc6cbafb579148b4addee44d307bd9739454b ------------- PR: https://git.openjdk.java.net/jfx/pull/771 From jvos at openjdk.java.net Wed Apr 13 14:22:03 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 14:22:03 GMT Subject: [jfx18] RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes Message-ID: Stabilization fixes from WebKitGTK 2.34.5 Reviewed-by: jvos, kcr ------------- Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx/pull/772/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=772&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx/pull/772.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/772/head:pull/772 PR: https://git.openjdk.java.net/jfx/pull/772 From jvos at openjdk.java.net Wed Apr 13 15:24:29 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 15:24:29 GMT Subject: [jfx18] Withdrawn: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: <7svDj3q0bJ7Wg_OHQAgSnVJSX-KF3MkMiZ_GRIyvnGA=.2c497cd4-df7a-439f-bd3b-0e4d5f3c7a2b@github.com> On Wed, 13 Apr 2022 14:15:29 GMT, Johan Vos wrote: > Stabilization fixes from WebKitGTK 2.34.5 > > Reviewed-by: jvos, kcr This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/772 From jvos at openjdk.java.net Wed Apr 13 15:29:57 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 15:29:57 GMT Subject: [jfx18] RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes Message-ID: Stabilization fixes from WebKitGTK 2.34.5 Reviewed-by: jvos, kcr ------------- Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx/pull/773/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=773&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx/pull/773.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/773/head:pull/773 PR: https://git.openjdk.java.net/jfx/pull/773 From jvos at openjdk.java.net Wed Apr 13 15:59:27 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 15:59:27 GMT Subject: [jfx18] Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: <8iVSElmyV-ump2i-vuaMXm9sAL0-N1WEIWriZRZByvA=.40ff5e9c-d5c7-4d42-9d80-55975b5352fc@github.com> On Wed, 13 Apr 2022 15:22:22 GMT, Johan Vos wrote: > Stabilization fixes from WebKitGTK 2.34.5 > > Reviewed-by: jvos, kcr This pull request has now been integrated. Changeset: 0402975a Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/0402975a4cae590296915ea9bd9ea755c97f1ca2 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod 8281711: Cherry-pick WebKit 613.1 stabilization fixes Stabilization fixes from WebKitGTK 2.34.5 Backport-of: 418d3437923fed0a298c48b54214af069e3bb3bd ------------- PR: https://git.openjdk.java.net/jfx/pull/773 From jvos at openjdk.java.net Wed Apr 13 16:07:52 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 16:07:52 GMT Subject: [jfx18] RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Message-ID: Reviewed-by: kcr, jvos ------------- Commit messages: - 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Changes: https://git.openjdk.java.net/jfx/pull/774/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=774&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282099 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/774.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/774/head:pull/774 PR: https://git.openjdk.java.net/jfx/pull/774 From jvos at openjdk.java.net Wed Apr 13 16:55:17 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 13 Apr 2022 16:55:17 GMT Subject: [jfx18] Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 16:00:41 GMT, Johan Vos wrote: > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 7e2cefba Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/7e2cefba7f28fc0570b7495a08203756caa5327c Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Backport-of: 6f201f7a02dba14328d183e7d0db5dede4416ce4 ------------- PR: https://git.openjdk.java.net/jfx/pull/774 From duke at openjdk.java.net Thu Apr 14 08:33:16 2022 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 14 Apr 2022 08:33:16 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I don't believe that it is possible to position the content and scrollbar **exactly**, if the VirtualFlow **estimates** the size of the cells. For that case we need an external cell size provider, that I, as an application developer, can provide to the e.g. ListView. I thought of something like this. The existing estimation logic can then be implemented as a default cell size provider. interface CellSizeProvider { /** * Returns the size of all cells. * IMPORTANT: Be carefully by implementing this method. It can drastically degrade the performance of a component. */ double getTotalSize(); /** * Returns the size of the cell for an item given by its index. * IMPORTANT: Be carefully by implementing this method. It can drastically degrade the performance of a component. */ double getCellSize(int); /** * The callback which is set by the VirtualFlow. It allows to calculate the cell size for an item given by its index. * IMPORTANT: This callback returns the exact value, but it may be slow. */ void setCellSizeCalculator(Function cellSizeCalculator); } ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From jvos at openjdk.java.net Thu Apr 14 08:55:18 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 14 Apr 2022 08:55:18 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I agree with that observation. The mathematical perfect situation would be to pre-calculate the height of all items, so that the scrolbar position can be exact, and the content placing can be exact as well. That would be at the price of a major performance overhead for large lists. For small lists, this overhead is more acceptable. I agree that this is something that could be rather application-defined instead of having heuristics in the ListView. As a historical note, before https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were considered of equali height for the position of the scrollbar. In the current case, if that precondition holds, the estimated size will be the real size, so in that case there is no need to calculate the height of every item before getting the correct total size. This is again something the application knows best -- even with non-fixed cell heights, the expected variations might be small enough and if they are randomly spread, the estimate will soon be "good enough". ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From almatvee at openjdk.java.net Fri Apr 15 23:29:54 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 15 Apr 2022 23:29:54 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v3] In-Reply-To: References: Message-ID: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v3] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/b45b1fb1..51cc1e0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=01-02 Stats: 211 lines in 11 files changed: 210 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768 From almatvee at openjdk.java.net Sat Apr 16 01:23:46 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 16 Apr 2022 01:23:46 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v3] In-Reply-To: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> References: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> Message-ID: On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] Update GStreamer to 1.20.1 [v2] - Made caps writable before changing them in qtdemux, otherwise values are not set and critical error printed in console. - Fixed compilation error in GstAudioSpectrum.cpp by casting pointer. - Added g_abort() if it is not defined (building with older GLib). Update GStreamer to 1.20.1 [v3] - Added -Werror=deprecated-declarations and GLIB_VERSION_MIN_REQUIRED/GLIB_VERSION_MAX_ALLOWED=2.48.0 to Linux makefiles. GLIB_VERSION_MIN_REQUIRED/GLIB_VERSION_MAX_ALLOWED will give deprecated warnings when code uses APIs from GLib which where added after 2.48.0. -Werror=deprecated-declarations will fail build if such warning detected. This is needed to make sure that we can build and run with older GLib starting with 2.48.0 and up. - avplugin does not have -Werror=deprecated-declarations, because avplugin uses deprecated APIs from libavcodec and build fails with this flag and fixing avplugin is out of scope of GStreamer update. - Fixed build issues that were discovered after above was implemented, so we can build/run with GLib 2.48.0 and up. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From kcr at openjdk.java.net Sat Apr 16 15:10:45 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 16 Apr 2022 15:10:45 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v3] In-Reply-To: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> References: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> Message-ID: On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] I see one remaining build failure on Ubuntu 16.04, which should be easy to fix: ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] 367 | memcpy (dup_data, data, size); | ^~~~~~ ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: warning: incompatible implicit declaration of built-in function 'memcpy' ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:27:1: note: include '' or provide a declaration of 'memcpy' 26 | #include +++ |+#include 27 | In file included from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytewriter.h:25, from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytewriter.c:26: ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h: In function 'gst_byte_reader_dup_data_unchecked': ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] 367 | memcpy (dup_data, data, size); | ^~~~~~ ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: warning: incompatible implicit declaration of built-in function 'memcpy' The workaround you needed to do this time suggests we will need a different approach for the next update. I think we will need to consider one of two things: 1. Build and link glib-lite on Linux, as we do for the other platforms 2. Bump the minimum version of GLib needed to build or run JavaFX media. This would mean we would no longer run on Ubuntu 16.0.4 (and probably older versions of RHEL / Oracle Linux). We can decide as it gets closer to the next update. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From almatvee at openjdk.java.net Mon Apr 18 18:38:03 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 18 Apr 2022 18:38:03 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v4] In-Reply-To: References: Message-ID: <-u2SN8yiUYZG-JTU_t2aWmaMmGaykcqyMnKuZsgM7cY=.bc957426-4a3b-416e-a995-f7f86fb423c9@github.com> > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v4] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/51cc1e0f..a29cd34b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768 From almatvee at openjdk.java.net Mon Apr 18 18:38:05 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 18 Apr 2022 18:38:05 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v3] In-Reply-To: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> References: <326ODcuHha0fQ08xakQIRgfq2Lms9sX777AJ3tcWD70=.66f99d55-ded0-42ce-919a-baf047e9d457@github.com> Message-ID: <_gkUON3LOTiAG0h1zAqb3PL0HfbxgwiCPlZu8148Am8=.f609485f-76a3-4285-9c5b-cc52004ed78a@github.com> On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] 8283218: Update GStreamer to 1.20.1 [v4] - Added missing include file (string.h). ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From rlichten at openjdk.java.net Tue Apr 19 06:12:29 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 19 Apr 2022 06:12:29 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: Message-ID: <8lGkNEAWS2RlSXmoh1Aus5VBQDgV-pJflqiZvUdQTIc=.1de1f6ad-e0b8-4613-9814-f1e308c93923@github.com> On Wed, 16 Mar 2022 13:01:45 GMT, Robert Lichtenberger wrote: >> Might make sense to also adjust the TreeTableView sizing implementation? > >> Might make sense to also adjust the TreeTableView sizing implementation? > > Yes I think that may be a good idea. True to the idea of specific, narrow commits I've not integrated this into this PR but would be willing to open a new issue / produce a separate PR for TreeTableView. > @effad Do you have time and interest to take a look at this for the `TreeTableView` as well? Just asking as otherwise I will have a look :) Sorry for late response (extended easter holidays ...). Yes I could also take a look at this for TreeTableView. Is there a pre-existing issue for this? Otherwise I'll try and come up with an example and create a new issue... ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From mhanl at openjdk.java.net Tue Apr 19 10:01:29 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 19 Apr 2022 10:01:29 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: <8lGkNEAWS2RlSXmoh1Aus5VBQDgV-pJflqiZvUdQTIc=.1de1f6ad-e0b8-4613-9814-f1e308c93923@github.com> References: <8lGkNEAWS2RlSXmoh1Aus5VBQDgV-pJflqiZvUdQTIc=.1de1f6ad-e0b8-4613-9814-f1e308c93923@github.com> Message-ID: On Tue, 19 Apr 2022 06:06:25 GMT, Robert Lichtenberger wrote: > Is there a pre-existing issue for this? Otherwise I'll try and come up with an example and create a new issue... I don't think so, you may need to create a new issue. I think it's pretty much the same problem and solution as this ticket was, so you can probably copy some information. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From kevin.rushforth at oracle.com Tue Apr 19 16:03:07 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Apr 2022 09:03:07 -0700 Subject: RFR: Request to sync April 2022 changes into jfx master In-Reply-To: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> Message-ID: <4261b0a3-97d5-e63a-cbe6-e5e89bbd7516@oracle.com> Hi Johan, I request approval to sync changes from to the just-released April 2022 CPU release into the 'master' branch of the 'jfx' repo. Here is the aggregate set of changes for the fixes: https://github.com/kevinrushforth/jfx/compare/d1110f4795...cpu-2204-sync As a note, the patches initially applied cleanly, but there was a subsequent merge conflict with the WebKit 613.1 update that had to be resolved. NOTE: Since this is an integration of already-reviewed fixes, I will push it directly to the master branch of the jfx repo rather than via a pull request. -- Kevin From kevin.rushforth at oracle.com Tue Apr 19 16:03:39 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Apr 2022 09:03:39 -0700 Subject: [jfx18, jfx17u, jfx11u] RFR: Request to backport April 2022 CPU changes Message-ID: Hi Johan, I request approval to backport the changes from the just-released April 2022 CPU to jfx:jfx18 (for 18.0.1), jfx17u (for 17.0.3) and to jfx11u (for 11.0.15) . https://github.com/kevinrushforth/jfx17u/compare/4af7ee97f3...cpu-2204-sync https://github.com/kevinrushforth/jfx11u/compare/1c3d966688...cpu-2204-sync https://github.com/kevinrushforth/jfx/compare/7e2cefba7f...18-cpu-2204-sync For each repo, this is a straight backport (patches initially applied cleanly, but then the same merge conflict had to be resolved in each code line as was done in the mainline) of the two FX fix that went into the April CPU. NOTE: Since this is an integration of already-reviewed fixes, I will push it directly to the jfx18 branch of the jfx repo, and to the master branch of the jfx17u and jfx11u repos rather than via a pull request. Thanks. -- Kevin From johan.vos at gluonhq.com Tue Apr 19 16:07:14 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 19 Apr 2022 18:07:14 +0200 Subject: RFR: Request to sync April 2022 changes into jfx master In-Reply-To: <4261b0a3-97d5-e63a-cbe6-e5e89bbd7516@oracle.com> References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com> <4261b0a3-97d5-e63a-cbe6-e5e89bbd7516@oracle.com> Message-ID: Approved. On Tue, Apr 19, 2022 at 6:03 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to sync changes from to the just-released April 2022 > CPU release into the 'master' branch of the 'jfx' repo. Here is the > aggregate set of changes for the fixes: > > https://github.com/kevinrushforth/jfx/compare/d1110f4795...cpu-2204-sync > > As a note, the patches initially applied cleanly, but there was a > subsequent merge conflict with the WebKit 613.1 update that had to be > resolved. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the master branch of the jfx repo rather than via a > pull request. > > -- Kevin > > From johan.vos at gluonhq.com Tue Apr 19 16:07:29 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 19 Apr 2022 18:07:29 +0200 Subject: [jfx18, jfx17u, jfx11u] RFR: Request to backport April 2022 CPU changes In-Reply-To: References: Message-ID: Approved. On Tue, Apr 19, 2022 at 6:03 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the changes from the just-released April > 2022 CPU to jfx:jfx18 (for 18.0.1), jfx17u (for 17.0.3) and to jfx11u > (for 11.0.15) . > > https://github.com/kevinrushforth/jfx17u/compare/4af7ee97f3...cpu-2204-sync > https://github.com/kevinrushforth/jfx11u/compare/1c3d966688...cpu-2204-sync > https://github.com/kevinrushforth/jfx/compare/7e2cefba7f...18-cpu-2204-sync > > For each repo, this is a straight backport (patches initially applied > cleanly, but then the same merge conflict had to be resolved in each > code line as was done in the mainline) of the two FX fix that went into > the April CPU. > > NOTE: Since this is an integration of already-reviewed fixes, I will > push it directly to the jfx18 branch of the jfx repo, and to the master > branch of the jfx17u and jfx11u repos rather than via a pull request. > > Thanks. > > -- Kevin > > From almatvee at openjdk.java.net Tue Apr 19 22:44:08 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 19 Apr 2022 22:44:08 GMT Subject: RFR: 8283318: Videos with unusual sizes cannot be played on windows Message-ID: <2DA94ImMDRo3BGA4n_HefL32uNXihLRX71vf1aojk4Y=.c1800e7f-019a-4a09-8aa1-4f708c36bbac@github.com> Fixed by removing check which enables dynamic format change, since it requires for portrait videos, not standard resolutions and anything that has width > 1920 or/and height > 1080. ------------- Commit messages: - 8283318: Videos with unusual sizes cannot be played on windows Changes: https://git.openjdk.java.net/jfx/pull/775/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=775&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283318 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/775/head:pull/775 PR: https://git.openjdk.java.net/jfx/pull/775 From jvos at openjdk.java.net Wed Apr 20 06:44:07 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 06:44:07 GMT Subject: [jfx11u] RFR: 8285152: Change JavaFX release version to 11.0.16 in jfx11u Message-ID: Update security version for JavaFX 11 to 16. ------------- Commit messages: - Update security version for JavaFX 11 to 16. Changes: https://git.openjdk.java.net/jfx11u/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=83&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285152 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/83/head:pull/83 PR: https://git.openjdk.java.net/jfx11u/pull/83 From jvos at openjdk.java.net Wed Apr 20 07:07:19 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 07:07:19 GMT Subject: [jfx18] RFR: 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch Message-ID: <8cjoodQb9Xjcc6TSmsM6Q0mU6gMbDOeJ-ZX8vtF7RQE=.99dfd67b-705c-42ba-9321-1200dbf0a99b@github.com> Increase security version to 2 for JavaFX 18.0.2 ------------- Commit messages: - Increase security version to 2 for JavaFX 18.0.2 Changes: https://git.openjdk.java.net/jfx/pull/776/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=776&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285181 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/776.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/776/head:pull/776 PR: https://git.openjdk.java.net/jfx/pull/776 From jvos at openjdk.java.net Wed Apr 20 07:14:08 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 07:14:08 GMT Subject: [jfx17u] RFR: 8285153: Change JavaFX release version to 17.0.4 in jfx17u Message-ID: Update security version for JavaFX 17 to 4. ------------- Commit messages: - Increase security version to 4 Changes: https://git.openjdk.java.net/jfx17u/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285153 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx17u/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/40/head:pull/40 PR: https://git.openjdk.java.net/jfx17u/pull/40 From rlichten at openjdk.java.net Wed Apr 20 08:56:42 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Wed, 20 Apr 2022 08:56:42 GMT Subject: RFR: 8251480: TableColumnHeader: calc of cell width must respect row styling In-Reply-To: References: <8lGkNEAWS2RlSXmoh1Aus5VBQDgV-pJflqiZvUdQTIc=.1de1f6ad-e0b8-4613-9814-f1e308c93923@github.com> Message-ID: On Tue, 19 Apr 2022 09:57:58 GMT, Marius Hanl wrote: >>> @effad Do you have time and interest to take a look at this for the `TreeTableView` as well? Just asking as otherwise I will have a look :) >> >> Sorry for late response (extended easter holidays ...). Yes I could also take a look at this for TreeTableView. Is there a pre-existing issue for this? Otherwise I'll try and come up with an example and create a new issue... > >> Is there a pre-existing issue for this? Otherwise I'll try and come up with an example and create a new issue... > > I don't think so, you may need to create a new issue. I think it's pretty much the same problem and solution as this ticket was, so you can probably copy some information. @Maran23 https://bugs.openjdk.java.net/browse/JDK-8285197 created. ------------- PR: https://git.openjdk.java.net/jfx/pull/757 From kcr at openjdk.java.net Wed Apr 20 12:09:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 12:09:38 GMT Subject: [jfx18] RFR: 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch In-Reply-To: <8cjoodQb9Xjcc6TSmsM6Q0mU6gMbDOeJ-ZX8vtF7RQE=.99dfd67b-705c-42ba-9321-1200dbf0a99b@github.com> References: <8cjoodQb9Xjcc6TSmsM6Q0mU6gMbDOeJ-ZX8vtF7RQE=.99dfd67b-705c-42ba-9321-1200dbf0a99b@github.com> Message-ID: On Wed, 20 Apr 2022 07:00:46 GMT, Johan Vos wrote: > Increase security version to 2 for JavaFX 18.0.2 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/776 From kcr at openjdk.java.net Wed Apr 20 12:10:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 12:10:35 GMT Subject: [jfx17u] RFR: 8285153: Change JavaFX release version to 17.0.4 in jfx17u In-Reply-To: References: Message-ID: <5-v3gZfKygvxV1Z9k_2knJgyUKpsn4onxdWRYXTEGS0=.acec5bcd-27dd-4698-9596-b04613fbe1b1@github.com> On Wed, 20 Apr 2022 06:43:32 GMT, Johan Vos wrote: > Update security version for JavaFX 17 to 4. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/40 From kcr at openjdk.java.net Wed Apr 20 12:10:36 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 12:10:36 GMT Subject: [jfx11u] RFR: 8285152: Change JavaFX release version to 11.0.16 in jfx11u In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 06:37:08 GMT, Johan Vos wrote: > Update security version for JavaFX 11 to 16. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/83 From jvos at openjdk.java.net Wed Apr 20 12:57:30 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 12:57:30 GMT Subject: [jfx17u] Integrated: 8285153: Change JavaFX release version to 17.0.4 in jfx17u In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 06:43:32 GMT, Johan Vos wrote: > Update security version for JavaFX 17 to 4. This pull request has now been integrated. Changeset: b41307ff Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/b41307ff3f0cec70f1eafe808173ec0fb0cba36c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285153: Change JavaFX release version to 17.0.4 in jfx17u Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx17u/pull/40 From jvos at openjdk.java.net Wed Apr 20 12:58:29 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 12:58:29 GMT Subject: [jfx11u] Integrated: 8285152: Change JavaFX release version to 11.0.16 in jfx11u In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 06:37:08 GMT, Johan Vos wrote: > Update security version for JavaFX 11 to 16. This pull request has now been integrated. Changeset: f0440390 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/f0440390bdb064c7a5a4cfd19bdba47322cd3009 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285152: Change JavaFX release version to 11.0.16 in jfx11u Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx11u/pull/83 From johan.vos at gluonhq.com Wed Apr 20 12:59:28 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 20 Apr 2022 14:59:28 +0200 Subject: Backport requests for JavaFX 11, 17, 18 Message-ID: Hi Kevin, I request permission to backport the following issue to JavaFX 11.0.16, JavaFX 17.0.4 and JavaFX 18.0.2 https://bugs.openjdk.java.net/browse/JDK-8283328 Apart from whitespace warnings, the patch applies clean - Johan From jvos at openjdk.java.net Wed Apr 20 12:55:41 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 12:55:41 GMT Subject: [jfx18] Integrated: 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch In-Reply-To: <8cjoodQb9Xjcc6TSmsM6Q0mU6gMbDOeJ-ZX8vtF7RQE=.99dfd67b-705c-42ba-9321-1200dbf0a99b@github.com> References: <8cjoodQb9Xjcc6TSmsM6Q0mU6gMbDOeJ-ZX8vtF7RQE=.99dfd67b-705c-42ba-9321-1200dbf0a99b@github.com> Message-ID: On Wed, 20 Apr 2022 07:00:46 GMT, Johan Vos wrote: > Increase security version to 2 for JavaFX 18.0.2 This pull request has now been integrated. Changeset: 60d76c8b Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/60d76c8b5d60a816376aa569ad562b56fc790b4c Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8285181: Change JavaFX release version to 18.0.2 in jfx18 branch Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/776 From kevin.rushforth at oracle.com Wed Apr 20 13:06:58 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Apr 2022 06:06:58 -0700 Subject: [External] : Backport requests for JavaFX 11, 17, 18 In-Reply-To: References: Message-ID: <0efac533-8ffe-8524-bed6-ad0fe488a2a9@oracle.com> +1 On 4/20/2022 5:59 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issue to JavaFX > 11.0.16, JavaFX 17.0.4 and JavaFX 18.0.2 > > https://bugs.openjdk.java.net/browse/JDK-8283328 > > Apart from whitespace warnings, the patch applies clean > > - Johan From jvos at openjdk.java.net Wed Apr 20 13:30:21 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 13:30:21 GMT Subject: [jfx11u] RFR: 8283328: Update libxml2 to 2.9.13 Message-ID: Reviewed-by: jvos, kcr, arapte ------------- Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx11u/pull/84/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=84&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx11u/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/84/head:pull/84 PR: https://git.openjdk.java.net/jfx11u/pull/84 From jvos at openjdk.java.net Wed Apr 20 13:32:05 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 13:32:05 GMT Subject: [jfx17u] RFR: 8283328: Update libxml2 to 2.9.13 Message-ID: Reviewed-by: jvos, kcr, arapte ------------- Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx17u/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx17u/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx17u/pull/41 From jvos at openjdk.java.net Wed Apr 20 13:37:14 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 13:37:14 GMT Subject: [jfx18] RFR: 8283328: Update libxml2 to 2.9.13 Message-ID: Reviewed-by: jvos, kcr, arapte ------------- Commit messages: - 8283328: Update libxml2 to 2.9.13 Changes: https://git.openjdk.java.net/jfx/pull/777/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=777&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283328 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod Patch: https://git.openjdk.java.net/jfx/pull/777.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/777/head:pull/777 PR: https://git.openjdk.java.net/jfx/pull/777 From kcr at openjdk.java.net Wed Apr 20 13:49:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 13:49:30 GMT Subject: [jfx17u] RFR: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:24:53 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte I confirm that this is a clean backport, but Skara failed to detect that it was clean due to [SKARA-1332](https://bugs.openjdk.java.net/browse/SKARA-1332). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/41 From kcr at openjdk.java.net Wed Apr 20 13:51:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 13:51:30 GMT Subject: [jfx11u] RFR: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:21:39 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte I confirm that this is a clean backport, but Skara failed to detect that it was clean due to [SKARA-1332](https://bugs.openjdk.java.net/browse/SKARA-1332). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/84 From kcr at openjdk.java.net Wed Apr 20 13:54:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 13:54:35 GMT Subject: [jfx18] RFR: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: <3ei3Wa2ozxhEv8jcXVZOagmc2AH1THd8p04MvsgGyZg=.c6a11750-4dae-46a8-b206-f097b002d383@github.com> On Wed, 20 Apr 2022 13:29:36 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte I confirm that this is a clean backport, but Skara failed to detect that it was clean due to [SKARA-1332](https://bugs.openjdk.java.net/browse/SKARA-1332). ------------- PR: https://git.openjdk.java.net/jfx/pull/777 From jvos at openjdk.java.net Wed Apr 20 14:22:33 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 14:22:33 GMT Subject: [jfx17u] Integrated: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:24:53 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 5c0d0a65 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/5c0d0a653f6066c545b2cc61655f29e99c9ccca6 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/41 From jvos at openjdk.java.net Wed Apr 20 14:22:44 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 14:22:44 GMT Subject: [jfx18] Integrated: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:29:36 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 2a1805a2 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/2a1805a2b9ac83011677b654d2505d7147a6e916 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 ------------- PR: https://git.openjdk.java.net/jfx/pull/777 From jvos at openjdk.java.net Wed Apr 20 14:23:42 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 20 Apr 2022 14:23:42 GMT Subject: [jfx11u] Integrated: 8283328: Update libxml2 to 2.9.13 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 13:21:39 GMT, Johan Vos wrote: > Reviewed-by: jvos, kcr, arapte This pull request has now been integrated. Changeset: 1b214b04 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/1b214b04f78e5bbf2d49f63e7995f55141dba6b4 Stats: 55661 lines in 105 files changed: 5761 ins; 24999 del; 24901 mod 8283328: Update libxml2 to 2.9.13 Backport-of: b0f2521219efc1b0d0c45088736d5105712bc2c9 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/84 From jpereda at openjdk.java.net Wed Apr 20 18:32:19 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 20 Apr 2022 18:32:19 GMT Subject: RFR: 8285217: [Android] Window's screen is not updated after native screen was disposed Message-ID: This PR updates the screen for each window even for the case where the old screen has been disposed but there is a new screen instance found for such window. This is the case of Android, where the lifecycle of the application allows destroying the native screen when the app goes to the background, and providing a new native screen, in case it comes back to the foreground. Before this PR, the screen for the window wasn't updated after returning from the background, and if orientation changes happened, the dimensions were wrong. ------------- Commit messages: - Update the screen for each window even after old screen being disposed Changes: https://git.openjdk.java.net/jfx/pull/778/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=778&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285217 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/778.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/778/head:pull/778 PR: https://git.openjdk.java.net/jfx/pull/778 From almatvee at openjdk.java.net Wed Apr 20 23:08:00 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 20 Apr 2022 23:08:00 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v5] In-Reply-To: References: Message-ID: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v5] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/a29cd34b..39f0b050 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=768&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768 From almatvee at openjdk.java.net Wed Apr 20 23:08:01 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 20 Apr 2022 23:08:01 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v4] In-Reply-To: <-u2SN8yiUYZG-JTU_t2aWmaMmGaykcqyMnKuZsgM7cY=.bc957426-4a3b-416e-a995-f7f86fb423c9@github.com> References: <-u2SN8yiUYZG-JTU_t2aWmaMmGaykcqyMnKuZsgM7cY=.bc957426-4a3b-416e-a995-f7f86fb423c9@github.com> Message-ID: <93EY5JLqnr68ZV8LY4-PKubx-em8fMc0poomWvCDxeA=.f1443a41-63ec-4dcf-9f21-94ae50efe438@github.com> On Mon, 18 Apr 2022 18:38:03 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v4] 8283218: Update GStreamer to 1.20.1 [v5] - Added missing define which required for Windows 32-bit build. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From kcr at openjdk.java.net Wed Apr 20 23:08:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 20 Apr 2022 23:08:02 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v4] In-Reply-To: <-u2SN8yiUYZG-JTU_t2aWmaMmGaykcqyMnKuZsgM7cY=.bc957426-4a3b-416e-a995-f7f86fb423c9@github.com> References: <-u2SN8yiUYZG-JTU_t2aWmaMmGaykcqyMnKuZsgM7cY=.bc957426-4a3b-416e-a995-f7f86fb423c9@github.com> Message-ID: <3fq8TvLmYFgrNxkjY0R1Yro7Bq7alUCJ6scEGffkM5o=.a1e36b32-839a-47df-91bd-d8f1faf1f304@github.com> On Mon, 18 Apr 2022 18:38:03 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v4] The latest patch builds and runs for me now on Ubuntu 16.04. I do want to make sure that regardless of whatever system we build it on, the binary is able to run on the oldest version we are targeting. Otherwise, a binary built on, say, Oracle Linux 7.x or Ubuntu 20.04 might not run on an Ubuntu 16.04 system. Basically what we don't want is to be dependent on a particular version of libraries at compile time. The more I think about it, the best long term solution (not this time) is probably to build and deliver glib-lite.so on Linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From jpereda at openjdk.java.net Thu Apr 21 08:37:11 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 21 Apr 2022 08:37:11 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem [v3] In-Reply-To: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: > This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). > > When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. > > This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. > > This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. > > Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. > > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Fix spacing in tests - Merge branch 'master' into 8193442-treeitemselection - Merge branch 'master' into 8193442-treeitemselection - Don't shift selection/focus if item is below removed element ------------- Changes: https://git.openjdk.java.net/jfx/pull/753/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=753&range=02 Stats: 193 lines in 5 files changed: 175 ins; 12 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/753.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/753/head:pull/753 PR: https://git.openjdk.java.net/jfx/pull/753 From rlichten at openjdk.java.net Thu Apr 21 08:44:56 2022 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 21 Apr 2022 08:44:56 GMT Subject: RFR: 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) Message-ID: Separate test class added for TreeTableView case. Fix is analogous to JDK-8251480. ------------- Commit messages: - 8285197: TableColumnHeader: calc of cell width must respect row styling (TreeTableView) Changes: https://git.openjdk.java.net/jfx/pull/779/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=779&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285197 Stats: 183 lines in 2 files changed: 179 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/779.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/779/head:pull/779 PR: https://git.openjdk.java.net/jfx/pull/779 From aghaisas at openjdk.java.net Thu Apr 21 11:29:28 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 21 Apr 2022 11:29:28 GMT Subject: RFR: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests Message-ID: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> This PR is to cleanup a few `javafx.controls` unit tests that were ignored. Here is the list of targeted unit test classes- - Ignored tests re-enabled and fixed - `DateCellTest`, `CellTest`, `PaginationTest` - Ignored tests removed - `RadioMenuItemTest`, `PopupControlTest` Results of `javafx.controls` unit tests- **Before this PR :** Total tests - 8610 Failures - 0 Ignored - 246 **After this PR :** Total tests - 8608 Failures - 0 Ignored - 235 ------------- Commit messages: - fix or remove ignored unit tests Changes: https://git.openjdk.java.net/jfx/pull/780/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=780&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285360 Stats: 49 lines in 5 files changed: 24 ins; 24 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/780.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/780/head:pull/780 PR: https://git.openjdk.java.net/jfx/pull/780 From Rony.Flatscher at wu.ac.at Thu Apr 21 11:53:55 2022 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 21 Apr 2022 13:53:55 +0200 Subject: Question ad css' -fx-font-family Message-ID: <94556ab7-8dab-1e66-4d1a-ed3a245b5366@wu.ac.at> Not sure whether these are bugs or working as intended: * setting in a css "-fx-font-family" to: ??? -fx-font-family: "IBM Plex Mono","Liberation Mono",Consolas,Monaco,Terminus,Courier,monospace; If the first listed font is not found then JavaFX uses the "family=System" rather than trying all listed fonts in sequence and if none is found using "family=Monospaced". Testing on a Windows system with "Liberation Mono", "Consolas" and "Courier" installed will yield "family=System" if retrieving the used font from the control. * It seems that if the first font family in the list is not found in "-fx-font-family" by JavaFX then all other listed font families get ignored and the fallback seems to be "family=System". Is this to be expected or is this a bug (have not found anything in the bug database)? ---rony From Rony.Flatscher at wu.ac.at Thu Apr 21 11:57:14 2022 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 21 Apr 2022 13:57:14 +0200 Subject: Not finding installed font family on Windows Message-ID: Having installed the "IBM Plex" (otf) fonts (e.g. a file like "IBMPlexMono-Text.otf") to the global Windows font directory at "C:\Windows\Fonts" (%windir%\Fonts) the font family "IBM Plex Mono" and the like does not get listed with "javafx.scene.text.Font.getFamilies()". Using javafx.scene.text.Font.getFontNames() the fonts are listed (e.g. as "IBMPlexMono-Text"). Is this to be expected, no font family, but font names carrying the name of the otf-font file only rather than the logical name of the "open type font"? ---rony P.S.: This may be related to although it sounds to be a different issue. From hmeda at openjdk.java.net Thu Apr 21 15:09:08 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Thu, 21 Apr 2022 15:09:08 GMT Subject: RFR: 8278430 : Several tests use terminally deprecated System.runFinalization method Message-ID: This PR is to remove calls to deprecated method System.runFinalization. Here is the list of module wise test cases affected by the removal: **web**: test.javafx.scene.web.LeakTest **systemTests**: test.memoryleak.JSCallbackMemoryTest test.javafx.embed.swing.SwingNodeDnDMemoryLeakTest test.javafx.embed.swing.SwingNodeMemoryLeakTest test.javafx.scene.control.AccordionTitlePaneLeakTest test.javafx.scene.control.TabPaneHeaderLeakTest test.javafx.scene.shape.ShapeViewOrderLeakTest test.javafx.scene.shape.meshmanagercacheleaktest.MeshManagerCacheLeakApp test.javafx.stage.FocusedWindowTestBase --tests test.memoryleak.JSCallbackMemoryTest test.robot.javafx.web.TooltipFXTest **graphics**: test.javafx.scene.SceneTest **controls**: test.javafx.scene.control.ToggleButtonTest test.javafx.scene.control.ControlAcceleratorSupportTest **base**: Executed above tests for 50 iterations on windows and Mac. No regressions observed.All tests run fine. ------------- Commit messages: - Remove deprecated call - Remove deprecated method runFinalization - Remove calls to deprecated method System.runFinalization Changes: https://git.openjdk.java.net/jfx/pull/781/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=781&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278430 Stats: 38 lines in 20 files changed: 0 ins; 38 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/781.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/781/head:pull/781 PR: https://git.openjdk.java.net/jfx/pull/781 From arapte at openjdk.java.net Thu Apr 21 15:13:58 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 21 Apr 2022 15:13:58 GMT Subject: RFR: 8282449: Intermittent OOM error in PredefinedMeshManagerTest Message-ID: This is a test only fix. The tests used to create Sphere and Cylinder of large divisions, which could fail intermittently with OOM. The tests were added along with the fix for [JDK-8180151](https://bugs.openjdk.java.net/browse/JDK-8180151). The attributes of Sphere and Cylinder were chosen such that their hash code would collide. The large number of divisions results in creating large sized triangle mesh and sometimes cause OOM. The fix: is to use different combination of hashcode colliding attributes with smaller number of divisions to avoid OOM. There are two commits in the PR: 1. [First commit](https://github.com/openjdk/jfx/commit/1ff6054503f5042f9ede54faac6fa00ec4369612) contains the source changes with which test should fail. Only `sphereCacheTest` fails with this commit but not the `cylinderCacheTest`. The earlier combination of Cylinder attributes also does NOT fail. 2. [Second commit](https://github.com/openjdk/jfx/commit/0c8649abe94ef2b526007c37fab6910315a98654) reverts the source code changes. ------------- Commit messages: - revert temp source changes - commit with source changes where test fails Changes: https://git.openjdk.java.net/jfx/pull/782/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=782&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282449 Stats: 9 lines in 1 file changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/782.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/782/head:pull/782 PR: https://git.openjdk.java.net/jfx/pull/782 From arapte at openjdk.java.net Thu Apr 21 15:50:58 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 21 Apr 2022 15:50:58 GMT Subject: RFR: 8285034: Skip ServiceTest.testManyServicesRunConcurrently on Windows Message-ID: The test ServiceTest.testManyServicesRunConcurrently fails intermittently on Windows platform with a time out error. Test needs to be skipped until fixed. ------------- Commit messages: - skip-test Changes: https://git.openjdk.java.net/jfx/pull/783/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=783&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285034 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/783.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/783/head:pull/783 PR: https://git.openjdk.java.net/jfx/pull/783 From jvos at openjdk.java.net Thu Apr 21 18:18:43 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 21 Apr 2022 18:18:43 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 23:08:00 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v5] Marked as reviewed by jvos (Reviewer). I have this working on Ubuntu 18.04, and that gives me enough confidence that with the appropriate toolchain it can be built for 16.04. Exploring glib-lite.so sounds like a good plan. ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From kcr at openjdk.java.net Thu Apr 21 20:20:39 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Apr 2022 20:20:39 GMT Subject: RFR: 8283218: Update GStreamer to 1.20.1 [v5] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 23:08:00 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v5] Answering my own question from above, I was able to take a `gstreamer-lite` binary built on Oracle Linux 7.x and run it on my Ubuntu 16.04 system, so it looks like we are good to go. Alexander or I will file a follow-on bug to build and ship `glib-lite` on Linux. It will allow some of the custom code to be reverted, and will avoid this problem the next time we update GLib. It also matches what we do for the other platforms (and what we do for Linux on Oracle's JDK 8u releases, so we have a data point that shows it to be a feasible approach). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/768 From kcr at openjdk.java.net Thu Apr 21 20:28:27 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Apr 2022 20:28:27 GMT Subject: RFR: 8285034: Skip ServiceTest.testManyServicesRunConcurrently on Windows In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:44:57 GMT, Ambarish Rapte wrote: > The test ServiceTest.testManyServicesRunConcurrently fails intermittently on Windows platform with a time out error. > Test needs to be skipped until fixed. LGTM ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/783 From kcr at openjdk.java.net Thu Apr 21 20:31:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Apr 2022 20:31:46 GMT Subject: RFR: 8282449: Intermittent OOM error in PredefinedMeshManagerTest In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:07:38 GMT, Ambarish Rapte wrote: > This is a test only fix. The tests used to create Sphere and Cylinder of large divisions, which could fail intermittently with OOM. > The tests were added along with the fix for [JDK-8180151](https://bugs.openjdk.java.net/browse/JDK-8180151). > The attributes of Sphere and Cylinder were chosen such that their hash code would collide. The large number of divisions results in creating large sized triangle mesh and sometimes cause OOM. > > The fix: is to use different combination of hashcode colliding attributes with smaller number of divisions to avoid OOM. > > There are two commits in the PR: > 1. [First commit](https://github.com/openjdk/jfx/commit/1ff6054503f5042f9ede54faac6fa00ec4369612) contains the source changes with which test should fail. Only `sphereCacheTest` fails with this commit but not the `cylinderCacheTest`. The earlier combination of Cylinder attributes also does NOT fail. > 2. [Second commit](https://github.com/openjdk/jfx/commit/0c8649abe94ef2b526007c37fab6910315a98654) reverts the source code changes. Looks good. Thanks for the explanation regarding the replacement values. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/782 From almatvee at openjdk.java.net Thu Apr 21 20:33:43 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 21 Apr 2022 20:33:43 GMT Subject: Integrated: 8283218: Update GStreamer to 1.20.1 In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 06:49:59 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. This pull request has now been integrated. Changeset: c4b1a72c Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 Stats: 38924 lines in 413 files changed: 22010 ins; 5981 del; 10933 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/768 From kcr at openjdk.java.net Thu Apr 21 22:22:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 21 Apr 2022 22:22:35 GMT Subject: RFR: 8278430 : Several tests use terminally deprecated System.runFinalization method In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:03:04 GMT, Hima Bindu Meda wrote: > This PR is to remove calls to deprecated method System.runFinalization. > Here is the list of module wise test cases affected by the removal: > > **web**: > test.javafx.scene.web.LeakTest > > **systemTests**: > test.memoryleak.JSCallbackMemoryTest > test.javafx.embed.swing.SwingNodeDnDMemoryLeakTest > test.javafx.embed.swing.SwingNodeMemoryLeakTest > test.javafx.scene.control.AccordionTitlePaneLeakTest > test.javafx.scene.control.TabPaneHeaderLeakTest > test.javafx.scene.shape.ShapeViewOrderLeakTest test.javafx.scene.shape.meshmanagercacheleaktest.MeshManagerCacheLeakApp test.javafx.stage.FocusedWindowTestBase --tests test.memoryleak.JSCallbackMemoryTest > test.robot.javafx.web.TooltipFXTest > > **graphics**: > test.javafx.scene.SceneTest > > **controls**: > test.javafx.scene.control.ToggleButtonTest > test.javafx.scene.control.ControlAcceleratorSupportTest > > **base**: > > Executed above tests for 50 iterations on windows and Mac. > No regressions observed.All tests run fine. Looks good. I did a sanity test run on Mac and found no new issues. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/781 From arapte at openjdk.java.net Fri Apr 22 01:42:42 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 22 Apr 2022 01:42:42 GMT Subject: Integrated: 8282449: Intermittent OOM error in PredefinedMeshManagerTest In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:07:38 GMT, Ambarish Rapte wrote: > This is a test only fix. The tests used to create Sphere and Cylinder of large divisions, which could fail intermittently with OOM. > The tests were added along with the fix for [JDK-8180151](https://bugs.openjdk.java.net/browse/JDK-8180151). > The attributes of Sphere and Cylinder were chosen such that their hash code would collide. The large number of divisions results in creating large sized triangle mesh and sometimes cause OOM. > > The fix: is to use different combination of hashcode colliding attributes with smaller number of divisions to avoid OOM. > > There are two commits in the PR: > 1. [First commit](https://github.com/openjdk/jfx/commit/1ff6054503f5042f9ede54faac6fa00ec4369612) contains the source changes with which test should fail. Only `sphereCacheTest` fails with this commit but not the `cylinderCacheTest`. The earlier combination of Cylinder attributes also does NOT fail. > 2. [Second commit](https://github.com/openjdk/jfx/commit/0c8649abe94ef2b526007c37fab6910315a98654) reverts the source code changes. This pull request has now been integrated. Changeset: 7ddcb8bd Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/7ddcb8bdf8549c3c140b8697c781eb294ea2b0dc Stats: 9 lines in 1 file changed: 0 ins; 3 del; 6 mod 8282449: Intermittent OOM error in PredefinedMeshManagerTest Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/782 From arapte at openjdk.java.net Fri Apr 22 01:44:29 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 22 Apr 2022 01:44:29 GMT Subject: Integrated: 8285034: Skip ServiceTest.testManyServicesRunConcurrently on Windows In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:44:57 GMT, Ambarish Rapte wrote: > The test ServiceTest.testManyServicesRunConcurrently fails intermittently on Windows platform with a time out error. > Test needs to be skipped until fixed. This pull request has now been integrated. Changeset: 5a023bd8 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/5a023bd8d15a0e70336bad96efa39e24a07679da Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8285034: Skip ServiceTest.testManyServicesRunConcurrently on Windows Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/783 From arapte at openjdk.java.net Fri Apr 22 06:33:41 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 22 Apr 2022 06:33:41 GMT Subject: RFR: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests In-Reply-To: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> References: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> Message-ID: On Thu, 21 Apr 2022 11:23:35 GMT, Ajit Ghaisas wrote: > This PR is to cleanup a few `javafx.controls` unit tests that were ignored. > > Here is the list of targeted unit test classes- > - Ignored tests re-enabled and fixed - `DateCellTest`, `CellTest`, `PaginationTest` > - Ignored tests removed - `RadioMenuItemTest`, `PopupControlTest` > > Results of `javafx.controls` unit tests- > **Before this PR :** > Total tests - 8610 > Failures - 0 > Ignored - 246 > > **After this PR :** > Total tests - 8608 > Failures - 0 > Ignored - 235 Looks good to me, Providing minor suggestions. modules/javafx.controls/src/test/java/test/javafx/scene/control/CellTest.java line 387: > 385: cell.requestFocus(); > 386: Toolkit.getToolkit().firePulse(); > 387: Minor: Optional: Adding `assertTrue(cell.isEditing());` here can be a good sanity check. But I leave it to you. Similar comment for the change in `DateCellTest.loseFocusWhileEditing()` modules/javafx.controls/src/test/java/test/javafx/scene/control/CellTest.java line 392: > 390: > 391: assertFalse(cell.isEditing()); > 392: } I would recommend to call `stage.hide()` similar to that in the `@AfterClass cleanup` methods. Similar comment for the change in `DateCellTest.loseFocusWhileEditing()` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/780 From aghaisas at openjdk.java.net Fri Apr 22 07:30:25 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 22 Apr 2022 07:30:25 GMT Subject: RFR: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests [v2] In-Reply-To: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> References: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> Message-ID: > This PR is to cleanup a few `javafx.controls` unit tests that were ignored. > > Here is the list of targeted unit test classes- > - Ignored tests re-enabled and fixed - `DateCellTest`, `CellTest`, `PaginationTest` > - Ignored tests removed - `RadioMenuItemTest`, `PopupControlTest` > > Results of `javafx.controls` unit tests- > **Before this PR :** > Total tests - 8610 > Failures - 0 > Ignored - 246 > > **After this PR :** > Total tests - 8608 > Failures - 0 > Ignored - 235 Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/780/files - new: https://git.openjdk.java.net/jfx/pull/780/files/679c54e2..2d8366fc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=780&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=780&range=00-01 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/780.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/780/head:pull/780 PR: https://git.openjdk.java.net/jfx/pull/780 From aghaisas at openjdk.java.net Fri Apr 22 07:30:26 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 22 Apr 2022 07:30:26 GMT Subject: RFR: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests [v2] In-Reply-To: References: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> Message-ID: <65Q1qV22xLJG4DX8cEGluBsDSxcEI75_vihmgPvl1kg=.ad59fd56-b39d-4e7f-957e-9867f8980460@github.com> On Fri, 22 Apr 2022 06:27:49 GMT, Ambarish Rapte wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > modules/javafx.controls/src/test/java/test/javafx/scene/control/CellTest.java line 387: > >> 385: cell.requestFocus(); >> 386: Toolkit.getToolkit().firePulse(); >> 387: > > Minor: Optional: > Adding `assertTrue(cell.isEditing());` here can be a good sanity check. But I leave it to you. > Similar comment for the change in `DateCellTest.loseFocusWhileEditing()` Done. > modules/javafx.controls/src/test/java/test/javafx/scene/control/CellTest.java line 392: > >> 390: >> 391: assertFalse(cell.isEditing()); >> 392: } > > I would recommend to call `stage.hide()` similar to that in the `@AfterClass cleanup` methods. > Similar comment for the change in `DateCellTest.loseFocusWhileEditing()` I have added `stage.hide()` to these tests, also to the `PaginationTest` class. ------------- PR: https://git.openjdk.java.net/jfx/pull/780 From arapte at openjdk.java.net Fri Apr 22 07:58:30 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 22 Apr 2022 07:58:30 GMT Subject: RFR: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests [v2] In-Reply-To: References: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> Message-ID: On Fri, 22 Apr 2022 07:30:25 GMT, Ajit Ghaisas wrote: >> This PR is to cleanup a few `javafx.controls` unit tests that were ignored. >> >> Here is the list of targeted unit test classes- >> - Ignored tests re-enabled and fixed - `DateCellTest`, `CellTest`, `PaginationTest` >> - Ignored tests removed - `RadioMenuItemTest`, `PopupControlTest` >> >> Results of `javafx.controls` unit tests- >> **Before this PR :** >> Total tests - 8610 >> Failures - 0 >> Ignored - 246 >> >> **After this PR :** >> Total tests - 8608 >> Failures - 0 >> Ignored - 235 > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > address review comments LGTM ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/780 From aghaisas at openjdk.java.net Fri Apr 22 10:58:40 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 22 Apr 2022 10:58:40 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem [v3] In-Reply-To: References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: On Thu, 21 Apr 2022 08:37:11 GMT, Jose Pereda wrote: >> This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). >> >> When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. >> >> This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. >> >> This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. >> >> Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. >> >> In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Fix spacing in tests > - Merge branch 'master' into 8193442-treeitemselection > - Merge branch 'master' into 8193442-treeitemselection > - Don't shift selection/focus if item is below removed element Looks good to me. Apart from the bug id in title, you can use `/issue` command to list additional issues this PR fixes. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/753 From hmeda at openjdk.java.net Fri Apr 22 17:50:38 2022 From: hmeda at openjdk.java.net (Hima Bindu Meda) Date: Fri, 22 Apr 2022 17:50:38 GMT Subject: Integrated: 8278430 : Several tests use terminally deprecated System.runFinalization method In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 15:03:04 GMT, Hima Bindu Meda wrote: > This PR is to remove calls to deprecated method System.runFinalization. > Here is the list of module wise test cases affected by the removal: > > **web**: > test.javafx.scene.web.LeakTest > > **systemTests**: > test.memoryleak.JSCallbackMemoryTest > test.javafx.embed.swing.SwingNodeDnDMemoryLeakTest > test.javafx.embed.swing.SwingNodeMemoryLeakTest > test.javafx.scene.control.AccordionTitlePaneLeakTest > test.javafx.scene.control.TabPaneHeaderLeakTest > test.javafx.scene.shape.ShapeViewOrderLeakTest test.javafx.scene.shape.meshmanagercacheleaktest.MeshManagerCacheLeakApp test.javafx.stage.FocusedWindowTestBase --tests test.memoryleak.JSCallbackMemoryTest > test.robot.javafx.web.TooltipFXTest > > **graphics**: > test.javafx.scene.SceneTest > > **controls**: > test.javafx.scene.control.ToggleButtonTest > test.javafx.scene.control.ControlAcceleratorSupportTest > > **base**: > > Executed above tests for 50 iterations on windows and Mac. > No regressions observed.All tests run fine. This pull request has now been integrated. Changeset: 166d5c2f Author: Hima Bindu Meda Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/166d5c2f248aec2117c0023194bfe480bf110eb5 Stats: 38 lines in 20 files changed: 0 ins; 38 del; 0 mod 8278430: Several tests use terminally deprecated System.runFinalization method Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/781 From kcr at openjdk.java.net Fri Apr 22 18:57:35 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Apr 2022 18:57:35 GMT Subject: RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem [v3] In-Reply-To: References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: On Thu, 21 Apr 2022 08:37:11 GMT, Jose Pereda wrote: >> This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). >> >> When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. >> >> This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. >> >> This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. >> >> Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. >> >> In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. > > Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Fix spacing in tests > - Merge branch 'master' into 8193442-treeitemselection > - Merge branch 'master' into 8193442-treeitemselection > - Don't shift selection/focus if item is below removed element Looks good. > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. After this is integrated, can you close JDK-8088157 as "Cannot reproduce"? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/753 From jpereda at openjdk.java.net Fri Apr 22 19:29:33 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 22 Apr 2022 19:29:33 GMT Subject: Integrated: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> References: <78Wj3WTkQSJYaYO9nJVBnwtmYl1Dd0_XT8DUAwo0Hfs=.342a937b-4915-4d0d-aa43-5a818547cd5f@github.com> Message-ID: On Mon, 14 Mar 2022 14:49:41 GMT, Jose Pereda wrote: > This PR fixes JDK-[8193442](https://bugs.openjdk.java.net/browse/JDK-8193442), but also [JDK-8187596](https://bugs.openjdk.java.net/browse/JDK-8187596), and verifies that the tests mentioned in [JDK-8088157](https://bugs.openjdk.java.net/browse/JDK-8088157) are working (with a minor fix). > > When removing an item that is below the selected item from TreeTableView or TreeView controls the selection and/or focus was wrongly changed in some occasions, because a shift in the selection was applied. > > This PR adds a method to ControlUtils to get the index of the sibling that is selected/focused or contains the descendant item with the current selection/focus. > > This index is required to compare properly if the selected/focus item is above or below the item that was removed, by comparing the indices of siblings. > > Tests have been added to TreeViewTest and TreeTableViewTest based on the existing tests on JDK-8193442 and JDK-8187596. The four tests fail without this PR, pass with it. > > In the process, I noticed that the ignored tests referred from JDK-8088157 were already passing, after removing some obsolete asserts, even without this PR. This pull request has now been integrated. Changeset: 3bb2db12 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/3bb2db12a4ae3fe4a26420f0af57c189b2549edb Stats: 193 lines in 5 files changed: 175 ins; 12 del; 6 mod 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem 8187596: TreeView selection incorrectly changes after deleting an unselected row Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/753 From tsayao at openjdk.java.net Fri Apr 22 19:35:49 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 22 Apr 2022 19:35:49 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage Message-ID: When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. The fix also works for: https://bugs.openjdk.java.net/browse/JDK-8269429 But this one might need another fix: https://bugs.openjdk.java.net/browse/JDK-8240640 ------------- Commit messages: - Fix for JDK-8284654 - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - ... and 12 more: https://git.openjdk.java.net/jfx/compare/d1110f47...72317b21 Changes: https://git.openjdk.java.net/jfx/pull/784/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=784&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284654 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784 From kcr at openjdk.java.net Fri Apr 22 19:48:30 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 22 Apr 2022 19:48:30 GMT Subject: RFR: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: <2uK6eLjfcheKMILJiAvnbwHzFK7lgCDkmOclqFKepz4=.5143f0c6-fcee-4e4f-8acc-de5f5ac73499@github.com> On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 I'll take a look at it, and also ask @arapte to review. As you know from my comment in the bug report, I especially want to ensure that this causes no regressions, so need to test [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) on macOS. ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From aghaisas at openjdk.java.net Sat Apr 23 11:27:32 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Sat, 23 Apr 2022 11:27:32 GMT Subject: Integrated: 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests In-Reply-To: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> References: <1q73oMpDIk3ZLUgk6ecohU-A2ebDxe1O3mxdS4QxpcE=.ce4614c4-0420-414d-9456-7ca20c5ccdbb@github.com> Message-ID: On Thu, 21 Apr 2022 11:23:35 GMT, Ajit Ghaisas wrote: > This PR is to cleanup a few `javafx.controls` unit tests that were ignored. > > Here is the list of targeted unit test classes- > - Ignored tests re-enabled and fixed - `DateCellTest`, `CellTest`, `PaginationTest` > - Ignored tests removed - `RadioMenuItemTest`, `PopupControlTest` > > Results of `javafx.controls` unit tests- > **Before this PR :** > Total tests - 8610 > Failures - 0 > Ignored - 246 > > **After this PR :** > Total tests - 8608 > Failures - 0 > Ignored - 235 This pull request has now been integrated. Changeset: 318204b4 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/318204b47530e532abf8738693e6eefa2de00543 Stats: 58 lines in 5 files changed: 33 ins; 24 del; 1 mod 8285360: [TestBug] Cleanup a few ignored javafx.controls unit tests Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/780 From thiago.sayao at gmail.com Sun Apr 24 20:40:57 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 24 Apr 2022 17:40:57 -0300 Subject: Xlib backend In-Reply-To: <4hzgkqn7my.fsf@qfs.de> References: <4hzgkqn7my.fsf@qfs.de> Message-ID: Hi, Xlib port at: https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib Is able to very poorly run Ensemble8: java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar Keyboard events still do not work, mouse clicks are still buggy. There will be crashes, but it's progress. Window size & positioning is better now. I am painting directly like this: void WindowContextBase::paint(void* data, jint width, jint height) { Pixmap pixmap = XCreatePixmapFromBitmapData(display, DefaultRootWindow(display), (char *) data, width, height, 0, 0, depth); XCopyPlane(display, pixmap, xwindow, DefaultGC(display, DefaultScreen(display)), 0, 0, width, height, 0, 0, 1); XFlush(display); XFreePixmap(display, pixmap); } It does flicker a little, maybe it needs XSync extension to draw together with WM, maybe some kind of buffering. Using cairo is possible, but it's a final render, not sure if there will be advantages. I am accepting opinions. -- Thiago. Em ter., 12 de abr. de 2022 ?s 03:22, escreveu: > > Hi Thiago, > > I wholly agree. > > If gtk can be taken out of the equation it will reduce dependencies > significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing > cross-embedding. Moving to gtk3 would start this all over again > whereas plain Xlib should remain fully compatible regardless of the > gtk version used by Swing (or SWT or whatever). > > I'll gladly help with testing - just ping me when you've got a > version that is reasonably stable. > > Best regards, > Greg > > Thiago Milczarek Say?o writes: > > > Kevin, > > > > Sure, I was hoping for the question. > > > > "The focus of GTK has moved away from being a ?meta toolkit? that other > > toolkits can use as a ?backend?." > > > > Quoted from > > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 > > > > The first attempt I have made is the logical one, gtk4: > > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground > > > > Then I have discovered it's not possible to use gtk4 without Xlib and > that > > many window management functions are gone (see the quotation link). > > In addition to this: > > - Gtk4 cannot draw directly on the window or set the background without > > gtk4 css; > > - It cannot even move the window, just tell the compositor it started a > > move. > > > > I also have played plenty with gtk3, it breaks a lot of things thru the > 3.x > > release cycle, such as DND. > > > > So, I see no reason to use Gtk if Xlib fits better as a glass backend > (has > > all the needed functions) and Gtk would use Xlib anyway and hide much > > needed functionality. > > > > Current glass Gtk backend already touches a lot of Xlib. > > > > Wayland is fully compatible with Xlib, so we can work on "both worlds" > with > > it. Someday on the future a pure Wayland backend would be nice. > > > > I'm happy to answer any further questions. > > > > -- Thiago. > > > > > > > > > > Em seg., 11 de abr. de 2022 ?s 12:41, Kevin Rushforth < > > kevin.rushforth at oracle.com> escreveu: > > > >> Can you say more about the motivation for doing this? Given the eventual > >> direction for Wayland support, even in X11 compatibility mode, I would > >> expect more use of gtk and less use of Xlib, not the other way around. > >> > >> -- Kevin > >> > >> On 4/10/2022 2:43 PM, Thiago Milczarek Say?o wrote: > >> > Hi, > >> > > >> > I got simple samples running on the pure Xlib port of the Gtk backend. > >> > > >> > It still has gtk code, but mainly uses Xlib by now. Don't judge the > code, > >> > I'm porting it gradually. > >> > > >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib > >> > > >> > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar > >> hello.HelloCursors > >> > > >> > Window coordinates and sizes are still off a bit, so you might have to > >> > resize the window to redraw. > >> > > >> > -- Thiago. > >> > >> > > -- > Gregor Schmid > > E: gregor.schmid at qfs.de > T: +49 8171 38648-11 > F: +49 8171 38648-16 > > Quality First Software GmbH | www.qfs.de > B?rgermeister-Graf-Ring 10 | 82538 Geretsried | Germany > GF Gregor Schmid, Karlheinz Kellerer > HRB M?nchen 140833 > > The data protection information in accordance with the EU General Data > Protection Regulation applies to authorized representatives / > authorized representatives of "legal persons" in accordance with Art. > 12 ff. DS-GVO > https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf > From fkirmaier at openjdk.java.net Mon Apr 25 09:04:40 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 25 Apr 2022 09:04:40 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Thu, 14 Apr 2022 08:52:27 GMT, Johan Vos wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't shift cells if we are already showing the lowest index cell. > > I agree with that observation. The mathematical perfect situation would be to pre-calculate the height of all items, so that the scrolbar position can be exact, and the content placing can be exact as well. That would be at the price of a major performance overhead for large lists. For small lists, this overhead is more acceptable. > > I agree that this is something that could be rather application-defined instead of having heuristics in the ListView. > > As a historical note, before https://bugs.openjdk.java.net/browse/JDK-8089589 was fixed, all items were considered of equali height for the position of the scrollbar. In the current case, if that precondition holds, the estimated size will be the real size, so in that case there is no need to calculate the height of every item before getting the correct total size. > This is again something the application knows best -- even with non-fixed cell heights, the expected variations might be small enough and if they are randomly spread, the estimate will soon be "good enough". @johanvos As requested, we've made a unit test, which tests this bug. It's based on your test and our original test class. It can be added to the ListViewTest. You can find it, in the JDK ticket. Btw, adding the cells incrementally seems to make a difference - which is why the new test class tests both cases. It accepts various inputs of cell sizes - and should work with any inputs. It should catch all the cases from the original test class. Because it works with all possible inputs - one could even make a random test-cases generator to make sure it works in every case. It basically only works well, when the sizes are only 20s - in most other cases it fails. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From nlisker at openjdk.java.net Mon Apr 25 12:09:00 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 25 Apr 2022 12:09:00 GMT Subject: RFR: 8285534: Update the 3D lighting test sample Message-ID: Update the the test utility. Includes: * Refactoring since there is no more need the split pre- and post-attenuation and light types. * Added customizable material to the `Boxes` to test the interaction between lights and materials.. * Light colors can now be changed. Note that GitHub decided to count the removal of the `AttenLightingSample` and addition of the `Controls` file as renaming. The sample is now run now only through `LightingSample`. ------------- Commit messages: - Restore - del - Initial commit Changes: https://git.openjdk.java.net/jfx/pull/787/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285534 Stats: 541 lines in 5 files changed: 304 ins; 203 del; 34 mod Patch: https://git.openjdk.java.net/jfx/pull/787.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/787/head:pull/787 PR: https://git.openjdk.java.net/jfx/pull/787 From duke at openjdk.java.net Mon Apr 25 20:55:21 2022 From: duke at openjdk.java.net (=?UTF-8?B?RnJhbsOnb2lz?= Martin) Date: Mon, 25 Apr 2022 20:55:21 GMT Subject: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: <7k7s4lS7YP788fIeQ0t-ei8cX9baQMtWrYvjJ8gFQYU=.3cd49594-266c-4fe4-b87e-fd7258aeffa2@github.com> On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Don't shift cells if we are already showing the lowest index cell. I noticed this bug as well, but in my case even when the `CellHeight` stays the same (so I'm not sure if it's the same or something else)... A minimal repro example: public class ApplicationUI extends VBox { private final ObservableList elements = FXCollections.observableArrayList(); public ApplicationUI() { Button button = new Button("Add New Element"); ListView listView = new ListView<>(elements); setVgrow(listView, Priority.ALWAYS); getChildren().addAll(listView, button); button.setOnAction(event -> { elements.add(String.valueOf(elements.size())); }); elements.addListener((ListChangeListener) c -> { while (c.next()) { listView.scrollTo(c.getFrom()); } }); } } Click the button until there is a scroll bar, it always seems to scroll down to the second last element in the list, instead of the last. Interestingly, changing the line from `listView.scrollTo(c.getFrom());` to `listView.scrollTo(c.getFrom()-1);` or `listView.scrollTo(c.getFrom()+1);` results in the same behavior, however changing it to `listView.scrollTo(c.getFrom()-2);` does scroll correctly to the last item in the list? Just thought I would share this in case this would help find the issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/712 From nlisker at gmail.com Tue Apr 26 01:25:27 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 26 Apr 2022 04:25:27 +0300 Subject: D3D pipeline possible inconsistencies Message-ID: Hi, Using the updated lighting test sample [1], I found some odd behavior with regards to PhongMaterial: 1. The effect of the opacity (alpha channel) of a self-illumination map is not documented, but lowering its value makes the object darker. I looked at the pixel shader [2] and only the rgb components are sampled, so I'm a bit confused here. What is the intended behavior? 2. The opacity of the object is controlled in the shader by both the diffuse color and diffuse map. This is also not documented (although it might be obvious for some). In the shader, the pixel (fragment) is discarded only if the map is fully transparent (line 55), but not the color. This leads to a situation where the object completely disappears when the map is transparent, but not when the color is. In the shader, the pixel should be transparent because of the multiplication of the alpha, but it's not, so this is also confusing. Should they both have the same contribution? Shouldn't it be valid to have a transparent diffuse but still have specular reflections? 3. The specular map and color behave differently in regards to the opacity. There is no documented behavior here. The alpha on the color is ignored (it's used for the specular power), but not on the map - it controls the reflection's strength, probably by making its color darker. In the shader, lines 76-84 indeed ignore the alpha of the color, but take the alpha of the map, although later in line 93 it's not used, so again I'm confused. What's the intended behavior? 4. The specular map and color also behave differently in regards to the reflection's strength. In the shader, this happens in line 78: the specular power is corrected with NTSC_Gray if there is a map (with or without color), but not if there's only a color. Shouldn't the contributions be the same? Is the NTSC_Gray correction correct in this case? Thanks, Nir [1] https://github.com/openjdk/jfx/pull/787 [2] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl From kcr at openjdk.java.net Tue Apr 26 13:33:40 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Apr 2022 13:33:40 GMT Subject: [jfx18] RFR: 8285475: Create release notes for 18.0.1 In-Reply-To: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> References: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> Message-ID: On Mon, 25 Apr 2022 06:50:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18.0.1 to the repository The following two non-public (security) fixes are also included in 18.0.1: JDK-8276371 (not public) | Better long buffering | web JDK-8277465 (not public) | Additional fix for JDK-8276371 | web ------------- PR: https://git.openjdk.java.net/jfx/pull/785 From duke at openjdk.java.net Tue Apr 26 13:33:40 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 26 Apr 2022 13:33:40 GMT Subject: [jfx18] RFR: 8285475: Create release notes for 18.0.1 Message-ID: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> Add release notes for JavaFX 18.0.1 to the repository ------------- Commit messages: - Add list of security fixes - 8285475: Create release notes for 18.0.1 Changes: https://git.openjdk.java.net/jfx/pull/785/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=785&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285475 Stats: 24 lines in 1 file changed: 24 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/785.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/785/head:pull/785 PR: https://git.openjdk.java.net/jfx/pull/785 From kcr at openjdk.java.net Tue Apr 26 14:20:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 26 Apr 2022 14:20:08 GMT Subject: [jfx18] RFR: 8285475: Create release notes for 18.0.1 In-Reply-To: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> References: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> Message-ID: On Mon, 25 Apr 2022 06:50:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18.0.1 to the repository Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/785 From duke at openjdk.java.net Tue Apr 26 15:07:54 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 26 Apr 2022 15:07:54 GMT Subject: [jfx18] Integrated: 8285475: Create release notes for 18.0.1 In-Reply-To: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> References: <8ytYMiFqheGhMzCNSzb-QRJVT3RIHzOPc3kCuanlcSA=.b2f22a86-38c4-496d-bfda-13b25d581ba6@github.com> Message-ID: On Mon, 25 Apr 2022 06:50:07 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 18.0.1 to the repository This pull request has now been integrated. Changeset: f0099c25 Author: Abhinay Agarwal Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/f0099c256f6b8d02d5dd3bb4aa5d9def043c240c Stats: 24 lines in 1 file changed: 24 ins; 0 del; 0 mod 8285475: Create release notes for 18.0.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/785 From nlisker at gmail.com Tue Apr 26 18:41:59 2022 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 26 Apr 2022 21:41:59 +0300 Subject: D3D pipeline possible inconsistencies In-Reply-To: References: Message-ID: I found a comment [1] on JBS stating that specular and self-Illumination alphas should be ignored, so it seems like there's at least 2 bugs here already. https://bugs.openjdk.java.net/browse/JDK-8090548?focusedCommentId=13771150&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13771150 On Tue, Apr 26, 2022 at 4:25 AM Nir Lisker wrote: > Hi, > > Using the updated lighting test sample [1], I found some odd behavior with > regards to PhongMaterial: > > 1. The effect of the opacity (alpha channel) of a self-illumination map is > not documented, but lowering its value makes the object darker. I looked at > the pixel shader [2] and only the rgb components are sampled, so I'm a bit > confused here. What is the intended behavior? > > 2. The opacity of the object is controlled in the shader by both the > diffuse color and diffuse map. This is also not documented (although it > might be obvious for some). In the shader, the pixel (fragment) is > discarded only if the map is fully transparent (line 55), but not the > color. This leads to a situation where the object completely disappears > when the map is transparent, but not when the color is. In the shader, the > pixel should be transparent because of the multiplication of the alpha, but > it's not, so this is also confusing. Should they both have the same > contribution? Shouldn't it be valid to have a transparent diffuse but still > have specular reflections? > > 3. The specular map and color behave differently in regards to the > opacity. There is no documented behavior here. The alpha on the color is > ignored (it's used for the specular power), but not on the map - it > controls the reflection's strength, probably by making its color darker. In > the shader, lines 76-84 indeed ignore the alpha of the color, but take the > alpha of the map, although later in line 93 it's not used, so again I'm > confused. What's the intended behavior? > > 4. The specular map and color also behave differently in regards to the > reflection's strength. In the shader, this happens in line 78: the specular > power is corrected with NTSC_Gray if there is a map (with or without > color), but not if there's only a color. Shouldn't the contributions be the > same? Is the NTSC_Gray correction correct in this case? > > Thanks, > Nir > > [1] https://github.com/openjdk/jfx/pull/787 > [2] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl > From kevin.rushforth at oracle.com Wed Apr 27 00:02:02 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Apr 2022 17:02:02 -0700 Subject: D3D pipeline possible inconsistencies In-Reply-To: References: Message-ID: <119952e5-fadb-baf9-f3a5-7885fae33b77@oracle.com> As you note, there are a few different issues here. To answer your questions as best I can: 1 & 3. We should document that self-illum maps and specular only use the rgb components and that alpha should be ignored. It's possible (although I don't know for sure) that the image is being treated as a non- premultiplied color format, and is subsequently converted to a premultiplied format; if so, this could explain the color darkening. 2. This also needs to be documented. The diffuse component should have an alpha that applies whether from the diffuse color or from a diffuse map. I agree with you that the pixel fragment should not be discarded just because the diffuse component is transparent. A specular highlight should be possible on a fully transparent object. 4. It does seem that the result should be the same regardless of whether the color comes from a specular map or color, but I'd need to dig further. Do all of the above issues happen with the OpenGL shaders, too? -- Kevin On 4/26/2022 11:41 AM, Nir Lisker wrote: > I found a comment [1] on JBS stating that specular and self-Illumination > alphas should be ignored, so it seems like there's at least 2 bugs here > already. > > https://bugs.openjdk.java.net/browse/JDK-8090548?focusedCommentId=13771150&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13771150 > > On Tue, Apr 26, 2022 at 4:25 AM Nir Lisker wrote: > >> Hi, >> >> Using the updated lighting test sample [1], I found some odd behavior with >> regards to PhongMaterial: >> >> 1. The effect of the opacity (alpha channel) of a self-illumination map is >> not documented, but lowering its value makes the object darker. I looked at >> the pixel shader [2] and only the rgb components are sampled, so I'm a bit >> confused here. What is the intended behavior? >> >> 2. The opacity of the object is controlled in the shader by both the >> diffuse color and diffuse map. This is also not documented (although it >> might be obvious for some). In the shader, the pixel (fragment) is >> discarded only if the map is fully transparent (line 55), but not the >> color. This leads to a situation where the object completely disappears >> when the map is transparent, but not when the color is. In the shader, the >> pixel should be transparent because of the multiplication of the alpha, but >> it's not, so this is also confusing. Should they both have the same >> contribution? Shouldn't it be valid to have a transparent diffuse but still >> have specular reflections? >> >> 3. The specular map and color behave differently in regards to the >> opacity. There is no documented behavior here. The alpha on the color is >> ignored (it's used for the specular power), but not on the map - it >> controls the reflection's strength, probably by making its color darker. In >> the shader, lines 76-84 indeed ignore the alpha of the color, but take the >> alpha of the map, although later in line 93 it's not used, so again I'm >> confused. What's the intended behavior? >> >> 4. The specular map and color also behave differently in regards to the >> reflection's strength. In the shader, this happens in line 78: the specular >> power is corrected with NTSC_Gray if there is a map (with or without >> color), but not if there's only a color. Shouldn't the contributions be the >> same? Is the NTSC_Gray correction correct in this case? >> >> Thanks, >> Nir >> >> [1] https://github.com/openjdk/jfx/pull/787 >> [2] >> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl >> From nlisker at gmail.com Wed Apr 27 03:54:19 2022 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 27 Apr 2022 06:54:19 +0300 Subject: Wrong link in README.md? Message-ID: In the README.md, under Issue Tracking, the link to "issues list" leads to the JBS homepage. In CONTRIBUTING.md under Bug Report, the (almost) same paragraph links to the JavaFX filter in JBS, which is a lot more helpful. Shouldn't the link in README also link to the filtered issues list? - Nir From duke at openjdk.java.net Wed Apr 27 07:12:25 2022 From: duke at openjdk.java.net (Fabian Wolter) Date: Wed, 27 Apr 2022 07:12:25 GMT Subject: RFR: 8087370: Fix false detection of multitouch events with some touch controllers Message-ID: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> This fixes JDK-8087370. There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. ------------- Commit messages: - 8087370: Fix false detection of multitouch events with some touch controllers Changes: https://git.openjdk.java.net/jfx/pull/641/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=641&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8087370 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/641/head:pull/641 PR: https://git.openjdk.java.net/jfx/pull/641 From alexsch at openjdk.java.net Wed Apr 27 11:04:55 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 27 Apr 2022 11:04:55 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. The fix #746 for 8282702 also proposes to copy the touch state. The fix makes it in LinuxStatefulMultiTouchProcessor class. Do issues 8087370 and 8282702 have the same root? ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From kevin.rushforth at oracle.com Wed Apr 27 12:15:49 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Apr 2022 05:15:49 -0700 Subject: Wrong link in README.md? In-Reply-To: References: Message-ID: Yes, this seems like a bug. I agree that it would be better for the "issues list" link to use the same filtered list of issues that CONTRIBUTING.md links to. -- Kevin On 4/26/2022 8:54 PM, Nir Lisker wrote: > In the README.md, under Issue Tracking, the link to "issues list" leads to > the JBS homepage. In CONTRIBUTING.md under Bug Report, the (almost) same > paragraph links to the JavaFX filter in JBS, which is a lot more helpful. > Shouldn't the link in README also link to the filtered issues list? > > - Nir From nlisker at gmail.com Wed Apr 27 14:01:41 2022 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 27 Apr 2022 17:01:41 +0300 Subject: Wrong link in README.md? In-Reply-To: References: Message-ID: I created https://github.com/openjdk/jfx/pull/788. By the way, 'openjfx18' version is listed in JBS as unreleased. On Wed, Apr 27, 2022 at 3:16 PM Kevin Rushforth wrote: > Yes, this seems like a bug. I agree that it would be better for the > "issues list" link to use the same filtered list of issues that > CONTRIBUTING.md links to. > > -- Kevin > > > On 4/26/2022 8:54 PM, Nir Lisker wrote: > > In the README.md, under Issue Tracking, the link to "issues list" leads > to > > the JBS homepage. In CONTRIBUTING.md under Bug Report, the (almost) same > > paragraph links to the JavaFX filter in JBS, which is a lot more helpful. > > Shouldn't the link in README also link to the filtered issues list? > > > > - Nir > > From nlisker at openjdk.java.net Wed Apr 27 14:07:23 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 27 Apr 2022 14:07:23 GMT Subject: RFR: 8285725: Wrong link to JBS in README.md Message-ID: Updated the README link to match the CONTRIBUTING link. ------------- Commit messages: - Fixed link Changes: https://git.openjdk.java.net/jfx/pull/788/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=788&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285725 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/788.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/788/head:pull/788 PR: https://git.openjdk.java.net/jfx/pull/788 From kcr at openjdk.java.net Wed Apr 27 14:23:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 27 Apr 2022 14:23:09 GMT Subject: RFR: 8285725: Wrong link to JBS in README.md In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:01:06 GMT, Nir Lisker wrote: > Updated the README link to match the CONTRIBUTING link. Looks good. Thanks for fixing it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/788 From nlisker at openjdk.java.net Wed Apr 27 15:41:46 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 27 Apr 2022 15:41:46 GMT Subject: Integrated: 8285725: Wrong link to JBS in README.md In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:01:06 GMT, Nir Lisker wrote: > Updated the README link to match the CONTRIBUTING link. This pull request has now been integrated. Changeset: d69a498c Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/d69a498c2cde73339bc99e6c02c0d47fe4b1b650 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8285725: Wrong link to JBS in README.md Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/788 From duke at openjdk.java.net Wed Apr 27 16:48:54 2022 From: duke at openjdk.java.net (ea1111) Date: Wed, 27 Apr 2022 16:48:54 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 27 Apr 2022 11:01:46 GMT, Alexander Scherbatiy wrote: >> There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. >> >> The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. >> >> We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. > > The fix #746 for 8282702 also proposes to copy the touch state. The fix makes it in LinuxStatefulMultiTouchProcessor class. > Do issues 8087370 and 8282702 have the same root? @AlexanderScherbatiy I think both issues address the same problem in quite the same way. However, #746 solves the problem only for LinuxStatefulMultiTouchProcessor. This pull request implements the fix more generally in the TouchPipeline so that other touch processors (e. g. LinuxStatelessMultiTouchProcessor and LinuxSimpleTouchProcessor) can also benefit. ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From alexsch at openjdk.java.net Wed Apr 27 17:00:00 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 27 Apr 2022 17:00:00 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. It's sounds reasonable to fix the issue generally on all available touch processors. ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From duke at openjdk.java.net Wed Apr 27 17:21:02 2022 From: duke at openjdk.java.net (Fabian Wolter) Date: Wed, 27 Apr 2022 17:21:02 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: <71eHG3JDLH4j2_Z3mbc-fe4xBG-Vctb-0HmgCq6lXWE=.82bcab36-3a0a-40e0-8cfd-1a29f56d8b09@github.com> On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. Sounds reasonable to me, too. What a coincidence we both filed a PR to fix the same 8-year-old bug, now, after nobody cared for 8 years :) ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From nlisker at openjdk.java.net Thu Apr 28 13:03:46 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 28 Apr 2022 13:03:46 GMT Subject: RFR: 8285534: Update the 3D lighting test sample [v2] In-Reply-To: References: Message-ID: > Update the the test utility. Includes: > * Refactoring since there is no more need the split pre- and post-attenuation and light types. > * Added customizable material to the `Boxes` to test the interaction between lights and materials.. > * Light colors can now be changed. > > Note that GitHub decided to count the removal of the `AttenLightingSample` and addition of the `Controls` file as renaming. The sample is now run now only through `LightingSample`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fix for directional lights not added to scene ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/787/files - new: https://git.openjdk.java.net/jfx/pull/787/files/2f8fdbef..dae9c1d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=787&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=787&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/787.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/787/head:pull/787 PR: https://git.openjdk.java.net/jfx/pull/787 From arapte at openjdk.java.net Thu Apr 28 17:15:27 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:15:27 GMT Subject: [jfx11u] RFR: 8280841: Update SQLite to 3.37.2 Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8280841: Update SQLite to 3.37.2 Changes: https://git.openjdk.java.net/jfx11u/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280841 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod Patch: https://git.openjdk.java.net/jfx11u/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/85/head:pull/85 PR: https://git.openjdk.java.net/jfx11u/pull/85 From arapte at openjdk.java.net Thu Apr 28 17:20:22 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:20:22 GMT Subject: [jfx11u] RFR: 8282134: Certain regex can cause a JS trap in WebView Message-ID: <5Q7_krIVizw8zt8vC6_iOXTmOAzJk7vwLX76Er_MuCo=.76214fd7-e6c4-4dbc-9a41-6c2ec928929b@github.com> Reviewed-by: kcr, arapte ------------- Commit messages: - 8282134: Certain regex can cause a JS trap in WebView Changes: https://git.openjdk.java.net/jfx11u/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=86&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282134 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/86/head:pull/86 PR: https://git.openjdk.java.net/jfx11u/pull/86 From arapte at openjdk.java.net Thu Apr 28 17:24:29 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:24:29 GMT Subject: [jfx11u] RFR: 8278759: PointerEvent: buttons property set to 0 when mouse down Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8278759: PointerEvent: buttons property set to 0 when mouse down Changes: https://git.openjdk.java.net/jfx11u/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=87&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278759 Stats: 302 lines in 8 files changed: 293 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx11u/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/87/head:pull/87 PR: https://git.openjdk.java.net/jfx11u/pull/87 From nlisker at openjdk.java.net Thu Apr 28 17:28:34 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 28 Apr 2022 17:28:34 GMT Subject: RFR: 8285534: Update the 3D lighting test sample [v3] In-Reply-To: References: Message-ID: > Update the the test utility. Includes: > * Refactoring since there is no more need the split pre- and post-attenuation and light types. > * Added customizable material to the `Boxes` to test the interaction between lights and materials.. > * Light colors can now be changed. > > Note that GitHub decided to count the removal of the `AttenLightingSample` and addition of the `Controls` file as renaming. The sample is now run now only through `LightingSample`. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added ambient lights ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/787/files - new: https://git.openjdk.java.net/jfx/pull/787/files/dae9c1d7..cbca5f8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=787&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=787&range=01-02 Stats: 23 lines in 3 files changed: 18 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/787.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/787/head:pull/787 PR: https://git.openjdk.java.net/jfx/pull/787 From arapte at openjdk.java.net Thu Apr 28 17:52:15 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:52:15 GMT Subject: [jfx11u] RFR: 8255940: localStorage is null after window.close() Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8255940: localStorage is null after window.close() Changes: https://git.openjdk.java.net/jfx11u/pull/88/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=88&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255940 Stats: 168 lines in 4 files changed: 167 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/88/head:pull/88 PR: https://git.openjdk.java.net/jfx11u/pull/88 From arapte at openjdk.java.net Thu Apr 28 17:55:14 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:55:14 GMT Subject: [jfx11u] RFR: 8269115: WebView paste event contains old data Message-ID: Reviewed-by: arapte, kcr ------------- Commit messages: - 8269115: WebView paste event contains old data Changes: https://git.openjdk.java.net/jfx11u/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=89&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269115 Stats: 120 lines in 3 files changed: 108 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jfx11u/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/89/head:pull/89 PR: https://git.openjdk.java.net/jfx11u/pull/89 From arapte at openjdk.java.net Thu Apr 28 17:57:25 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:57:25 GMT Subject: [jfx11u] RFR: 8280020: Underline and line-through not straight in WebView Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8280020: Underline and line-through not straight in WebView Changes: https://git.openjdk.java.net/jfx11u/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=90&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280020 Stats: 192 lines in 2 files changed: 182 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jfx11u/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/90/head:pull/90 PR: https://git.openjdk.java.net/jfx11u/pull/90 From arapte at openjdk.java.net Thu Apr 28 17:58:20 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:58:20 GMT Subject: [jfx11u] RFR: 8270867: Debug build of WebKit 613.1 fails on Linux Message-ID: <9rkEzmR20rLU5lycfupUJI4FJ8VEt_ytsQDLOZUDZLY=.08b6dc2c-53ca-4925-a19e-28e9d10f933d@github.com> Reviewed-by: kcr, jbhaskar ------------- Commit messages: - 8270867: Debug build of WebKit 613.1 fails on Linux Changes: https://git.openjdk.java.net/jfx11u/pull/91/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=91&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270867 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/91.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/91/head:pull/91 PR: https://git.openjdk.java.net/jfx11u/pull/91 From arapte at openjdk.java.net Thu Apr 28 17:59:51 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 17:59:51 GMT Subject: [jfx11u] Integrated: 8280841: Update SQLite to 3.37.2 In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:04:37 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 6fe09f46 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/6fe09f4618a6767d323f4c490014a7eea6756da8 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod 8280841: Update SQLite to 3.37.2 Backport-of: 6b7b463cd2286658ad7d236824ded9b1020329e7 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/85 From arapte at openjdk.java.net Thu Apr 28 18:04:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:04:56 GMT Subject: [jfx11u] Integrated: 8282134: Certain regex can cause a JS trap in WebView In-Reply-To: <5Q7_krIVizw8zt8vC6_iOXTmOAzJk7vwLX76Er_MuCo=.76214fd7-e6c4-4dbc-9a41-6c2ec928929b@github.com> References: <5Q7_krIVizw8zt8vC6_iOXTmOAzJk7vwLX76Er_MuCo=.76214fd7-e6c4-4dbc-9a41-6c2ec928929b@github.com> Message-ID: On Thu, 28 Apr 2022 17:13:19 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 3cfee273 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/3cfee27342f3b1fc1b8533823f50ebd9660955e4 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8282134: Certain regex can cause a JS trap in WebView Backport-of: 73963960dc6e56fe34d7aa5fb4ce6f6d2f07acc5 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/86 From arapte at openjdk.java.net Thu Apr 28 18:07:00 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:07:00 GMT Subject: [jfx11u] Integrated: 8278759: PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:16:40 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: c2c62ff4 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/c2c62ff459edded8284c09307fb6d709b54aebef Stats: 302 lines in 8 files changed: 293 ins; 1 del; 8 mod 8278759: PointerEvent: buttons property set to 0 when mouse down Backport-of: 2e8a4a5e97bb88a5807ae5fe075b98e1d54a4ca0 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/87 From arapte at openjdk.java.net Thu Apr 28 18:09:07 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:09:07 GMT Subject: [jfx11u] Integrated: 8255940: localStorage is null after window.close() In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:46:45 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 57e4c94a Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/57e4c94a0bc1a47d2381e86275a7d8a53ce4ce5e Stats: 168 lines in 4 files changed: 167 ins; 0 del; 1 mod 8255940: localStorage is null after window.close() Backport-of: 5112be957be70dd6521e6fb6ee64e669c148729c ------------- PR: https://git.openjdk.java.net/jfx11u/pull/88 From arapte at openjdk.java.net Thu Apr 28 18:10:07 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:10:07 GMT Subject: [jfx11u] Integrated: 8269115: WebView paste event contains old data In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:48:23 GMT, Ambarish Rapte wrote: > Reviewed-by: arapte, kcr This pull request has now been integrated. Changeset: 567685c9 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/567685c9c7bf7d8d779701c6709856be328c1cd4 Stats: 120 lines in 3 files changed: 108 ins; 3 del; 9 mod 8269115: WebView paste event contains old data Backport-of: 2338821bdbb7db929a89aa89903271dcff333a5c ------------- PR: https://git.openjdk.java.net/jfx11u/pull/89 From arapte at openjdk.java.net Thu Apr 28 18:11:04 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:11:04 GMT Subject: [jfx11u] Integrated: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 17:50:08 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 104e7b67 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/104e7b67ed7714cd3c5849d5012f5877ef2f57dc Stats: 192 lines in 2 files changed: 182 ins; 2 del; 8 mod 8280020: Underline and line-through not straight in WebView Backport-of: 263db3df5fdf9e0f6955be6ae58173aa589e55fe ------------- PR: https://git.openjdk.java.net/jfx11u/pull/90 From arapte at openjdk.java.net Thu Apr 28 18:12:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:12:56 GMT Subject: [jfx11u] Integrated: 8270867: Debug build of WebKit 613.1 fails on Linux In-Reply-To: <9rkEzmR20rLU5lycfupUJI4FJ8VEt_ytsQDLOZUDZLY=.08b6dc2c-53ca-4925-a19e-28e9d10f933d@github.com> References: <9rkEzmR20rLU5lycfupUJI4FJ8VEt_ytsQDLOZUDZLY=.08b6dc2c-53ca-4925-a19e-28e9d10f933d@github.com> Message-ID: On Thu, 28 Apr 2022 17:52:40 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, jbhaskar This pull request has now been integrated. Changeset: 8706f989 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/8706f9893a0acd3c07a7f5574e77badeb05deed3 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod 8270867: Debug build of WebKit 613.1 fails on Linux Backport-of: eb7fa5dd1c0911bca15576060691d884d29895a1 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/91 From arapte at openjdk.java.net Thu Apr 28 18:24:23 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:24:23 GMT Subject: [jfx11u] Integrated: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Changes: https://git.openjdk.java.net/jfx11u/pull/92/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=92&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284184 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/92/head:pull/92 PR: https://git.openjdk.java.net/jfx11u/pull/92 From arapte at openjdk.java.net Thu Apr 28 18:24:23 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 28 Apr 2022 18:24:23 GMT Subject: [jfx11u] Integrated: 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 18:12:41 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: f8d4b48b Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/f8d4b48b03e2af4ec1f927448a4cf95303a29a9f Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8284184: Crash in GraphicsContextJava::drawLinesForText on https://us.yahoo.com/ Backport-of: 64da125f05f2a25038ce3370c8fe7c0baf0a354b ------------- PR: https://git.openjdk.java.net/jfx11u/pull/92 From alexsch at openjdk.java.net Fri Apr 29 15:02:59 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 29 Apr 2022 15:02:59 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. The 8087370 includes [LinuxStatefulMultiTouchProcessor-fix-for-1.patch](https://bugs.openjdk.java.net/secure/attachment/50236/LinuxStatefulMultiTouchProcessor-fix-for-1.patch) to fix the first described case: 1. Consider you're touching the screen with two fingers, for example coordinates of one point is ~100,100 and second point is ~200,200. While still touching around the same points some events are reported with one or another point to be either 100,200 or 200,100. Is it reproduced on your system as well? It relates to `8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen` with fix #737 which suggests to not take LinuxInput.ABS_X/Y events into account for non zero slots instead just skipping them for all slots. ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From duke at openjdk.java.net Fri Apr 29 15:34:57 2022 From: duke at openjdk.java.net (Fabian Wolter) Date: Fri, 29 Apr 2022 15:34:57 GMT Subject: RFR: 8087370: [odroid] Monocle: Touch is still broken on Odroid In-Reply-To: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> References: <8r1cERIcJeZVLWYcG3EqWV7zKEoDqtLLgqBVHlPIUyI=.9f7e72c8-de1a-49f6-9df2-8d6a5f46174a@github.com> Message-ID: On Wed, 13 Oct 2021 10:52:40 GMT, Fabian Wolter wrote: > There are sometimes multitouch events detected, when only a single touch should be detected under certain conditions. This lead to touch events on previous touch positions. > > The referenced bug is closed with "won't fix" with the justification it would be platform specific. But this is not correct. It affects all Linux platforms combined with a touch controller, which sends the touch events in an uncommon, but valid(!), order. > > We encountered this problem with the touch controller ILI2511 with firmware V6000_V1 in the Tianma display TM070JVHG33. This patch fixes the problem. It is the same patch attached to above bug report. We didn't encounter the first point in this bug report as our application doesn't make use of multi touch. It was propably not the best idea of the original bug reporter 8 years ago to file two different bugs within the same bug report. Seems like you fixed two bugs which were already about to be fixed nearly a decade ago :/ ------------- PR: https://git.openjdk.java.net/jfx/pull/641 From arapte at openjdk.java.net Fri Apr 29 17:22:23 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:22:23 GMT Subject: [jfx17u] RFR: 8280841: Update SQLite to 3.37.2 Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8280841: Update SQLite to 3.37.2 Changes: https://git.openjdk.java.net/jfx17u/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=42&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280841 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod Patch: https://git.openjdk.java.net/jfx17u/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/42/head:pull/42 PR: https://git.openjdk.java.net/jfx17u/pull/42 From arapte at openjdk.java.net Fri Apr 29 17:26:26 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:26:26 GMT Subject: [jfx17u] RFR: 8270867: Debug build of WebKit 613.1 fails on Linux Message-ID: <0meS5B10zkuVCKFeibITX6n2K3WqC8HLPibHV2GHJz8=.df2cdfed-363d-44cc-ba9e-1da2e43994af@github.com> Reviewed-by: kcr, jbhaskar ------------- Commit messages: - 8270867: Debug build of WebKit 613.1 fails on Linux Changes: https://git.openjdk.java.net/jfx17u/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270867 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/48/head:pull/48 PR: https://git.openjdk.java.net/jfx17u/pull/48 From arapte at openjdk.java.net Fri Apr 29 17:26:32 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:26:32 GMT Subject: [jfx17u] RFR: 8278759: PointerEvent: buttons property set to 0 when mouse down Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8278759: PointerEvent: buttons property set to 0 when mouse down Changes: https://git.openjdk.java.net/jfx17u/pull/44/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=44&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278759 Stats: 302 lines in 8 files changed: 293 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx17u/pull/44.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/44/head:pull/44 PR: https://git.openjdk.java.net/jfx17u/pull/44 From arapte at openjdk.java.net Fri Apr 29 17:26:38 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:26:38 GMT Subject: [jfx17u] RFR: 8282134: Certain regex can cause a JS trap in WebView Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8282134: Certain regex can cause a JS trap in WebView Changes: https://git.openjdk.java.net/jfx17u/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282134 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/43/head:pull/43 PR: https://git.openjdk.java.net/jfx17u/pull/43 From arapte at openjdk.java.net Fri Apr 29 17:26:43 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:26:43 GMT Subject: [jfx17u] RFR: 8269115: WebView paste event contains old data Message-ID: Reviewed-by: arapte, kcr ------------- Commit messages: - 8269115: WebView paste event contains old data Changes: https://git.openjdk.java.net/jfx17u/pull/46/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=46&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269115 Stats: 120 lines in 3 files changed: 108 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jfx17u/pull/46.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/46/head:pull/46 PR: https://git.openjdk.java.net/jfx17u/pull/46 From arapte at openjdk.java.net Fri Apr 29 17:27:21 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:27:21 GMT Subject: [jfx17u] RFR: 8280020: Underline and line-through not straight in WebView Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8280020: Underline and line-through not straight in WebView Changes: https://git.openjdk.java.net/jfx17u/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280020 Stats: 192 lines in 2 files changed: 182 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jfx17u/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/47/head:pull/47 PR: https://git.openjdk.java.net/jfx17u/pull/47 From arapte at openjdk.java.net Fri Apr 29 17:28:32 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 17:28:32 GMT Subject: [jfx17u] RFR: 8255940: localStorage is null after window.close() Message-ID: Reviewed-by: kcr, arapte ------------- Commit messages: - 8255940: localStorage is null after window.close() Changes: https://git.openjdk.java.net/jfx17u/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255940 Stats: 168 lines in 4 files changed: 167 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/45/head:pull/45 PR: https://git.openjdk.java.net/jfx17u/pull/45 From nlisker at gmail.com Fri Apr 29 17:53:02 2022 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 29 Apr 2022 20:53:02 +0300 Subject: D3D pipeline possible inconsistencies In-Reply-To: <119952e5-fadb-baf9-f3a5-7885fae33b77@oracle.com> References: <119952e5-fadb-baf9-f3a5-7885fae33b77@oracle.com> Message-ID: > > It's possible (although > I don't know for sure) that the image is being treated as a non- > premultiplied color format, and is subsequently converted to a > premultiplied format; if so, this could explain the color darkening. The image is constructed with var image = new WritableImage(1, 1); I called image.getPixelWriter().getPixelFormat().getType(); and got BYTE_BGRA_PRE so it's premultiplied. I filed a placeholder JBS issue [1] until it's determined what exactly needs to be fixed. Do all of the above issues happen with the OpenGL shaders, too? I haven't tested yet, but I will. [1] https://bugs.openjdk.java.net/browse/JDK-8285862 On Wed, Apr 27, 2022 at 3:02 AM Kevin Rushforth wrote: > As you note, there are a few different issues here. To answer your > questions as best I can: > > 1 & 3. We should document that self-illum maps and specular only use the > rgb components and that alpha should be ignored. It's possible (although > I don't know for sure) that the image is being treated as a non- > premultiplied color format, and is subsequently converted to a > premultiplied format; if so, this could explain the color darkening. > > 2. This also needs to be documented. The diffuse component should have > an alpha that applies whether from the diffuse color or from a diffuse > map. I agree with you that the pixel fragment should not be discarded > just because the diffuse component is transparent. A specular highlight > should be possible on a fully transparent object. > > 4. It does seem that the result should be the same regardless of whether > the color comes from a specular map or color, but I'd need to dig further. > > Do all of the above issues happen with the OpenGL shaders, too? > > -- Kevin > > > On 4/26/2022 11:41 AM, Nir Lisker wrote: > > I found a comment [1] on JBS stating that specular and self-Illumination > > alphas should be ignored, so it seems like there's at least 2 bugs here > > already. > > > > > https://bugs.openjdk.java.net/browse/JDK-8090548?focusedCommentId=13771150&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13771150 > > > > On Tue, Apr 26, 2022 at 4:25 AM Nir Lisker wrote: > > > >> Hi, > >> > >> Using the updated lighting test sample [1], I found some odd behavior > with > >> regards to PhongMaterial: > >> > >> 1. The effect of the opacity (alpha channel) of a self-illumination map > is > >> not documented, but lowering its value makes the object darker. I > looked at > >> the pixel shader [2] and only the rgb components are sampled, so I'm a > bit > >> confused here. What is the intended behavior? > >> > >> 2. The opacity of the object is controlled in the shader by both the > >> diffuse color and diffuse map. This is also not documented (although it > >> might be obvious for some). In the shader, the pixel (fragment) is > >> discarded only if the map is fully transparent (line 55), but not the > >> color. This leads to a situation where the object completely disappears > >> when the map is transparent, but not when the color is. In the shader, > the > >> pixel should be transparent because of the multiplication of the alpha, > but > >> it's not, so this is also confusing. Should they both have the same > >> contribution? Shouldn't it be valid to have a transparent diffuse but > still > >> have specular reflections? > >> > >> 3. The specular map and color behave differently in regards to the > >> opacity. There is no documented behavior here. The alpha on the color is > >> ignored (it's used for the specular power), but not on the map - it > >> controls the reflection's strength, probably by making its color > darker. In > >> the shader, lines 76-84 indeed ignore the alpha of the color, but take > the > >> alpha of the map, although later in line 93 it's not used, so again I'm > >> confused. What's the intended behavior? > >> > >> 4. The specular map and color also behave differently in regards to the > >> reflection's strength. In the shader, this happens in line 78: the > specular > >> power is corrected with NTSC_Gray if there is a map (with or without > >> color), but not if there's only a color. Shouldn't the contributions be > the > >> same? Is the NTSC_Gray correction correct in this case? > >> > >> Thanks, > >> Nir > >> > >> [1] https://github.com/openjdk/jfx/pull/787 > >> [2] > >> > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1PS.hlsl > >> > > From arapte at openjdk.java.net Fri Apr 29 18:00:47 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 18:00:47 GMT Subject: [jfx17u] Integrated: 8280841: Update SQLite to 3.37.2 In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 16:59:33 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: e05362c9 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/e05362c9b81c91450cf928304ea3c2aefd71017a Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod 8280841: Update SQLite to 3.37.2 Backport-of: 6b7b463cd2286658ad7d236824ded9b1020329e7 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/42 From arapte at openjdk.java.net Fri Apr 29 18:02:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 29 Apr 2022 18:02:56 GMT Subject: [jfx17u] Integrated: 8282134: Certain regex can cause a JS trap in WebView In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 17:04:44 GMT, Ambarish Rapte wrote: > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 350fb532 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx17u/commit/350fb53261e2d51be4ba25f538ad127aa16f6471 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8282134: Certain regex can cause a JS trap in WebView Backport-of: 73963960dc6e56fe34d7aa5fb4ce6f6d2f07acc5 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/43 From kcr at openjdk.java.net Sat Apr 30 13:37:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:37:11 GMT Subject: [jfx11u] RFR: 8280840: Update libFFI to 3.4.2 Message-ID: Clean backport to `jfx11u`. Tested in connection with gstreamer / glib update in the `test-kcr-11.0.16` branch. ------------- Commit messages: - 8280840: Update libFFI to 3.4.2 Changes: https://git.openjdk.java.net/jfx11u/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=93&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280840 Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod Patch: https://git.openjdk.java.net/jfx11u/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/93/head:pull/93 PR: https://git.openjdk.java.net/jfx11u/pull/93 From kcr at openjdk.java.net Sat Apr 30 13:45:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:45:41 GMT Subject: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1 Message-ID: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> Backport to `jfx11u`. Tested in connection with libffi update in the `test-kcr-11.0.16` branch. This was not a clean backport, but the merge conflicts were trivial to resolve. Here is a summary of the changes. The jfx mainline patch applied cleanly to all other files. 1. The following file is not present in jfx11u, so that part of the patch was skipped: modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c 2. The following files had minor merge conflicts, the first was a diff in surrounding context and the rest were in copyright header blocks: modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile modules/javafx.media/src/tools/native/def-glib.pl modules/javafx.media/src/tools/native/def-gstlite.pl ------------- Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx11u/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=94&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38984 lines in 412 files changed: 22060 ins; 5959 del; 10965 mod Patch: https://git.openjdk.java.net/jfx11u/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/94/head:pull/94 PR: https://git.openjdk.java.net/jfx11u/pull/94 From kcr at openjdk.java.net Sat Apr 30 13:45:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:45:41 GMT Subject: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1 In-Reply-To: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> References: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> Message-ID: On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to resolve. Here is a summary of the changes. The jfx mainline patch applied cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl Reviewer: @johanvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/94 From kcr at openjdk.java.net Sat Apr 30 13:46:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:46:10 GMT Subject: [jfx11u] RFR: 8281564: Update cmake to 3.22.3 Message-ID: Simple backport to `jfx11u`. It isn't a clean backport since the mainline patch had an update to `gradle/verification-metadata.xml`, which doesn't exist in 11. ------------- Commit messages: - 8281564: Update cmake to 3.22.3 Changes: https://git.openjdk.java.net/jfx11u/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=95&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281564 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/95/head:pull/95 PR: https://git.openjdk.java.net/jfx11u/pull/95 From kcr at openjdk.java.net Sat Apr 30 13:46:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:46:11 GMT Subject: [jfx11u] RFR: 8281564: Update cmake to 3.22.3 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 13:39:32 GMT, Kevin Rushforth wrote: > Simple backport to `jfx11u`. It isn't a clean backport since the mainline patch had an update to `gradle/verification-metadata.xml`, which doesn't exist in 11. Reviewer: @arapte ------------- PR: https://git.openjdk.java.net/jfx11u/pull/95 From kcr at openjdk.java.net Sat Apr 30 13:49:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:49:13 GMT Subject: [jfx11u] RFR: 8276142: Update gradle to version 7.3 Message-ID: <7Jv27rURbjBJvK3Odtbj39CU-72-UF5kJZnT1WctI4s=.d2a78fda-b109-4b2c-a56f-9b5155aad1da@github.com> Clean backport to `jfx11u`. ------------- Commit messages: - 8276142: Update gradle to version 7.3 Changes: https://git.openjdk.java.net/jfx11u/pull/96/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=96&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276142 Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod Patch: https://git.openjdk.java.net/jfx11u/pull/96.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/96/head:pull/96 PR: https://git.openjdk.java.net/jfx11u/pull/96 From kcr at openjdk.java.net Sat Apr 30 13:52:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:52:08 GMT Subject: [jfx11u] RFR: 8274274: Update JUnit to version 5.8.1 Message-ID: Nearly clean backport to `jfx11u`. It isn't a clean backport since the mainline patch updated `gradle/verification-metadata.xml`, which doesn't exist in 11. ------------- Commit messages: - 8274274: Update JUnit to version 5.8.1 Changes: https://git.openjdk.java.net/jfx11u/pull/97/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=97&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274274 Stats: 63 lines in 4 files changed: 58 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/97.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/97/head:pull/97 PR: https://git.openjdk.java.net/jfx11u/pull/97 From kcr at openjdk.java.net Sat Apr 30 13:52:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:52:08 GMT Subject: [jfx11u] RFR: 8274274: Update JUnit to version 5.8.1 In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 13:45:39 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u`. It isn't a clean backport since the mainline patch updated `gradle/verification-metadata.xml`, which doesn't exist in 11. Reviewer: @arapte ------------- PR: https://git.openjdk.java.net/jfx11u/pull/97 From kcr at openjdk.java.net Sat Apr 30 13:55:24 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:55:24 GMT Subject: [jfx11u] RFR: 8273998: Clarify specification for Window properties controlled by the window manager Message-ID: Clean backport to `jfx11u`. ------------- Commit messages: - 8273998: Clarify specification for Window properties controlled by the window manager Changes: https://git.openjdk.java.net/jfx11u/pull/99/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=99&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273998 Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod Patch: https://git.openjdk.java.net/jfx11u/pull/99.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/99/head:pull/99 PR: https://git.openjdk.java.net/jfx11u/pull/99 From kcr at openjdk.java.net Sat Apr 30 13:57:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:57:09 GMT Subject: [jfx11u] RFR: 8276174: JavaFX build fails on macOS aarch64 Message-ID: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> Backport to `jfx11u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. It isn't a clean backport, since I also had to include the definition of `IS_AARCH64` which is present in mainline, but not in `jfx11u` (it was added as part of another unrelated fix that isn't backported to `jfx11u`). ------------- Commit messages: - 8276174: JavaFX build fails on macOS aarch64 Changes: https://git.openjdk.java.net/jfx11u/pull/100/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=100&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276174 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/100.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/100/head:pull/100 PR: https://git.openjdk.java.net/jfx11u/pull/100 From kcr at openjdk.java.net Sat Apr 30 13:57:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 13:57:10 GMT Subject: [jfx11u] RFR: 8276174: JavaFX build fails on macOS aarch64 In-Reply-To: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> References: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> Message-ID: On Sat, 30 Apr 2022 13:51:23 GMT, Kevin Rushforth wrote: > Backport to `jfx11u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. It isn't a clean backport, since I also had to include the definition of `IS_AARCH64` which is present in mainline, but not in `jfx11u` (it was added as part of another unrelated fix that isn't backported to `jfx11u`). Reviewer: @johanvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/100 From kcr at openjdk.java.net Sat Apr 30 14:10:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 14:10:46 GMT Subject: [jfx11u] Integrated: 8273998: Clarify specification for Window properties controlled by the window manager In-Reply-To: References: Message-ID: <0N6vy_-ye7ASWdIB1UW3a_qtx4ydCQkuznAzwSXBvVA=.95fc3cd3-e6f3-4989-9efd-90ccf898ea2a@github.com> On Sat, 30 Apr 2022 13:48:57 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: 1e62db92 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/1e62db92944c545cc7dd333652819be1c50896ff Stats: 84 lines in 2 files changed: 59 ins; 4 del; 21 mod 8273998: Clarify specification for Window properties controlled by the window manager Backport-of: 7a1a19c098e21572077c9c3d75cc2141fadc99f6 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/99 From kcr at openjdk.java.net Sat Apr 30 14:11:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 30 Apr 2022 14:11:54 GMT Subject: [jfx11u] Integrated: 8276142: Update gradle to version 7.3 In-Reply-To: <7Jv27rURbjBJvK3Odtbj39CU-72-UF5kJZnT1WctI4s=.d2a78fda-b109-4b2c-a56f-9b5155aad1da@github.com> References: <7Jv27rURbjBJvK3Odtbj39CU-72-UF5kJZnT1WctI4s=.d2a78fda-b109-4b2c-a56f-9b5155aad1da@github.com> Message-ID: <5baU5Vskyrduznpynvyrpze9EufSBFHWicj86ux4R84=.0cb322fb-5471-443b-9a95-c52d13b16c04@github.com> On Sat, 30 Apr 2022 13:43:09 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: e92f7fcd Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/e92f7fcd4f9e9bc89c91b06b1c7fa8296c4902bb Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod 8276142: Update gradle to version 7.3 Backport-of: 13c24d22463436bc953ec5159beec7a78017019f ------------- PR: https://git.openjdk.java.net/jfx11u/pull/96 From jvos at openjdk.java.net Sat Apr 30 17:17:38 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 30 Apr 2022 17:17:38 GMT Subject: [jfx11u] RFR: 8276174: JavaFX build fails on macOS aarch64 In-Reply-To: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> References: <8JuLLVSlPMkKqM35Vhwyj1CXbI0X2wCfmDysH2z_RYw=.c47aa197-04f0-428e-9dd6-55228935983a@github.com> Message-ID: <66mq8uze7WsEDjxnvEcGb9ot6rMvC8XGQs10LJyiwRI=.646a6be1-221f-43a8-8863-1436bb5f00a6@github.com> On Sat, 30 Apr 2022 13:51:23 GMT, Kevin Rushforth wrote: > Backport to `jfx11u` so we can build on macOS / aarch64 without needing to specify `-PCOMPILE_TARGET=arm64`. It isn't a clean backport, since I also had to include the definition of `IS_AARCH64` which is present in mainline, but not in `jfx11u` (it was added as part of another unrelated fix that isn't backported to `jfx11u`). Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/100 From jvos at openjdk.java.net Sat Apr 30 18:38:48 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 30 Apr 2022 18:38:48 GMT Subject: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1 In-Reply-To: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> References: <-uIlyw7rSlwjLvHKqEH5GcO323mjO82C3r9uWHztGRI=.35e628ce-ec14-42a3-88a1-ada480236dfd@github.com> Message-ID: On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to resolve. Here is a summary of the changes. The jfx mainline patch applied cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/94 From jvos at openjdk.java.net Sat Apr 30 18:51:10 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 30 Apr 2022 18:51:10 GMT Subject: [jfx17u] RFR: 8274137: TableView scrollbar/header misaligned when reloading data Message-ID: Reviewed-by: kcr, aghaisas ------------- Commit messages: - 8274137: TableView scrollbar/header misaligned when reloading data Changes: https://git.openjdk.java.net/jfx17u/pull/49/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=49&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274137 Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/49/head:pull/49 PR: https://git.openjdk.java.net/jfx17u/pull/49 From jvos at openjdk.java.net Sat Apr 30 18:54:15 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 30 Apr 2022 18:54:15 GMT Subject: [jfx17u] RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Message-ID: Reviewed-by: kcr, mstrauss ------------- Commit messages: - 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Changes: https://git.openjdk.java.net/jfx17u/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276553 Stats: 29 lines in 5 files changed: 19 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jfx17u/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/50/head:pull/50 PR: https://git.openjdk.java.net/jfx17u/pull/50