From hjohn at xs4all.nl Mon Mar 1 13:01:21 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 1 Mar 2021 14:01:21 +0100 Subject: font color fringes on macOS, not a priority? In-Reply-To: References: Message-ID: <7235fab8-f145-859d-868b-687bae47cbae@xs4all.nl> Not a solution to the problem (the color fringes on Mac apparently are using almost fully saturated subpixels which seems like a serious issue), but I see color fringes on most screens so I always just turn this type of rendering off. It obviously depends on the pixel density though as higher resolution 4k+ screens make the colored fringes less obvious. Have you tried to simply turn subpixel rendering off as a temporary solution? System.setProperty("prism.lcdtext", "false") --John On 25/02/2021 15:18, Rob Nikander wrote: > Hi, > > Last year, I wanted to use JavaFX for a project, but did not because the font rendering on macOS looked bad compared to native apps. I was following this bug: https://bugs.openjdk.java.net/browse/JDK-8236689 . It was created over a year ago and recently its ?Fix version" was pushed back from 16 to 17. > > The way that bug is titled (?non-retina?) makes me wonder: do people realize that this is effecting even retina screens on macOS? I have a 2020 MacBook Pro and the JavaFX fonts have color fringes. > > I?d like to write a cross platform desktop app, but I need the text rendering to be as good as native. Maybe time to give up and write some Swift code, or a web app (ugh). > > Rob > From ebresie at gmail.com Mon Mar 1 13:31:29 2021 From: ebresie at gmail.com (Eric Bresie) Date: Mon, 1 Mar 2021 07:31:29 -0600 Subject: font color fringes on macOS, not a priority? In-Reply-To: 6d813790-a02c-bca8-7bb8-7db3af07a021@oracle.com References: DE12503B-0782-4035-8F1C-FA267CF7EF6D@gmail.com e39d5399-64f1-02fb-7bb3-435f7c1dd093@status6.com 5505E5E3-1166-4889-AF93-211CA43E9548@gmail.com edb96b9e-9a4b-dbc0-3b73-d739a1eaacd9@status6.com edb96b9e-9a4b-dbc0-3b73-d739a1eaacd9@status6.com Message-ID: Just curious...while reading up on the below Metal API / MacOS OpenGL depreciation, I notice reference to coming changes with OpenGL relating to transition to ?Vulkan? which if I understand correctly may be a similar change in lower level graphics API (I think similar to Metal). Will updated to JFX with something similar eventually also be needed there as well? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On February 26, 2021 at 12:02:11 PM CST, Kevin Rushforth wrote: > Part of that 11+ minutes of the macOS build on GitHub Actions (which > starts from a clean machine) is downloading and installing the JDK and > other tools (gradle, etc), and cloning the repo. Also, incremental > builds are much faster after the first one. So even if you do a full > build once, subsequent builds for the debug-edit-build cycle is pretty > quick. > > Phil might want to comment about the possibility of eliminating > sub-pixel (LCD) text entirely on macOS. If it does turn out to be > something worth doing, I note that macOS 10.13 is pretty old by now, so > that wouldn't be a compelling reason to hold off (as long as it doesn't > regress horribly). > > As for Project Lanai, that isn't related to this issue. Lanai is an > implementation of the Java2D back end on Apple's Metal API (as an > alternative to OpenGL). See JEP 382 [1] for more information. We will > very likely do the same for FX starting in the not-too-distant future. > > -- Kevin > > [1] https://openjdk.java.net/jeps/382 > > > On 2/26/2021 9:39 AM, John Neffenger wrote: > > On 2/26/21 6:56 AM, Rob Nikander wrote: > > > I wonder if I can get a dev setup with a quick edit-compile-run > > > cycle, or if the compile step takes a long time. > > > > The builds for macOS are taking just over 11 minutes on GitHub. > > > > To speed that up, I do my development in a project with only the > > JavaFX Graphics module, linked below, and then use a guest machine to > > do a full build for amd64 and armhf. Things go pretty quickly with the > > help of 'rsync'. Not sure whether the same setup would help on macOS. > > > > JavaFX Graphics > > https://github.com/jgneff/javafx-graphics > > > > > Do you know if the color fringes are being produced by the Core Text > > > rendering to a bitmap, and not the subsequent OpenGL phase? > > > > No, I don't. I also don't know how the JavaFX code for macOS relates > > to what's going on with the Lanai Project: > > > > Lanai Project > > https://wiki.openjdk.java.net/display/lanai/Main > > > > Regarding my suggestion of removing the sub-pixel rendering, it would > > be good to check how many Macs out there are still running on macOS > > 10.13 High Sierra and earlier. Apple removed its sub-pixel rendering > > and switched to grayscale anti-aliasing in macOS 10.14 Mojave. > > > > John > From rob.nikander at gmail.com Mon Mar 1 13:35:50 2021 From: rob.nikander at gmail.com (Rob Nikander) Date: Mon, 1 Mar 2021 07:35:50 -0600 Subject: font color fringes on macOS, not a priority? In-Reply-To: <7235fab8-f145-859d-868b-687bae47cbae@xs4all.nl> References: <7235fab8-f145-859d-868b-687bae47cbae@xs4all.nl> Message-ID: <80356A8D-1C91-4D43-98EA-244FE75EF561@gmail.com> > On Mar 1, 2021, at 7:01 AM, John Hendrikx wrote: > > Not a solution to the problem (the color fringes on Mac apparently are using almost fully saturated subpixels which seems like a serious issue), but I see color fringes on most screens so I always just turn this type of rendering off. It obviously depends on the pixel density though as higher resolution 4k+ screens make the colored fringes less obvious. > > Have you tried to simply turn subpixel rendering off as a temporary solution? > > System.setProperty("prism.lcdtext", "false?) Thanks, that helps. It stopped the color fringes on my MacBook Pro retina screen, but doesn?t cure all the font problems. The glyphs are still too close together compared to the text in native apps. From kevin.rushforth at oracle.com Mon Mar 1 16:26:11 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Mar 2021 08:26:11 -0800 Subject: Request to backport 2 fixes to 11-dev for 11.0.11 Message-ID: <4dfda216-2b76-e67a-edd4-e45831895fba@oracle.com> Hi Johan, I request approval to backport the following 2 bug fixes to 11-dev for FX 11.0.11: JDK-8260257: [Linux] WebView no longer reacts to some mouse events JDK-8260165: CSSFilterTest.testCSSFilterRendering system test fails Thanks. -- Kevin From johan.vos at gluonhq.com Mon Mar 1 20:12:51 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 1 Mar 2021 21:12:51 +0100 Subject: Request to backport 2 fixes to 11-dev for 11.0.11 In-Reply-To: <4dfda216-2b76-e67a-edd4-e45831895fba@oracle.com> References: <4dfda216-2b76-e67a-edd4-e45831895fba@oracle.com> Message-ID: Approved On Mon, Mar 1, 2021 at 5:26 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following 2 bug fixes to 11-dev for > FX 11.0.11: > > JDK-8260257: [Linux] WebView no longer reacts to some mouse events > JDK-8260165: CSSFilterTest.testCSSFilterRendering system test fails > > Thanks. > > -- Kevin > > From johan.vos at gluonhq.com Tue Mar 2 12:53:11 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 2 Mar 2021 13:53:11 +0100 Subject: Request to backport 7 fixes to 11-dev for 11.0.11 Message-ID: Hi Kevin, I request permission to backport the following issues to 11-dev, for the 11.0.11 release: JDK-8258592: Control labels in Dialogs are truncated at certain DPI scaling levels JDK-8256283: IndexOutOfBoundsException when sorting a TreeTableView JDK-8165749: java.lang.RuntimeException: dndGesture.dragboard is null in drag JDK-8249737: java.lang.RuntimeException: Too many touch points reported JDK-8252099: JavaFX does not render Myanmar script correctly JDK-8261460: Incorrect CSS applied to ContextMenu on DialogPane JDK-8248126: JavaFX ignores HiDPI scaling settings on some linux platforms - Johan From kevin.rushforth at oracle.com Tue Mar 2 13:04:15 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 2 Mar 2021 05:04:15 -0800 Subject: Request to backport 7 fixes to 11-dev for 11.0.11 In-Reply-To: References: Message-ID: <4de7d671-0158-c7dd-a1b7-d4065572bf47@oracle.com> Approved. -- Kevin On 3/2/2021 4:53 AM, Johan Vos wrote: > Hi Kevin, > > > I request permission to backport the following issues to 11-dev, for the > 11.0.11 release: > > > JDK-8258592: Control labels in Dialogs are truncated at certain DPI scaling > levels > > JDK-8256283: IndexOutOfBoundsException when sorting a TreeTableView > > JDK-8165749: java.lang.RuntimeException: dndGesture.dragboard is null in > drag > > JDK-8249737: java.lang.RuntimeException: Too many touch points reported > > JDK-8252099: JavaFX does not render Myanmar script correctly > > JDK-8261460: Incorrect CSS applied to ContextMenu on DialogPane > > JDK-8248126: JavaFX ignores HiDPI scaling settings on some linux platforms > > > - Johan From fastegal at swingempire.de Tue Mar 2 13:37:51 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 02 Mar 2021 14:37:51 +0100 Subject: Eclipse problem: not compiling module projects Message-ID: <20210302143751.Horde.lk0y4PTv4Fwknhfk1KQFRA1@webmail.df.eu> Just a quick question to Eclipse users (who do compile with Eclipse, not with gradle) Problem: updated my Eclipse to the december release yesterday, now it doesn't compile (neither automatically, nor forcing a clean build) anything as soon as the module projects are included, neither the modules nor dependent projects - nothing else changed (hopefully ;). All fine when adding the compiled module-jars. Questions: - anybody else seeing it? - any ideas where to look? -- Jeanette From tom.schindl at bestsolution.at Tue Mar 2 13:43:50 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 2 Mar 2021 14:43:50 +0100 Subject: Eclipse problem: not compiling module projects In-Reply-To: <20210302143751.Horde.lk0y4PTv4Fwknhfk1KQFRA1@webmail.df.eu> References: <20210302143751.Horde.lk0y4PTv4Fwknhfk1KQFRA1@webmail.df.eu> Message-ID: I setup everything from scratch a few weeks ago and all worked fine: * I first run the gradle build * then imported everything into Eclipse Tom Am 02.03.21 um 14:37 schrieb Jeanette Winzenburg: > > Just a quick question to Eclipse users (who do compile with Eclipse, not > with gradle) > > Problem: > > updated my Eclipse to the december release yesterday, now it doesn't > compile (neither automatically, nor forcing a clean build) anything as > soon as the module projects are included, neither the modules nor > dependent projects - nothing else changed (hopefully ;). All fine when > adding the compiled module-jars. > > Questions: > > - anybody else seeing it? > - any ideas where to look? > > -- Jeanette > > > > From fastegal at swingempire.de Tue Mar 2 13:48:09 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 02 Mar 2021 14:48:09 +0100 Subject: Eclipse problem: not compiling module projects In-Reply-To: References: <20210302143751.Horde.lk0y4PTv4Fwknhfk1KQFRA1@webmail.df.eu> Message-ID: <20210302144809.Horde.mHk-RW6aZJLLKFyV1LS0DA1@webmail.df.eu> "from scratch" are the words I feared to hear ;) Probably no way around, thanks Tom! Zitat von Tom Schindl : > I setup everything from scratch a few weeks ago and all worked fine: > * I first run the gradle build > * then imported everything into Eclipse > > Tom > > Am 02.03.21 um 14:37 schrieb Jeanette Winzenburg: >> >> Just a quick question to Eclipse users (who do compile with >> Eclipse, not with gradle) >> >> Problem: >> >> updated my Eclipse to the december release yesterday, now it >> doesn't compile (neither automatically, nor forcing a clean build) >> anything as soon as the module projects are included, neither the >> modules nor dependent projects - nothing else changed (hopefully >> ;). All fine when adding the compiled module-jars. >> >> Questions: >> >> - anybody else seeing it? >> - any ideas where to look? >> >> -- Jeanette >> >> >> >> From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Mar 2 18:29:55 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 2 Mar 2021 18:29:55 GMT Subject: RFR: 8262460: Create release notes for JavaFX 16 Message-ID: Add release notes for JavaFX 16 to the repository ------------- Commit messages: - 8262460: Create release notes for JavaFX 16 Changes: https://git.openjdk.java.net/jfx/pull/414/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262460 Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/414.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/414/head:pull/414 PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Mar 2 18:54:27 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 2 Mar 2021 18:54:27 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: Message-ID: > Add release notes for JavaFX 16 to the repository Abhinay Agarwal 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 27 additional commits since the last revision: - 8262460: Create release notes for JavaFX 16 - 8260165: CSSFilterTest.testCSSFilterRendering system test fails Reviewed-by: kcr, ghb - 8260257: [Linux] WebView no longer reacts to some mouse events Reviewed-by: kcr, jvos - 8262236: Configure Gradle checksum verification Reviewed-by: kcr - 8260468: Wrong behavior of LocalDateTimeStringConverter Reviewed-by: kcr, pbansal - 8261927: WebKit build fails with Visual Studio 2017 Reviewed-by: kcr, ghb - 8252935: Add treeShowing listener only when needed Reviewed-by: kcr, arapte - 8261460: Incorrect CSS applied to ContextMenu on DialogPane Reviewed-by: kcr, aghaisas - 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms Reviewed-by: kcr, arapte - 8252099: JavaFX does not render Myanmar script correctly Reviewed-by: prr - ... and 17 more: https://git.openjdk.java.net/jfx/compare/f3241470...5e75b332 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/414/files - new: https://git.openjdk.java.net/jfx/pull/414/files/5e75b332..5e75b332 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/414.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/414/head:pull/414 PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Tue Mar 2 18:54:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Mar 2021 18:54:29 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 18:25:14 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 16 to the repository The target branch should be changed to `jfx16` ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Tue Mar 2 18:54:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Mar 2021 18:54:29 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 18:48:10 GMT, Kevin Rushforth wrote: >> Add release notes for JavaFX 16 to the repository > > The target branch should be changed to `jfx16` And this means you will need to rebase on top of `jfx16`, so that it doesn't bring in commits from master. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Mar 2 19:12:39 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 2 Mar 2021 19:12:39 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: > Add release notes for JavaFX 16 to the repository Abhinay Agarwal has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8262460: Create release notes for JavaFX 16 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/414/files - new: https://git.openjdk.java.net/jfx/pull/414/files/5e75b332..1b5159ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=01-02 Stats: 273170 lines in 5576 files changed: 105839 ins; 127444 del; 39887 mod Patch: https://git.openjdk.java.net/jfx/pull/414.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/414/head:pull/414 PR: https://git.openjdk.java.net/jfx/pull/414 From nlisker at openjdk.java.net Tue Mar 2 19:16:40 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 2 Mar 2021 19:16:40 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: Message-ID: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> On Tue, 2 Mar 2021 18:54:27 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 16 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. Changes requested by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From nlisker at openjdk.java.net Tue Mar 2 19:16:42 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 2 Mar 2021 19:16:42 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:12:39 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 16 to the repository > > Abhinay Agarwal has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. doc-files/release-notes-16.md line 20: > 18: [JDK-8176270](https://bugs.openjdk.java.net/browse/JDK-8176270)|Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException|controls > 19: [JDK-8255415](https://bugs.openjdk.java.net/browse/JDK-8255415)|Nested calls to snap methods in Region give different results|graphics > 20: [JDK-8246343](https://bugs.openjdk.java.net/browse/JDK-8246343)|Fix mistakes in FX API docs|other This one is from an older version. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Mar 2 19:21:42 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 2 Mar 2021 19:21:42 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:00:07 GMT, Nir Lisker wrote: >> Abhinay Agarwal has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > doc-files/release-notes-16.md line 20: > >> 18: [JDK-8176270](https://bugs.openjdk.java.net/browse/JDK-8176270)|Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException|controls >> 19: [JDK-8255415](https://bugs.openjdk.java.net/browse/JDK-8255415)|Nested calls to snap methods in Region give different results|graphics >> 20: [JDK-8246343](https://bugs.openjdk.java.net/browse/JDK-8246343)|Fix mistakes in FX API docs|other > > This one is from an older version. All original issues are added to the Release Notes if an issue is a backport issue. It seems like there is backport issue against JDK-8246343 with fix version `openjfx16`. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From jvos at openjdk.java.net Tue Mar 2 19:44:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 2 Mar 2021 19:44:39 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:18:33 GMT, Abhinay Agarwal wrote: >> doc-files/release-notes-16.md line 20: >> >>> 18: [JDK-8176270](https://bugs.openjdk.java.net/browse/JDK-8176270)|Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException|controls >>> 19: [JDK-8255415](https://bugs.openjdk.java.net/browse/JDK-8255415)|Nested calls to snap methods in Region give different results|graphics >>> 20: [JDK-8246343](https://bugs.openjdk.java.net/browse/JDK-8246343)|Fix mistakes in FX API docs|other >> >> This one is from an older version. > > All original issues are added to the Release Notes if an issue is a backport issue. It seems like there is backport issue against JDK-8246343 with fix version `openjfx16`. There are some "backport" issues that are sort of forward ported but still have type backport. For example, issues fixed in 15.0.1 are "backported" to 16. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Tue Mar 2 19:55:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Mar 2021 19:55:39 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: On Tue, 2 Mar 2021 19:41:45 GMT, Johan Vos wrote: >> All original issues are added to the Release Notes if an issue is a backport issue. It seems like there is backport issue against JDK-8246343 with fix version `openjfx16`. > > There are some "backport" issues that are sort of forward ported but still have type backport. For example, issues fixed in 15.0.1 are "backported" to 16. There are issues in 15 with a backport to 16. I'd be surprised if that were the case for 15.0.1 (and if so, they would still be in the release notes for 16 if they didn't ship with 15 GA). https://bugs.openjdk.java.net/browse/JDK-8246343 is the case of a bug that was fixed in 15 and then synced into mainline for 16. So it should be ignored. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From jvos at openjdk.java.net Tue Mar 2 20:09:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 2 Mar 2021 20:09:45 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: References: Message-ID: <_5Gv4dHqP3BUTXFbZXXG1eabxy-t79GWpJV4xZnR84w=.10300e74-808d-4e0d-91ac-aa14757ea103@github.com> On Tue, 2 Mar 2021 19:52:31 GMT, Kevin Rushforth wrote: >> There are some "backport" issues that are sort of forward ported but still have type backport. For example, issues fixed in 15.0.1 are "backported" to 16. > > There are issues in 15 with a backport to 16. I'd be surprised if that were the case for 15.0.1 (and if so, they would still be in the release notes for 16 if they didn't ship with 15 GA). > > https://bugs.openjdk.java.net/browse/JDK-8246343 is the case of a bug that was fixed in 15 and then synced into mainline for 16. So it should be ignored. Right, I was confused when I saw the tag 15.0.1+0 but it is indeed in 15. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Tue Mar 2 20:20:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Mar 2021 20:20:43 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: On Tue, 2 Mar 2021 19:14:24 GMT, Nir Lisker wrote: >> Abhinay Agarwal has updated the pull request with a new target base due to a merge or a rebase. > > Changes requested by nlisker (Reviewer). A couple other comments: 1. Previous release notes were sorted first by subcomponent and then by bug ID. You might consider whether to do that again for 16? 2. The following bug was called out during the CSR as needing a release note to highlight the new log warning: [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362): JavaFX must warn when the javafx.* modules are loaded from the classpath I think I'm on the hook for that one, so I can provide you the proposed text later today, in case you want to include it. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Mar 3 07:52:06 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 3 Mar 2021 07:52:06 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v4] In-Reply-To: References: Message-ID: > Add release notes for JavaFX 16 to the repository Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: 8262460: Sort issues first by sub-component followed by bug id ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/414/files - new: https://git.openjdk.java.net/jfx/pull/414/files/1b5159ae..8eaa45f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=02-03 Stats: 108 lines in 1 file changed: 29 ins; 39 del; 40 mod Patch: https://git.openjdk.java.net/jfx/pull/414.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/414/head:pull/414 PR: https://git.openjdk.java.net/jfx/pull/414 From tsayao at openjdk.java.net Wed Mar 3 12:18:06 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 12:18:06 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v14] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Hopefully fix all "extra resize" problems due to frame extents. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/0c89a4da..5f8d7731 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=12-13 Stats: 51 lines in 2 files changed: 14 ins; 22 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Wed Mar 3 12:18:07 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 12:18:07 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Thu, 18 Feb 2021 21:24:31 GMT, Thiago Milczarek Sayao wrote: >> Current Status: >> >> ![image](https://user-images.githubusercontent.com/30704286/108422319-2aa0e800-7215-11eb-8b9e-8f62e7f8d553.png) > > Ready to be reviewed. Changed to WIP while we run some more tests to make sure latest changes are ok. I'm fixing some residual "extra resize" issues (these issues exists on the current versions, so this makes it better, hopefully). ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Wed Mar 3 12:23:05 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 12:23:05 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v15] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Small change to reuse get_net_frame_extents_atom() ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/5f8d7731..0de9fc96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=13-14 Stats: 13 lines in 1 file changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Wed Mar 3 12:50:07 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 12:50:07 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v16] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix more tests (restore 1 behaviour) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/0de9fc96..41f48dc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=14-15 Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Wed Mar 3 13:00:03 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 13:00:03 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v17] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: More test fixes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/41f48dc2..1d085aad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=15-16 Stats: 12 lines in 2 files changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From nlisker at openjdk.java.net Wed Mar 3 13:12:48 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 3 Mar 2021 13:12:48 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: <_5Gv4dHqP3BUTXFbZXXG1eabxy-t79GWpJV4xZnR84w=.10300e74-808d-4e0d-91ac-aa14757ea103@github.com> References: <_5Gv4dHqP3BUTXFbZXXG1eabxy-t79GWpJV4xZnR84w=.10300e74-808d-4e0d-91ac-aa14757ea103@github.com> Message-ID: <0DKASgnBC01dLIhzW9Q7AUalmteocUpvRBRs2PISJjY=.9b2293ac-0fd7-4ef7-bf08-1860860116ba@github.com> On Tue, 2 Mar 2021 20:06:33 GMT, Johan Vos wrote: >> There are issues in 15 with a backport to 16. I'd be surprised if that were the case for 15.0.1 (and if so, they would still be in the release notes for 16 if they didn't ship with 15 GA). >> >> https://bugs.openjdk.java.net/browse/JDK-8246343 is the case of a bug that was fixed in 15 and then synced into mainline for 16. So it should be ignored. > > Right, I was confused when I saw the tag 15.0.1+0 but it is indeed in 15. There might be other issues like that. Maybe the backport issue type should be filtered. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Mar 3 13:15:41 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 3 Mar 2021 13:15:41 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v3] In-Reply-To: <0DKASgnBC01dLIhzW9Q7AUalmteocUpvRBRs2PISJjY=.9b2293ac-0fd7-4ef7-bf08-1860860116ba@github.com> References: <_5Gv4dHqP3BUTXFbZXXG1eabxy-t79GWpJV4xZnR84w=.10300e74-808d-4e0d-91ac-aa14757ea103@github.com> <0DKASgnBC01dLIhzW9Q7AUalmteocUpvRBRs2PISJjY=.9b2293ac-0fd7-4ef7-bf08-1860860116ba@github.com> Message-ID: On Wed, 3 Mar 2021 13:09:51 GMT, Nir Lisker wrote: >> Right, I was confused when I saw the tag 15.0.1+0 but it is indeed in 15. > > There might be other issues like that. Maybe the backport issue type should be filtered. This has already been taken care of. I have removed all the issues which were already shipped with 15GA and then backported to 16. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 13:23:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 13:23:44 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: On Tue, 2 Mar 2021 20:17:59 GMT, Kevin Rushforth wrote: >> Changes requested by nlisker (Reviewer). > > A couple other comments: > > 1. Previous release notes were sorted first by subcomponent and then by bug ID. You might consider whether to do that again for 16? > 2. The following bug was called out during the CSR as needing a release note to highlight the new log warning: > [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362): JavaFX must warn when the javafx.* modules are loaded from the classpath > I think I'm on the hook for that one, so I can provide you the proposed text later today, in case you want to include it. For the last couple releases, I generated the list of bugs to add to release notes, and yes, I typically exclude backports for that reason (it isn't perfect, but it also excludes the issues labeled with the `hgupdate-sync` label, which can be added to indicate an issue synced in from a prior release). Here is the same filter I used in the past, updated for JavaFX 16 for comparison: https://bugs.openjdk.java.net/issues/?filter=40381 You'll notice that it excludes test bugs and build issue (so the "GitHub Actions" bugs don't show up, for example) ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 14:15:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 14:15:47 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: On Wed, 3 Mar 2021 13:21:06 GMT, Kevin Rushforth wrote: >> A couple other comments: >> >> 1. Previous release notes were sorted first by subcomponent and then by bug ID. You might consider whether to do that again for 16? >> 2. The following bug was called out during the CSR as needing a release note to highlight the new log warning: >> [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362): JavaFX must warn when the javafx.* modules are loaded from the classpath >> I think I'm on the hook for that one, so I can provide you the proposed text later today, in case you want to include it. > > For the last couple releases, I generated the list of bugs to add to release notes, and yes, I typically exclude backports for that reason (it isn't perfect, but it also excludes the issues labeled with the `hgupdate-sync` label, which can be added to indicate an issue synced in from a prior release). > > Here is the same filter I used in the past, updated for JavaFX 16 for comparison: > > https://bugs.openjdk.java.net/issues/?filter=40381 > > You'll notice that it excludes test bugs and build issue (so the "GitHub Actions" bugs don't show up, for example) Below is the release note for the warning, taken from [this release note sub-task](https://bugs.openjdk.java.net/browse/JDK-8262948): --- ### JavaFX runtime logs a warning if javafx.* modules are loaded from the classpath The JavaFX classes must be loaded from a set of named `javafx.*` modules on the _module path_. Loading the JavaFX classes from the classpath is not supported. The JavaFX runtime logs a warning at startup if the JavaFX classes are not loaded from the expected named module. See [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362) for more information. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+43553916+mstr2 at openjdk.java.net Wed Mar 3 14:29:07 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Wed, 3 Mar 2021 14:29:07 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes Message-ID: The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. ------------- Commit messages: - 8089913: CSS styling problem with Slider pseudo classes - Failing test Changes: https://git.openjdk.java.net/jfx/pull/413/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8089913 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/413.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/413/head:pull/413 PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Wed Mar 3 14:37:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 14:37:41 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 15:17:23 GMT, mstr2 wrote: > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. @mstr2 can you enable pre-submit testing for your repo as indicated the Checks section? You might need to then push a new (empty) commit to your branch in order to trigger the tests to run. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+43553916+mstr2 at openjdk.java.net Wed Mar 3 14:44:02 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Wed, 3 Mar 2021 14:44:02 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes [v2] In-Reply-To: References: Message-ID: > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. mstr2 has updated the pull request incrementally with one additional commit since the last revision: Empty commit to trigger tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/413/files - new: https://git.openjdk.java.net/jfx/pull/413/files/12714b01..dfe577cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/413.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/413/head:pull/413 PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Wed Mar 3 14:44:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 14:44:38 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: <8JBnxPC20Ause4JqDozYsnSwiffBGuMQiAvcP5wCR44=.1097faa6-898b-49d3-ad43-8eb3aad39290@github.com> On Wed, 3 Mar 2021 14:12:40 GMT, Kevin Rushforth wrote: >> For the last couple releases, I generated the list of bugs to add to release notes, and yes, I typically exclude backports for that reason (it isn't perfect, but it also excludes the issues labeled with the `hgupdate-sync` label, which can be added to indicate an issue synced in from a prior release). >> >> Here is the same filter I used in the past, updated for JavaFX 16 for comparison: >> >> https://bugs.openjdk.java.net/issues/?filter=40381 >> >> You'll notice that it excludes test bugs and build issue (so the "GitHub Actions" bugs don't show up, for example) > > Below is the release note for the warning, taken from [this release note sub-task](https://bugs.openjdk.java.net/browse/JDK-8262948): > > --- > > ### JavaFX runtime logs a warning if javafx.* modules are loaded from the classpath > > The JavaFX classes must be loaded from a set of named `javafx.*` modules on the _module path_. Loading the JavaFX classes from the classpath is not supported. The JavaFX runtime logs a warning at startup if the JavaFX classes are not loaded from the expected named module. See [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362) for more information. I also missed noticing that the following bug is marked with the need for a release note: [JDK-8196079](https://bugs.openjdk.java.net/browse/JDK-8196079): Remove obsolete Pisces rasterizer I'll create one shortly and add a comment to this PR when done. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 14:55:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 14:55:41 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: <8JBnxPC20Ause4JqDozYsnSwiffBGuMQiAvcP5wCR44=.1097faa6-898b-49d3-ad43-8eb3aad39290@github.com> References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> <8JBnxPC20Ause4JqDozYsnSwiffBGuMQiAvcP5wCR44=.1097faa6-898b-49d3-ad43-8eb3aad39290@github.com> Message-ID: On Wed, 3 Mar 2021 14:41:46 GMT, Kevin Rushforth wrote: >> Below is the release note for the warning, taken from [this release note sub-task](https://bugs.openjdk.java.net/browse/JDK-8262948): >> >> --- >> >> ### JavaFX runtime logs a warning if javafx.* modules are loaded from the classpath >> >> The JavaFX classes must be loaded from a set of named `javafx.*` modules on the _module path_. Loading the JavaFX classes from the classpath is not supported. The JavaFX runtime logs a warning at startup if the JavaFX classes are not loaded from the expected named module. See [JDK-8256362](https://bugs.openjdk.java.net/browse/JDK-8256362) for more information. > > I also missed noticing that the following bug is marked with the need for a release note: > > [JDK-8196079](https://bugs.openjdk.java.net/browse/JDK-8196079): Remove obsolete Pisces rasterizer > > I'll create one shortly and add a comment to this PR when done. Below is the release note for the removal of the Pisces rasterizer, taken from [this release note sub-task](https://bugs.openjdk.java.net/browse/JDK-8262951): --- ### The obsolete Pisces rasterizer has been removed from JavaFX The obsolete Pisces rasterizer has been removed from JavaFX. The Marlin rasterizer has been the default since JDK 10, but it was possible to select either the native Pisces rasterizer or the Java-based Pisces rasterizer by setting the `prism.rasterizerorder` system property to `nativepisces` or `javapisces`, respectively. Those options will now be silently ignored and the default Marlin rasterizer will always be used. See [JDK-8196079](https://bugs.openjdk.java.net/browse/JDK-8196079) for more information. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From fastegal at openjdk.java.net Wed Mar 3 16:43:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 3 Mar 2021 16:43:42 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 14:35:24 GMT, Kevin Rushforth wrote: >> The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. > > @mstr2 can you enable pre-submit testing for your repo as indicated the Checks section? You might need to then push a new (empty) commit to your branch in order to trigger the tests to run. side note: there might be a similar issue in other controls, f.i. the pseudoState of ListView orientation doesn't seem to be initialized ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Mar 3 17:57:55 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 3 Mar 2021 17:57:55 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v5] In-Reply-To: References: Message-ID: <7szfqoFwDpSRjW3XvFYsqf31zNGaxzVxiSuq3g7AnGA=.9f75b881-2023-4a08-b4a3-90b89c512b5c@github.com> > Add release notes for JavaFX 16 to the repository Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: - 8262460: Fix markdown table layout - 8262460: Add release notes for JDK-8256362 and JDK-8196079. Remove test bugs and build issue from list of issues. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/414/files - new: https://git.openjdk.java.net/jfx/pull/414/files/8eaa45f7..ee829502 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=414&range=03-04 Stats: 47 lines in 1 file changed: 17 ins; 30 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/414.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/414/head:pull/414 PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Mar 3 17:57:55 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 3 Mar 2021 17:57:55 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: On Wed, 3 Mar 2021 13:21:06 GMT, Kevin Rushforth wrote: > https://bugs.openjdk.java.net/issues/?filter=40381 Hi @kevinrushforth , Thanks for this list. You may want to add `test_sprint` to the list of labels :) ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 17:57:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 17:57:55 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> Message-ID: <-4vDOTqjU8UallQpXYzCNir2wj3wiE11IymFHR01-_8=.e8e751cd-d2a4-4e6a-b953-909a3ba577f4@github.com> On Wed, 3 Mar 2021 17:18:37 GMT, Abhinay Agarwal wrote: >> For the last couple releases, I generated the list of bugs to add to release notes, and yes, I typically exclude backports for that reason (it isn't perfect, but it also excludes the issues labeled with the `hgupdate-sync` label, which can be added to indicate an issue synced in from a prior release). >> >> Here is the same filter I used in the past, updated for JavaFX 16 for comparison: >> >> https://bugs.openjdk.java.net/issues/?filter=40381 >> >> You'll notice that it excludes test bugs and build issue (so the "GitHub Actions" bugs don't show up, for example) > >> https://bugs.openjdk.java.net/issues/?filter=40381 > > Hi @kevinrushforth , > > Thanks for this list. You may want to add `test_sprint` to the list of labels :) I don't think there should be any `test_sprint` labeled bugs that don't also have one of `testbug` or `noreg-self`, but I'll check. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 17:57:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 17:57:55 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v2] In-Reply-To: <-4vDOTqjU8UallQpXYzCNir2wj3wiE11IymFHR01-_8=.e8e751cd-d2a4-4e6a-b953-909a3ba577f4@github.com> References: <51iRuNj-OYvFG_AxH_d-vOy8sV4ct6_ITY0TCUdvHNs=.ee624dac-3167-4a21-82cd-fd873982cd71@github.com> <-4vDOTqjU8UallQpXYzCNir2wj3wiE11IymFHR01-_8=.e8e751cd-d2a4-4e6a-b953-909a3ba577f4@github.com> Message-ID: <2s0q-_AnM3Jmo-GVD5aCzEFuK1dOK8D-FLFUcKPTaiQ=.1332067c-dc3b-47e3-a048-8c13abdfcef5@github.com> On Wed, 3 Mar 2021 17:26:33 GMT, Kevin Rushforth wrote: >>> https://bugs.openjdk.java.net/issues/?filter=40381 >> >> Hi @kevinrushforth , >> >> Thanks for this list. You may want to add `test_sprint` to the list of labels :) > > I don't think there should be any `test_sprint` labeled bugs that don't also have one of `testbug` or `noreg-self`, but I'll check. And it turns out there were three. I added the `testbug` label. Thanks for pointing it out. ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Wed Mar 3 19:59:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Mar 2021 19:59:46 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v5] In-Reply-To: <7szfqoFwDpSRjW3XvFYsqf31zNGaxzVxiSuq3g7AnGA=.9f75b881-2023-4a08-b4a3-90b89c512b5c@github.com> References: <7szfqoFwDpSRjW3XvFYsqf31zNGaxzVxiSuq3g7AnGA=.9f75b881-2023-4a08-b4a3-90b89c512b5c@github.com> Message-ID: On Wed, 3 Mar 2021 17:57:55 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 16 to the repository > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - 8262460: Fix markdown table layout > - 8262460: Add release notes for JDK-8256362 and JDK-8196079. Remove test bugs and build issue from list of issues. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/414 From tsayao at openjdk.java.net Wed Mar 3 20:34:03 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 3 Mar 2021 20:34:03 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v18] In-Reply-To: References: Message-ID: <_zQGvJJPWpP7IyR7WEuIHqbRzTC4WM8uukTm030x_rI=.2e3da2b6-1748-491f-8c76-645e8eab8c25@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Partial progress ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/1d085aad..180a1ea9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=16-17 Stats: 97 lines in 2 files changed: 27 ins; 38 del; 32 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From jvos at openjdk.java.net Wed Mar 3 21:19:47 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 3 Mar 2021 21:19:47 GMT Subject: [jfx16] RFR: 8262460: Create release notes for JavaFX 16 [v5] In-Reply-To: <7szfqoFwDpSRjW3XvFYsqf31zNGaxzVxiSuq3g7AnGA=.9f75b881-2023-4a08-b4a3-90b89c512b5c@github.com> References: <7szfqoFwDpSRjW3XvFYsqf31zNGaxzVxiSuq3g7AnGA=.9f75b881-2023-4a08-b4a3-90b89c512b5c@github.com> Message-ID: On Wed, 3 Mar 2021 17:57:55 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 16 to the repository > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - 8262460: Fix markdown table layout > - 8262460: Add release notes for JDK-8256362 and JDK-8196079. Remove test bugs and build issue from list of issues. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From github.com+16880178+palexdev at openjdk.java.net Wed Mar 3 22:11:42 2021 From: github.com+16880178+palexdev at openjdk.java.net (Alessadro Parisi) Date: Wed, 3 Mar 2021 22:11:42 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Mon, 11 May 2020 04:50:22 GMT, Ambarish Rapte wrote: >> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214). >> >> I have run a full build and test using this new compiler. >> >> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by this PR. > > lgtm, verified a local build on Windows10. Can you also update the build script located in tools/scripts? Build fails on my system with `FAIL: WINSDK_DIR not defined` ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From jpereda at openjdk.java.net Wed Mar 3 22:47:54 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 3 Mar 2021 22:47:54 GMT Subject: RFR: 8262802: Wrong context origin coordinates when using EGL and HiDPI Message-ID: See [issue](https://bugs.openjdk.java.net/browse/JDK-8262802) for detailed description. This PR solves the wrong calculations of ContextX and ContextY in ES2SwapChain when EGL is used on HiDPI devices, by using properly scaled dimensions. Without these changes, any popup control is misplaced. ------------- Commit messages: - Use scaled dimensions to determine the origin coordinates when using EGL Changes: https://git.openjdk.java.net/jfx/pull/416/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=416&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262802 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/416.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/416/head:pull/416 PR: https://git.openjdk.java.net/jfx/pull/416 From jpereda at openjdk.java.net Wed Mar 3 23:04:01 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 3 Mar 2021 23:04:01 GMT Subject: RFR: 8262802: Wrong context origin coordinates when using EGL and HiDPI [v2] In-Reply-To: References: Message-ID: > See [issue](https://bugs.openjdk.java.net/browse/JDK-8262802) for detailed description. > > This PR solves the wrong calculations of ContextX and ContextY in ES2SwapChain when EGL is used on HiDPI devices, by using properly scaled dimensions. Without these changes, any popup control is misplaced. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary spacing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/416/files - new: https://git.openjdk.java.net/jfx/pull/416/files/09520338..b774eccf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=416&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=416&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/416.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/416/head:pull/416 PR: https://git.openjdk.java.net/jfx/pull/416 From arapte at openjdk.java.net Thu Mar 4 04:01:03 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 4 Mar 2021 04:01:03 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v2] In-Reply-To: References: Message-ID: <1XxY-iJq1cWXvIkgJOM_waH8Ve_KoNDwfKEqphSUeJ8=.7666e389-ef43-4ff4-a36e-87e3f4ae3b1d@github.com> > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: update to recalculate properties when font size changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/397/files - new: https://git.openjdk.java.net/jfx/pull/397/files/e2372f4d..816304de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=00-01 Stats: 653 lines in 5 files changed: 443 ins; 71 del; 139 mod Patch: https://git.openjdk.java.net/jfx/pull/397.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397 PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Thu Mar 4 08:09:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 4 Mar 2021 08:09:40 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v2] In-Reply-To: References: Message-ID: On Tue, 9 Feb 2021 01:33:06 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> update to recalculate properties when font size changes > > This is taking me longer to review than I expected, because I ran into some anomalies while doing some additional testing. There is an unexpected change in behavior for nested panes with relative sizes. We need to understand this change before this is integrated. > > I added a modified version of the original test program to the JBS bug report that creates a scene graph like this, where the root and both parent nodes specify the font size in absolute pixels: > > Root // -fx-font-size: 96px > P1 // -fx-font-size: 48px > P2 // -fx-font-size: 36px > L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em > > The above scene graph works as expected with the fix, whereas before the fix label L3 had incorrect padding. > > I then added a button to cycle through 4 modes replacing first P2, then P1, then the Root with what would be "equivalent" relative font sizes if the definition of an "em" is its parent's font size. > > Root // -fx-font-size: 96px > P1 // -fx-font-size: 48px > P2 // -fx-font-size: 0.75em > L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em > > Root // -fx-font-size: 96px > P1 // -fx-font-size: 0.5em > P2 // -fx-font-size: 0.75em > L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em > > Root // -fx-font-size: 8.0em > P1 // -fx-font-size: 0.5em > P2 // -fx-font-size: 0.75em > L1 (unset), L2 (18px), L3 (0.5em) // All three had padding and bg radius at 0.5em > > Things start getting unexpected when there is a parent with a relative font size, and the label had a relative font size (e.g., L3 when P2 is relative). When all nodes are relative (the last case), the padding size is completely wrong. > > Btw, I'm not currently worried about the calculation of the font size itself; this fix is intended to be a targeted fix that doesn't change the calculated font size (separately, we could look at that, but it would be much riskier and is out of scope for this bug fix). What I want to make sure is that in all cases, specifying the padding or other sizes in a node in ems will be relative to whatever the calculated font size is. The cause of wrong behaviour in the scenario that Kevin has mentioned in [previous comment](https://github.com/openjdk/jfx/pull/397#pullrequestreview-586076272) : The font size property of the Controls that are inherited from class `Labeled` is a shared a property. It is shared with a child `LabeledText` control. The `Label`'s(inherited from Labeled) css properties are first computed relative to the font size property that was computed for Label. And when the font size is computed for LabeledText, it computes a different font size(which is not same as what was computed for Label). This results in the behaviour that Label's css properties do not remain relative to its font size. `-fx-font-size` is a very primary property and changing its behaviour may regress lot of applications. So we decided not to change the above behaviour. Instead the other option to fix is: recompute the relative sized css properties of Labeled when the font size is changed for LabeledText. Changes in commit: 1. A method to recalculate relative sized properties when font size changes. 2. Added more tests to verify different combinations of css among parent and child. Tests are written only using Label control. The issue and its fix can also be observed using other controls inherited from Labeled class.(RadioButton, CheckBox, Button,..) ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From ajoseph at openjdk.java.net Thu Mar 4 09:47:58 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 4 Mar 2021 09:47:58 GMT Subject: RFR: 8262276: Debug build of WebKit fails Message-ID: Fixing the Debug build of WebKit. Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. ------------- Commit messages: - 8262276: Debug build of WebKit fails Changes: https://git.openjdk.java.net/jfx/pull/417/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=417&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262276 Stats: 59 lines in 7 files changed: 39 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417 From tsayao at openjdk.java.net Thu Mar 4 11:51:52 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 4 Mar 2021 11:51:52 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v19] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Adjust positioning (not 100% yet) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/180a1ea9..24b388f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=17-18 Stats: 96 lines in 2 files changed: 58 ins; 25 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Mar 4 12:01:52 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 4 Mar 2021 12:01:52 GMT Subject: [jfx16] Integrated: 8262460: Create release notes for JavaFX 16 In-Reply-To: References: Message-ID: <5z0PBNaIFW_8dU-B72dcCgGQXKAbGoXlxg9kWZjCwSo=.da8dac5a-2eec-46ad-8c09-e359d3b6a8a2@github.com> On Tue, 2 Mar 2021 18:25:14 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 16 to the repository This pull request has now been integrated. Changeset: e0ce73a3 Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/e0ce73a3 Stats: 92 lines in 1 file changed: 92 ins; 0 del; 0 mod 8262460: Create release notes for JavaFX 16 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/414 From kcr at openjdk.java.net Thu Mar 4 12:41:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Mar 2021 12:41:45 GMT Subject: Integrated: Merge jfx:jfx16 Message-ID: <65GcNnFQIPhmd7-roh9qr8qAYFACJ5RfCGpZw4q4AIU=.4c273e47-a61a-4146-99f5-f8eb8771c232@github.com> Sync `jfx16` branch into `master`. ------------- Commit messages: - Merge branch 'jfx16' into merge-jfx16-2021-03-04 - 8260165: CSSFilterTest.testCSSFilterRendering system test fails - 8260257: [Linux] WebView no longer reacts to some mouse events - 8262236: Configure Gradle checksum verification - 8260468: Wrong behavior of LocalDateTimeStringConverter - 8261927: WebKit build fails with Visual Studio 2017 - 8252935: Add treeShowing listener only when needed - 8261460: Incorrect CSS applied to ContextMenu on DialogPane - 8248126: JavaFX ignores HiDPI scaling settings on some linux platforms - 8252099: JavaFX does not render Myanmar script correctly - ... and 17 more: https://git.openjdk.java.net/jfx/compare/e0ce73a3...2d97419f The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/418/files Stats: 273221 lines in 5576 files changed: 127514 ins; 105909 del; 39798 mod Patch: https://git.openjdk.java.net/jfx/pull/418.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/418/head:pull/418 PR: https://git.openjdk.java.net/jfx/pull/418 From kcr at openjdk.java.net Thu Mar 4 12:41:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Mar 2021 12:41:46 GMT Subject: Integrated: Merge jfx:jfx16 In-Reply-To: <65GcNnFQIPhmd7-roh9qr8qAYFACJ5RfCGpZw4q4AIU=.4c273e47-a61a-4146-99f5-f8eb8771c232@github.com> References: <65GcNnFQIPhmd7-roh9qr8qAYFACJ5RfCGpZw4q4AIU=.4c273e47-a61a-4146-99f5-f8eb8771c232@github.com> Message-ID: <3v2wciIpEFC1Ra_aLmfd4FksRQT2Mil_tl6n18AFmF8=.059d7ae6-7577-44b2-a11c-45ff0176db92@github.com> On Thu, 4 Mar 2021 12:36:29 GMT, Kevin Rushforth wrote: > Sync `jfx16` branch into `master`. This pull request has now been integrated. Changeset: a00ef79c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a00ef79c Stats: 92 lines in 1 file changed: 92 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/418 From nlisker at gmail.com Thu Mar 4 14:47:57 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 4 Mar 2021 16:47:57 +0200 Subject: Eclipse problem: not compiling module projects In-Reply-To: <20210302144809.Horde.mHk-RW6aZJLLKFyV1LS0DA1@webmail.df.eu> References: <20210302143751.Horde.lk0y4PTv4Fwknhfk1KQFRA1@webmail.df.eu> <20210302144809.Horde.mHk-RW6aZJLLKFyV1LS0DA1@webmail.df.eu> Message-ID: I updated to the December version (4.18) a while ago and didn't have any issues. Maybe there was some new compiler setting that did something, so I would look at the release notes. I'm going to move to 4.19 soon. On Tue, Mar 2, 2021 at 3:48 PM Jeanette Winzenburg wrote: > > "from scratch" are the words I feared to hear ;) Probably no way > around, thanks Tom! > > Zitat von Tom Schindl : > > > I setup everything from scratch a few weeks ago and all worked fine: > > * I first run the gradle build > > * then imported everything into Eclipse > > > > Tom > > > > Am 02.03.21 um 14:37 schrieb Jeanette Winzenburg: > >> > >> Just a quick question to Eclipse users (who do compile with > >> Eclipse, not with gradle) > >> > >> Problem: > >> > >> updated my Eclipse to the december release yesterday, now it > >> doesn't compile (neither automatically, nor forcing a clean build) > >> anything as soon as the module projects are included, neither the > >> modules nor dependent projects - nothing else changed (hopefully > >> ;). All fine when adding the compiled module-jars. > >> > >> Questions: > >> > >> - anybody else seeing it? > >> - any ideas where to look? > >> > >> -- Jeanette > >> > >> > >> > >> > > > > From tsayao at openjdk.java.net Thu Mar 4 20:29:59 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Thu, 4 Mar 2021 20:29:59 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v20] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/24b388f2..b5547410 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=18-19 Stats: 145 lines in 3 files changed: 35 ins; 68 del; 42 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From kcr at openjdk.java.net Thu Mar 4 21:59:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Mar 2021 21:59:43 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v2] In-Reply-To: <1XxY-iJq1cWXvIkgJOM_waH8Ve_KoNDwfKEqphSUeJ8=.7666e389-ef43-4ff4-a36e-87e3f4ae3b1d@github.com> References: <1XxY-iJq1cWXvIkgJOM_waH8Ve_KoNDwfKEqphSUeJ8=.7666e389-ef43-4ff4-a36e-87e3f4ae3b1d@github.com> Message-ID: On Thu, 4 Mar 2021 04:01:03 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > update to recalculate properties when font size changes The fix looks good to me, as do the new unit tests. I tested it with the test program I wrote as well as by running your new unit test with / without the fix. As with any CSS fix, the two things we need to ensure are that there are no functional regressions and that there is no significant performance hit. I have a a couple questions: 1. The new method is only needed for Labeled because of the way it constructs the child graph, right? Is there anything that would preclude some other control from using this in the future, if a similar situation would arise? 2. Have you done any performance testing to ensure that there are no regressions? I wouldn't think there would be, given that this only applies the fix when the size of a Labeled control changes. I also left some inline suggestions and questions. modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 224: > 222: double p2FontSize = rootFontSize * 0.7; > 223: double p3FontSize = p1FontSize * 0.6; > 224: double p4FontSize = p2FontSize * 0.5; Is it worth a note that the expected font size is relative to the node's grandparent if both the node and its parent are relative? This is one of the oddities of font size that we are (intentionally) preserving, so it seems worth documenting it. Especially given your comment on the next test (the one that is `@Ignore`d). modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 337: > 335: System.err.println("p2FontSize: " + p2FontSize); > 336: System.err.println("p3FontSize: " + p3FontSize); > 337: System.err.println("p4FontSize: " + p4FontSize); Are you planning to leave these print statements in? It seems like noise now that you are done debugging the test. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 578: > 576: // Currently this method is executed only by Labeled.fontProperty().set(), when it's font size > 577: // is changed by LabeledText. > 578: void recalculateRelativeSizeProperties(final Node node, Font fontForRelativeSizes) { Given the tricky nature of this fix, I would like to see a little more description in the comment explaining why it is needed and how it works. Specifically, it should say why the originally calculated value is incorrect, and indicate that a second pass is needed for certain cases. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 603: > 601: for (int n = 0; n < numStyleables; n++) { > 602: > 603: final CssMetaData cssMetaData = This may need the ` @SuppressWarnings("unchecked")` annotation, as done in the original method. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 664: > 662: > 663: if (originOfCalculatedValue == null) { > 664: assert false : styleableProperty.toString(); We don't generally use `assert` in our code (although I see this part is copied from the original method, so I understand if you prefer to leave it). modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 630: > 628: ParsedValue resolved = resolveLookups(node, cssValue, styleMap, transitionStates[0], whence, new HashSet<>()); > 629: boolean isRelative = ParsedValueImpl.containsFontRelativeSize(resolved, false); > 630: if (!isRelative) { Is it possible to have a property that is absolute with sub-properties that might be relative? If so, then I think you need to add a check for `numSubProperties == 0` so you don't skip this case. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 707: > 705: } > 706: > 707: private boolean transitionStateInProgress = false; Minor: I recommend a blank line here. ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From kcr at openjdk.java.net Thu Mar 4 22:19:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Mar 2021 22:19:48 GMT Subject: RFR: 8262802: Wrong context origin coordinates when using EGL and HiDPI [v2] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 23:04:01 GMT, Jose Pereda wrote: >> See [issue](https://bugs.openjdk.java.net/browse/JDK-8262802) for detailed description. >> >> This PR solves the wrong calculations of ContextX and ContextY in ES2SwapChain when EGL is used on HiDPI devices, by using properly scaled dimensions. Without these changes, any popup control is misplaced. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary spacing Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/416 From kcr at openjdk.java.net Fri Mar 5 01:26:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 01:26:52 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 16:40:27 GMT, Jeanette Winzenburg wrote: >> @mstr2 can you enable pre-submit testing for your repo as indicated the Checks section? You might need to then push a new (empty) commit to your branch in order to trigger the tests to run. > > side note: there might be a similar issue in other controls, f.i. the pseudoState of ListView orientation doesn't seem to be initialized The fix and test look good. @kleopatra Good catch about the same problem occurring in other controls. I did a quick scan, and the same bug exists in at least `ListView`, which should initialize the VERTICAL PseudoClass in its constructor. Most of the others looked fine, except for the following, which need to be checked more carefully: TableView TreeTableView TreeCell TreeTableRow @mstr2 I think the scope of this bug should be expanded to fix at least the `ListView` issue, since it is effectively the same bug as this, with the same pattern used for the fix and test. The Tree/TableView classes could be looked at separately, unless you would like to take a closer look. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From jpereda at openjdk.java.net Fri Mar 5 08:43:43 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 5 Mar 2021 08:43:43 GMT Subject: Integrated: 8262802: Wrong context origin coordinates when using EGL and HiDPI In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 22:44:11 GMT, Jose Pereda wrote: > See [issue](https://bugs.openjdk.java.net/browse/JDK-8262802) for detailed description. > > This PR solves the wrong calculations of ContextX and ContextY in ES2SwapChain when EGL is used on HiDPI devices, by using properly scaled dimensions. Without these changes, any popup control is misplaced. This pull request has now been integrated. Changeset: e394b0a6 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/e394b0a6 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8262802: Wrong context origin coordinates when using EGL and HiDPI Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/416 From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 09:17:00 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 09:17:00 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes [v3] In-Reply-To: References: Message-ID: > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. mstr2 has updated the pull request incrementally with three additional commits since the last revision: - Fix whitespace issue - Set :vertical pseudoclass in ListView constructor - Failing test for ListView ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/413/files - new: https://git.openjdk.java.net/jfx/pull/413/files/dfe577cd..75108165 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=01-02 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/413.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/413/head:pull/413 PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 10:08:56 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 10:08:56 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes [v4] In-Reply-To: References: Message-ID: <7qE477iXLxXC3NRaFWMg4DPJpUlUQimJMYXUO_gIPmg=.145e7edf-752a-41f5-ab4b-ef256e3e14c7@github.com> > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. mstr2 has updated the pull request incrementally with two additional commits since the last revision: - Fixed default pseudoclasses for TableView, TreeCell, TreeTableRow, TreeTableView - Add failing test for TableView, TreeCell, TreeTableRow, TreeTableView ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/413/files - new: https://git.openjdk.java.net/jfx/pull/413/files/75108165..e64b34d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=02-03 Stats: 42 lines in 8 files changed: 42 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/413.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/413/head:pull/413 PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 10:49:46 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 10:49:46 GMT Subject: RFR: 8089913: CSS styling problem with Slider pseudo classes In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 01:24:09 GMT, Kevin Rushforth wrote: >> side note: there might be a similar issue in other controls, f.i. the pseudoState of ListView orientation doesn't seem to be initialized > > The fix and test look good. > > @kleopatra Good catch about the same problem occurring in other controls. I did a quick scan, and the same bug exists in at least `ListView`, which should initialize the VERTICAL PseudoClass in its constructor. Most of the others looked fine, except for the following, which need to be checked more carefully: > > TableView > TreeTableView > TreeCell > TreeTableRow > > > @mstr2 I think the scope of this bug should be expanded to fix at least the `ListView` issue, since it is effectively the same bug as this, with the same pattern used for the fix and test. The Tree/TableView classes could be looked at separately, unless you would like to take a closer look. I've fixed similar issues with the following pseudoclasses: ListView:vertical TableView:unconstrained-resize TreeTableView:unconstrained-resize TreeCell:collapsed TreeTableRow:collapsed ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From kirill.grouchnikov at gmail.com Fri Mar 5 14:18:19 2021 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Fri, 5 Mar 2021 09:18:19 -0500 Subject: font color fringes on macOS, not a priority? In-Reply-To: <80356A8D-1C91-4D43-98EA-244FE75EF561@gmail.com> References: <7235fab8-f145-859d-868b-687bae47cbae@xs4all.nl> <80356A8D-1C91-4D43-98EA-244FE75EF561@gmail.com> Message-ID: I reported this issue back in November 2018 on this very mailing list. Desktop-consistent font selection and rendering has been consistently one of the more problematic parts of both Swing and JavaFX, including poor support for rendering variable San Francisco font starting with macOS Catalina. On Mon, Mar 1, 2021 at 8:36 AM Rob Nikander wrote: > > > > On Mar 1, 2021, at 7:01 AM, John Hendrikx wrote: > > > > Not a solution to the problem (the color fringes on Mac apparently are > using almost fully saturated subpixels which seems like a serious issue), > but I see color fringes on most screens so I always just turn this type of > rendering off. It obviously depends on the pixel density though as higher > resolution 4k+ screens make the colored fringes less obvious. > > > > Have you tried to simply turn subpixel rendering off as a temporary > solution? > > > > System.setProperty("prism.lcdtext", "false?) > > Thanks, that helps. It stopped the color fringes on my MacBook Pro retina > screen, but doesn?t cure all the font problems. The glyphs are still too > close together compared to the text in native apps. > > > > From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 16:07:59 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 16:07:59 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls [v5] In-Reply-To: References: Message-ID: > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. mstr2 has updated the pull request incrementally with one additional commit since the last revision: Revert changes to TreeCell, TreeTableRow ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/413/files - new: https://git.openjdk.java.net/jfx/pull/413/files/e64b34d7..e0bedd57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=413&range=03-04 Stats: 14 lines in 4 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/413.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/413/head:pull/413 PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Fri Mar 5 16:08:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:17 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls [v5] In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 15:52:57 GMT, mstr2 wrote: >> The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. > > mstr2 has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to TreeCell, TreeTableRow Looks good. I can confirm that the new tests fail without the fix and pass with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Fri Mar 5 16:08:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:27 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 10:46:52 GMT, mstr2 wrote: >> The fix and test look good. >> >> @kleopatra Good catch about the same problem occurring in other controls. I did a quick scan, and the same bug exists in at least `ListView`, which should initialize the VERTICAL PseudoClass in its constructor. Most of the others looked fine, except for the following, which need to be checked more carefully: >> >> TableView >> TreeTableView >> TreeCell >> TreeTableRow >> >> >> @mstr2 I think the scope of this bug should be expanded to fix at least the `ListView` issue, since it is effectively the same bug as this, with the same pattern used for the fix and test. The Tree/TableView classes could be looked at separately, unless you would like to take a closer look. > > I've fixed similar issues with the following pseudoclasses: > > ListView:vertical > TableView:unconstrained-resize > TreeTableView:unconstrained-resize > TreeCell:collapsed > TreeTableRow:collapsed Thanks for the additional fixes. I'll change the title of the JBS bug to "CSS pseudo classes missing by default for some controls". Can you change the PR title to match? The changes to `ListView` and `TableView` look correct to me. In looking more closely, I'm not sure the changes to `TreeCell` or `TreeTableRow` are correct. When a `TreeCell` or `TreeTableRow` is constructed, the item is null. Unless I'm missing something, it looks like a cell/row with a null item shouldn't have a pseudo-class state set. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Fri Mar 5 16:08:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:34 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 13:21:09 GMT, Kevin Rushforth wrote: > The changes to ListView and TableView look correct to me. And also `TreeTableView`. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 16:08:40 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 16:08:40 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: Message-ID: <_-Z1Rf5uMbmDxJE_LL7KXGMAYlMYR42xnwISPoJ2gm8=.7bde350c-e8a0-4b40-88ec-280665eac117@github.com> On Fri, 5 Mar 2021 13:31:38 GMT, Kevin Rushforth wrote: >> Thanks for the additional fixes. I'll change the title of the JBS bug to "CSS pseudo classes missing by default for some controls". Can you change the PR title to match? >> >> The changes to `ListView` and `TableView` look correct to me. >> >> In looking more closely, I'm not sure the changes to `TreeCell` or `TreeTableRow` are correct. When a `TreeCell` or `TreeTableRow` is constructed, the item is null. Unless I'm missing something, it looks like a cell/row with a null item shouldn't have a pseudo-class state set. > >> The changes to ListView and TableView look correct to me. > > And also `TreeTableView`. I guess that depends on whether a `TreeCell` or `TreeTableRow` that is not expanded should be considered collapsed. Unless there are compelling reasons to have cells that are neither expanded nor collapsed, I think it is sensible to default to treating non-existing items as collapsed. Currently, once `:expanded` or `:collapsed` has been set, it will not be removed even if the item is set to `null`. This should probably be changed to either: 1. remove any pseudoclass when the item is set to `null`, or 2. set the `:collapsed` pseudoclass and remove the `:expanded` pseudoclass when the item is set to null. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Fri Mar 5 16:08:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:44 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: <_-Z1Rf5uMbmDxJE_LL7KXGMAYlMYR42xnwISPoJ2gm8=.7bde350c-e8a0-4b40-88ec-280665eac117@github.com> References: <_-Z1Rf5uMbmDxJE_LL7KXGMAYlMYR42xnwISPoJ2gm8=.7bde350c-e8a0-4b40-88ec-280665eac117@github.com> Message-ID: On Fri, 5 Mar 2021 13:33:41 GMT, mstr2 wrote: >>> The changes to ListView and TableView look correct to me. >> >> And also `TreeTableView`. > > I guess that depends on whether a `TreeCell` or `TreeTableRow` that is not expanded should be considered collapsed. > > Unless there are compelling reasons to have cells that are neither expanded nor collapsed, I think it is sensible to default to treating non-existing items as collapsed. > > Currently, once `:expanded` or `:collapsed` has been set, it will not be removed even if the item is set to `null`. This should probably be changed to either: > 1. remove any pseudoclass when the item is set to `null`, or > 2. set the `:collapsed` pseudoclass and remove the `:expanded` pseudoclass when the item is set to null. It does seems like there is a possible inconsistency for `TreeCell` and `TreeTableRow`. I'm not sure it matters in practice, since an application doesn't directly manage the creation of the cells (other than by providing a cell factory) or setting the item. The pseudo-class state of the cell is a proxy for the item it points to. Ideally, it would only contain the "empty" state if the item is null, but given that such a cell would never be rendered it would be hard to point to something that doesn't work as a result. In any case, since there are larger issues than just setting the default state for `TreeCell` and `TreeTableRow` I'd prefer to decouple them from this issue and file a follow-up issue (which doesn't need to be looked at any time soon). ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+43553916+mstr2 at openjdk.java.net Fri Mar 5 16:08:47 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Fri, 5 Mar 2021 16:08:47 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: <_-Z1Rf5uMbmDxJE_LL7KXGMAYlMYR42xnwISPoJ2gm8=.7bde350c-e8a0-4b40-88ec-280665eac117@github.com> Message-ID: On Fri, 5 Mar 2021 14:38:06 GMT, Kevin Rushforth wrote: >> I guess that depends on whether a `TreeCell` or `TreeTableRow` that is not expanded should be considered collapsed. >> >> Unless there are compelling reasons to have cells that are neither expanded nor collapsed, I think it is sensible to default to treating non-existing items as collapsed. >> >> Currently, once `:expanded` or `:collapsed` has been set, it will not be removed even if the item is set to `null`. This should probably be changed to either: >> 1. remove any pseudoclass when the item is set to `null`, or >> 2. set the `:collapsed` pseudoclass and remove the `:expanded` pseudoclass when the item is set to null. > > It does seems like there is a possible inconsistency for `TreeCell` and `TreeTableRow`. I'm not sure it matters in practice, since an application doesn't directly manage the creation of the cells (other than by providing a cell factory) or setting the item. The pseudo-class state of the cell is a proxy for the item it points to. Ideally, it would only contain the "empty" state if the item is null, but given that such a cell would never be rendered it would be hard to point to something that doesn't work as a result. > > In any case, since there are larger issues than just setting the default state for `TreeCell` and `TreeTableRow` I'd prefer to decouple them from this issue and file a follow-up issue (which doesn't need to be looked at any time soon). I've reverted the changes to `TreeCell` and `TreeTableRow`. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:05:07 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:05:07 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic Message-ID: https://bugs.openjdk.java.net/browse/JDK-8185886 Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. This may alleviate some of the issues seen here: TableView has a horrific performance with many columns #409 https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 JDK-8088394 : Huge memory consumption in TableView with too many columns JDK-8166956: JavaFX TreeTableView slow scroll performance JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html ------------- Commit messages: - JDK-8185886 Changes: https://git.openjdk.java.net/jfx/pull/108/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252936 Stats: 240 lines in 4 files changed: 105 ins; 76 del; 59 mod Patch: https://git.openjdk.java.net/jfx/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/108/head:pull/108 PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:08:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:50 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: <_-Z1Rf5uMbmDxJE_LL7KXGMAYlMYR42xnwISPoJ2gm8=.7bde350c-e8a0-4b40-88ec-280665eac117@github.com> Message-ID: On Fri, 5 Mar 2021 15:20:36 GMT, mstr2 wrote: >> It does seems like there is a possible inconsistency for `TreeCell` and `TreeTableRow`. I'm not sure it matters in practice, since an application doesn't directly manage the creation of the cells (other than by providing a cell factory) or setting the item. The pseudo-class state of the cell is a proxy for the item it points to. Ideally, it would only contain the "empty" state if the item is null, but given that such a cell would never be rendered it would be hard to point to something that doesn't work as a result. >> >> In any case, since there are larger issues than just setting the default state for `TreeCell` and `TreeTableRow` I'd prefer to decouple them from this issue and file a follow-up issue (which doesn't need to be looked at any time soon). > > I've reverted the changes to `TreeCell` and `TreeTableRow`. Thanks. I filed [JDK-8263096](https://bugs.openjdk.java.net/browse/JDK-8263096) to track the follow-issue for `TreeCell` and `TreeTableRow`. ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:05:14 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:05:14 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: Message-ID: On Thu, 6 Feb 2020 16:13:33 GMT, dannygonzalez wrote: > https://bugs.openjdk.java.net/browse/JDK-8185886 > > Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. > > This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. > > This may alleviate some of the issues seen here: > > TableView has a horrific performance with many columns #409 > https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 > > JDK-8088394 : Huge memory consumption in TableView with too many columns > JDK-8166956: JavaFX TreeTableView slow scroll performance > JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction > > OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html I have signed the Oracle Contributor Agreement today. Have not received back any confirmation yet though. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Fri Mar 5 16:05:20 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 5 Mar 2021 16:05:20 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: Message-ID: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> On Thu, 6 Feb 2020 16:22:28 GMT, dannygonzalez wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185886 >> >> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. >> >> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. >> >> This may alleviate some of the issues seen here: >> >> TableView has a horrific performance with many columns #409 >> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 >> >> JDK-8088394 : Huge memory consumption in TableView with too many columns >> JDK-8166956: JavaFX TreeTableView slow scroll performance >> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction >> >> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html > > I have signed the Oracle Contributor Agreement today. Have not received back any confirmation yet though. hmm ... wouldn't the change violate spec of adding listeners: > If the same listener is added more than once, then it will be notified more than once. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:05:28 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:05:28 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> Message-ID: <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> On Wed, 12 Feb 2020 11:29:24 GMT, Jeanette Winzenburg wrote: > hmm ... wouldn't the change violate spec of adding listeners: > > > If the same listener is added more than once, then it will be notified more than once. True, I hadn't read that spec in ObservableValueBase. Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. I would need to store a registration count for each listener to satisfy this requirement. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Fri Mar 5 16:05:36 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 5 Mar 2021 16:05:36 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Wed, 12 Feb 2020 12:01:03 GMT, dannygonzalez wrote: > > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > yeah, the test coverage is ... not optimal :) > I would need to store a registration count for each listener to satisfy this requirement. a count plus some marker as to where it was added: addListener(firstL) addListener(secondL) addListener(firstL) must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:05:42 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:05:42 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Wed, 12 Feb 2020 12:22:15 GMT, Jeanette Winzenburg wrote: >>> hmm ... wouldn't the change violate spec of adding listeners: >>> >>> > If the same listener is added more than once, then it will be notified more than once. >> >> True, I hadn't read that spec in ObservableValueBase. >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> >> I would need to store a registration count for each listener to satisfy this requirement. > >> >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> > > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> > > yeah, the test coverage is ... not optimal :) > >> I would need to store a registration count for each listener to satisfy this requirement. > > a count plus some marker as to where it was added: > > addListener(firstL) > addListener(secondL) > addListener(firstL) > > must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. The set implementation has lowered this to below 1%. This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. I?m happy to receive any suggestions. Danny On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. yeah, the test coverage is ... not optimal :) I would need to store a registration count for each listener to satisfy this requirement. a count plus some marker as to where it was added: addListener(firstL) addListener(secondL) addListener(firstL) must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? ? You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Fri Mar 5 16:05:44 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 5 Mar 2021 16:05:44 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: <5Rp7tjFcyDn5nuy1AGgDHjI_c3OP9JKnMoXFt_Kjv6U=.312420e4-6571-48df-b81e-72c9d1abdd7a@github.com> On Wed, 12 Feb 2020 12:43:58 GMT, dannygonzalez wrote: > > The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. yeah, you are right can't find that spec on sequence right now - maybe I dreamed it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:05:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:05:47 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Wed, 12 Feb 2020 12:43:58 GMT, dannygonzalez wrote: >>> >>> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >>> >> >> whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? >> >>> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >>> >> >> yeah, the test coverage is ... not optimal :) >> >>> I would need to store a registration count for each listener to satisfy this requirement. >> >> a count plus some marker as to where it was added: >> >> addListener(firstL) >> addListener(secondL) >> addListener(firstL) >> >> must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? > > The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. > > The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. > The set implementation has lowered this to below 1%. > > This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. > > I?m happy to receive any suggestions. > > Danny > > > On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: > > > Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. > > whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? > > Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. > > yeah, the test coverage is ... not optimal :) > > I would need to store a registration count for each listener to satisfy this requirement. > > a count plus some marker as to where it was added: > > addListener(firstL) > addListener(secondL) > addListener(firstL) > > must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe. @dannygonzalez the reason for the `jcheck` failure is that you have commits with two different email addresses in your branch. At this point, it's probably best to squash the commits into a single commit with `git rebase -i master` (presuming that your local `master` is up to date), and then do a force-push. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:05:51 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:05:51 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Mon, 17 Feb 2020 13:51:49 GMT, Kevin Rushforth wrote: >> The listeners are called back in the order they were registered in my implementation although I didn?t see this requirement in the spec unless I missed something. >> >> The performance unregistering thousands of listeners by TableView from the array is killing the performance of our JavaFX application. It takes up to 60% of JavaFX Application thread CPU and there are various bug reports around this same TableView performance issue. >> The set implementation has lowered this to below 1%. >> >> This pull request may be too fundamental a change to go into mainline. We however have to build our local OpenJFX with this fix or our application is unusable. >> >> I?m happy to receive any suggestions. >> >> Danny >> >> >> On 12 Feb 2020, at 12:22, Jeanette Winzenburg > wrote: >> >> >> Although that does seem odd behaviour to me. Obviously as the original implementation was using an array I can see how the implementation drove that specification. >> >> whatever drove it (had been so since the beginning ot java desktop, at least since the days of swing), there is no way to change it, is it? >> >> Non of the JavaFx unit tests test for that specific case as the unit tests all passed. It would be nice if there was a specific test case for this behaviour. >> >> yeah, the test coverage is ... not optimal :) >> >> I would need to store a registration count for each listener to satisfy this requirement. >> >> a count plus some marker as to where it was added: >> >> addListener(firstL) >> addListener(secondL) >> addListener(firstL) >> >> must result in firstL.invalidated, seconL.invalidated, firstL.invalidated .. which brings us back to .. an array? >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub, or unsubscribe. > > @dannygonzalez the reason for the `jcheck` failure is that you have commits with two different email addresses in your branch. At this point, it's probably best to squash the commits into a single commit with `git rebase -i master` (presuming that your local `master` is up to date), and then do a force-push. @kevinrushforth just a note to say there are other ExpressionHelper classes (i.e. MapExpressionHelper, SetExpressionHelper and ListExpressionHelper) that also use arrays and suffer from the linear search issue when removing listeners. These however didn't appear in the critical path of the JavaFXThread and didn't come up in my profiling of TableView. If this pull request is accepted, my opinion is that they should probably all move to using the same pattern as here, which is to use Maps instead of Arrays for their listener lists so that all these classes are uniform. Thanks ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:05:54 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:05:54 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Tue, 18 Feb 2020 09:02:36 GMT, dannygonzalez wrote: >> @dannygonzalez the reason for the `jcheck` failure is that you have commits with two different email addresses in your branch. At this point, it's probably best to squash the commits into a single commit with `git rebase -i master` (presuming that your local `master` is up to date), and then do a force-push. > > @kevinrushforth just a note to say there are other ExpressionHelper classes (i.e. MapExpressionHelper, SetExpressionHelper and ListExpressionHelper) that also use arrays and suffer from the linear search issue when removing listeners. > > These however didn't appear in the critical path of the JavaFXThread and didn't come up in my profiling of TableView. > > If this pull request is accepted, my opinion is that they should probably all move to using the same pattern as here, which is to use Maps instead of Arrays for their listener lists so that all these classes are uniform. > > Thanks Sorry for the interruption, send a PR that corrects the same problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:05:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:05:58 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Sat, 22 Feb 2020 08:42:52 GMT, yosbits wrote: >> @kevinrushforth just a note to say there are other ExpressionHelper classes (i.e. MapExpressionHelper, SetExpressionHelper and ListExpressionHelper) that also use arrays and suffer from the linear search issue when removing listeners. >> >> These however didn't appear in the critical path of the JavaFXThread and didn't come up in my profiling of TableView. >> >> If this pull request is accepted, my opinion is that they should probably all move to using the same pattern as here, which is to use Maps instead of Arrays for their listener lists so that all these classes are uniform. >> >> Thanks > > Sorry for the interruption, send a PR that corrects the same problem. I haven't done a detailed review yet, but I worry about the memory consumption and performance of using a Map for the simple cases where there is only a single (or very small number) of listeners. These methods are used in many more places than just the TableView / TreeTableView implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:06:02 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:06:02 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Tue, 25 Feb 2020 00:43:34 GMT, Kevin Rushforth wrote: >> Sorry for the interruption, send a PR that corrects the same problem. > > I haven't done a detailed review yet, but I worry about the memory consumption and performance of using a Map for the simple cases where there is only a single (or very small number) of listeners. These methods are used in many more places than just the TableView / TreeTableView implementation. Replying to @nlisker and @kevinrushforth general comments about the memory consumption of using a LinkedHashMap: I agree that at the very least these should be lazy initialised when they are needed and that we should initially allocate a small capacity and load factor. We could also have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. keeping the implementation with a similar overhead to the original) and then switch to the HashMap when it exceeds this threshold. This would make the code more complicated and I wonder if this is the worth the extra complexity. I know that in our application, the thousands of listeners unregistering when using a TableView was stalling the JavaFX thread. I am happy to submit code that lazy initialises and minimises initial capacity and load factor as suggested or happy to take direction and suggestions from anyone with a deeper understanding of the code than myself. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at openjdk.java.net Fri Mar 5 16:06:08 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Mar 2021 16:06:08 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Tue, 25 Feb 2020 12:18:34 GMT, dannygonzalez wrote: >> I haven't done a detailed review yet, but I worry about the memory consumption and performance of using a Map for the simple cases where there is only a single (or very small number) of listeners. These methods are used in many more places than just the TableView / TreeTableView implementation. > > Replying to @nlisker and @kevinrushforth general comments about the memory consumption of using a LinkedHashMap: > > I agree that at the very least these should be lazy initialised when they are needed and that we should initially allocate a small capacity and load factor. > > We could also have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. keeping the implementation with a similar overhead to the original) and then switch to the HashMap when it exceeds this threshold. This would make the code more complicated and I wonder if this is the worth the extra complexity. > > I know that in our application, the thousands of listeners unregistering when using a TableView was stalling the JavaFX thread. > > I am happy to submit code that lazy initialises and minimises initial capacity and load factor as suggested or happy to take direction and suggestions from anyone with a deeper understanding of the code than myself. I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:06:13 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:06:13 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> On Tue, 25 Feb 2020 13:55:50 GMT, Nir Lisker wrote: >> Replying to @nlisker and @kevinrushforth general comments about the memory consumption of using a LinkedHashMap: >> >> I agree that at the very least these should be lazy initialised when they are needed and that we should initially allocate a small capacity and load factor. >> >> We could also have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. keeping the implementation with a similar overhead to the original) and then switch to the HashMap when it exceeds this threshold. This would make the code more complicated and I wonder if this is the worth the extra complexity. >> >> I know that in our application, the thousands of listeners unregistering when using a TableView was stalling the JavaFX thread. >> >> I am happy to submit code that lazy initialises and minimises initial capacity and load factor as suggested or happy to take direction and suggestions from anyone with a deeper understanding of the code than myself. > > I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. Even though the order of notifications is unspecified, the following tests fail if we use a HashMap vs LinkedHashMap i.e. the notifications are not in order of registration: test.javafx.scene.control.TableViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED java.lang.AssertionError: expected:<0> but was:<-1> at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:470) at org.junit.Assert.assertEquals(Assert.java:454) at test.javafx.scene.control.TableViewTest.ensureSelectionIsCorrectWhenItemsChange(TableViewTest.java:333) test.javafx.scene.control.TreeTableViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeTableViewTest.java:2042) test.javafx.scene.control.TreeViewTest > test_rt27185 FAILED java.lang.AssertionError: expected: but was: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:145) at test.javafx.scene.control.TreeViewTest.test_rt27185(TreeViewTest.java:603) test.javafx.scene.control.TreeViewTest > test_rt27180_collapseBranch_laterSiblingAndChildrenSelected FAILED java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at test.javafx.scene.control.TreeViewTest.test_rt27180_collapseBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:973) test.javafx.scene.control.TreeViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeViewTest.java:992) These would need to be investigated to see why they assume this order. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Fri Mar 5 16:06:19 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 5 Mar 2021 16:06:19 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> Message-ID: On Tue, 25 Feb 2020 14:06:23 GMT, dannygonzalez wrote: >> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. > > Even though the order of notifications is unspecified, the following tests fail if we use a HashMap vs LinkedHashMap i.e. the notifications are not in order of registration: > > test.javafx.scene.control.TableViewTest > ensureSelectionIsCorrectWhenItemsChange FAILED > java.lang.AssertionError: expected:<0> but was:<-1> > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.failNotEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:126) > at org.junit.Assert.assertEquals(Assert.java:470) > at org.junit.Assert.assertEquals(Assert.java:454) > at test.javafx.scene.control.TableViewTest.ensureSelectionIsCorrectWhenItemsChange(TableViewTest.java:333) > > test.javafx.scene.control.TreeTableViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED > java.lang.AssertionError: > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at test.javafx.scene.control.TreeTableViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeTableViewTest.java:2042) > > test.javafx.scene.control.TreeViewTest > test_rt27185 FAILED > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.failNotEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:126) > at org.junit.Assert.assertEquals(Assert.java:145) > at test.javafx.scene.control.TreeViewTest.test_rt27185(TreeViewTest.java:603) > > test.javafx.scene.control.TreeViewTest > test_rt27180_collapseBranch_laterSiblingAndChildrenSelected FAILED > java.lang.AssertionError: > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at test.javafx.scene.control.TreeViewTest.test_rt27180_collapseBranch_laterSiblingAndChildrenSelected(TreeViewTest.java:973) > > test.javafx.scene.control.TreeViewTest > test_rt27180_expandBranch_laterSiblingSelected_singleSelection FAILED > java.lang.AssertionError: > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at test.javafx.scene.control.TreeViewTest.test_rt27180_expandBranch_laterSiblingSelected_singleSelection(TreeViewTest.java:992) > > > These would need to be investigated to see why they assume this order. Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. > .. sounds like a lot. Any idea, where exactly they come into play? ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From fastegal at openjdk.java.net Fri Mar 5 16:06:24 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 5 Mar 2021 16:06:24 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Tue, 25 Feb 2020 13:55:50 GMT, Nir Lisker wrote: > > > I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:06:28 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:06:28 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg wrote: >> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. > >> >> >> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. > > technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. In use cases where a large number of listeners are being discarded, it may be better to first consider changing the design to receive event notifications on nodes whose listener registrations are not frequently discarded. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at openjdk.java.net Fri Mar 5 16:06:31 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Mar 2021 16:06:31 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg wrote: > technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. So we can choose to specify it as ordered. These are the 2 options I mentioned: 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow applications to rely on the behavior safely. Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is unspecified and is planned to change in the future, so there will be at least some warning. Once we choose what to do here it will make sense to continue to review the code with that decision in mind. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:06:34 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:06:34 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> Message-ID: On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker wrote: >>> >>> >>> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by their registration order, or that is it unspecified, in which case we can take advantage of this for better performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides. >> >> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. > >> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically, we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal code does it .. > > So we can choose to specify it as ordered. > > These are the 2 options I mentioned: > 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as you've mentioned. > 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow applications to rely on the behavior safely. > > Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is unspecified and is planned to change in the future, so there will be at least some warning. > > Once we choose what to do here it will make sense to continue to review the code with that decision in mind. In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce the performance improvement. I have attached a test program in my PR(#125) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:06:37 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:06:37 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> Message-ID: On Mon, 2 Mar 2020 08:31:47 GMT, dannygonzalez wrote: >> Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: >> >>> I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. >>> >> >> .. sounds like a lot. Any idea, where exactly they come into play? > >> Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: >> >> > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. >> >> .. sounds like a lot. Any idea, where exactly they come into play? > > I did start to look at why there were so many change listeners unregistering but felt that would take a deeper understanding of the architecture and design decisions of JavaFX scene graph and I didn't have that time to invest. > I do know that there are thousands of them unregistering in a TableView and unregistering them is a bottleneck for the JavaFX thread. > > There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow. > > To get our application usable I profiled the code and saw this unregistering as a major bottleneck, hence why I looked at this more obvious solution. > > I'm happy to look at the problem from the other angle and happy to listen to suggestions from people with more experience of the design and architecture but tackling the problem from the perspective of re-architecting the behaviour of listeners in the scene graph would be more work than I could feasibly take on. @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:06:42 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:06:42 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> Message-ID: On Tue, 14 Apr 2020 12:20:10 GMT, John Hendrikx wrote: >>> Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: >>> >>> > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. >>> >>> .. sounds like a lot. Any idea, where exactly they come into play? >> >> I did start to look at why there were so many change listeners unregistering but felt that would take a deeper understanding of the architecture and design decisions of JavaFX scene graph and I didn't have that time to invest. >> I do know that there are thousands of them unregistering in a TableView and unregistering them is a bottleneck for the JavaFX thread. >> >> There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow. >> >> To get our application usable I profiled the code and saw this unregistering as a major bottleneck, hence why I looked at this more obvious solution. >> >> I'm happy to look at the problem from the other angle and happy to listen to suggestions from people with more experience of the design and architecture but tackling the problem from the perspective of re-architecting the behaviour of listeners in the scene graph would be more work than I could feasibly take on. > > @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". > > Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. > > As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. @hjohn I haven't quantified exactly where all the listeners are coming from but the Node class for example has various listeners on it. The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly (although it was still bad before this change in my previous tests): > commit e21606d3a1b73cd4b44383babc750a4b4721edfd > Author: Florian Kirmaier > > Date: Tue Jan 22 09:08:36 2019 -0800 > > 8216377: Fix memoryleak for initial nodes of Window > 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window > > Add or remove the windowShowingChangedListener when the scene changes As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant performance hit on the JavaFX thread. I don't have the time or knowledge to investigate why these listeners are all needed especially around the Node class. I went directly to the source of the problem which was the linear search to deregister each listener. I have been running my proposed fix in our JavaFX application for the past few months and it has saved it from being unusable due to the JavaFx thread being swamped. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:06:46 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:06:46 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> Message-ID: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez wrote: >> @dannygonzalez You mentioned "There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow.". >> >> Your changes in this PR seem to be focused on improving performance of unregistering listeners when there are thousands of listeners listening on changes or invalidations of the **same** property. Is this actually the case? Is there a single property in TableView or TreeTableView where such a high amount of listeners are present? If so, I think the problem should be solved there. >> >> As it is, I donot think this PR will help unregistration performance of listeners when the listeners are spread out over dozens of properties, and although high in total number, the total listeners per property would be low and their listener lists would be short. Performance of short lists (<50 entries) is almost unbeatable, so it is relevant for this PR to know if there are any properties with long listener lists. > > @hjohn > I haven't quantified exactly where all the listeners are coming from but the Node class for example has various listeners on it. > > The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly (although it was still bad before this change in my previous tests): > >> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >> Author: Florian Kirmaier > >> Date: Tue Jan 22 09:08:36 2019 -0800 >> >> 8216377: Fix memoryleak for initial nodes of Window >> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >> >> Add or remove the windowShowingChangedListener when the scene changes > > As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant performance hit on the JavaFX thread. > > I don't have the time or knowledge to investigate why these listeners are all needed especially around the Node class. I went directly to the source of the problem which was the linear search to deregister each listener. > > I have been running my proposed fix in our JavaFX application for the past few months and it has saved it from being unusable due to the JavaFx thread being swamped. The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. I think that it is necessary to reproduce it by testing first, but If you just focus on improving listener removal performance, If the lifespan of a large number of registered listeners is biased, It seems like the next simple change can improve delete performance without changing the data structure. * Change the search from the front of the list to the search from the back. This will reduce the number of long-life listeners matching. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:06:50 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:06:50 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> Message-ID: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> On Thu, 16 Apr 2020 06:34:39 GMT, yosbits wrote: >> @hjohn >> I haven't quantified exactly where all the listeners are coming from but the Node class for example has various listeners on it. >> >> The following changeset (which added an extra listener on the Node class) impacted TableView performance significantly (although it was still bad before this change in my previous tests): >> >>> commit e21606d3a1b73cd4b44383babc750a4b4721edfd >>> Author: Florian Kirmaier > >>> Date: Tue Jan 22 09:08:36 2019 -0800 >>> >>> 8216377: Fix memoryleak for initial nodes of Window >>> 8207837: Indeterminate ProgressBar does not animate if content is added after scene is set on window >>> >>> Add or remove the windowShowingChangedListener when the scene changes >> >> As you can imagine, a TableView with many columns and rows can be made up of many Node classes. The impact of having multiple listeners deregistering on the Node when new rows are being added to a TableView can be a significant performance hit on the JavaFX thread. >> >> I don't have the time or knowledge to investigate why these listeners are all needed especially around the Node class. I went directly to the source of the problem which was the linear search to deregister each listener. >> >> I have been running my proposed fix in our JavaFX application for the past few months and it has saved it from being unusable due to the JavaFx thread being swamped. > > The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. > > I think that it is necessary to reproduce it by testing first, but > > If you just focus on improving listener removal performance, > > If the lifespan of a large number of registered listeners is biased, > It seems like the next simple change can improve delete performance without changing the data structure. > > * Change the search from the front of the list to the search from the back. > > This will reduce the number of long-life listeners matching. Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes. A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us an idea how many Nodes we're talking about? 1000? 10.000? It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives? It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:06:55 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:06:55 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> Message-ID: On Thu, 16 Apr 2020 07:11:58 GMT, John Hendrikx wrote: >> The patch proposed here does not share the case where the listener deletion performance becomes a bottleneck. >> >> I think that it is necessary to reproduce it by testing first, but >> >> If you just focus on improving listener removal performance, >> >> If the lifespan of a large number of registered listeners is biased, >> It seems like the next simple change can improve delete performance without changing the data structure. >> >> * Change the search from the front of the list to the search from the back. >> >> This will reduce the number of long-life listeners matching. > > Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd > it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes. > > A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us an idea how many Nodes we're talking about? 1000? 10.000? > > It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives? It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change. The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there. No need for so many listeners. The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node). Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:01 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:01 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> Message-ID: On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx wrote: >> Looking at the commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd >> it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing` property. Each `Node` registers itself on those and so the listener lists for those properties would scale with the number of nodes. >> >> A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but I suppose it could be reproduced simply by having a large number of Nodes in a scene. @dannygonzalez could you give us an idea how many Nodes we're talking about? 1000? 10.000? >> >> It also means there might be other options, do Nodes really need to add these listeners and for which functionality and are there alternatives? It would also be possible to target only these specific properties with an optimized listener list to reduce the impact of this change. > > The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). > > A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there. No need for so many listeners. The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node). > > Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...) If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application. [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function. ![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:07:02 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:07:02 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> Message-ID: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> On Thu, 16 Apr 2020 08:24:16 GMT, dannygonzalez wrote: >> The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and `TreeVisible`, and are used to take various decisions like whether to play/pause animations. There is also a couple of listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`). >> >> A lot of the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility / showing status from there. No need for so many listeners. The other classes mentioned might register their own listener, instead of having `Node` do it for them (and thus impacting *every* node). >> >> Alternatively, `Node` may lazily register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty specific classes only, not classes that you'd see a lot in a TableView...) > > If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application. > > [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) > > If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function. > > ![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property. However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:10 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:10 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> Message-ID: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> On Thu, 16 Apr 2020 08:46:26 GMT, John Hendrikx wrote: >> If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using 61% of the JavaFX thread whilst running our application. >> >> [snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip) >> >> If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to see which classes are calling the removeListener function. >> >> ![Screenshot 2020-04-16 at 09 16 11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png) > > @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property. > > However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps. @hjohn I have 12136 change listeners when debugging our application as you suggested. Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue. It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:07:17 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:07:17 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Thu, 16 Apr 2020 09:45:20 GMT, dannygonzalez wrote: >> @dannygonzalez Could you perhaps debug your application and take a look at how large the following array is: a random node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` -> `changeListeners`. I just tested this with a custom control displaying 200 cells on screen at once (each cell consisting of about 30 nodes itself), and I saw about 20000 change listeners registered on this single Scene Window property. >> >> However, this custom control is not creating/destroying cells beyond the initial allocation, so there wouldn't be any registering and unregistering going on, scrolling was still smooth >30 fps. > > @hjohn I have 12136 change listeners when debugging our application as you suggested. > > Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue. > > It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. > The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with 20.000 nested stack panes resulted in these average times: - Add all 51 ms - Remove all 25 ms Versus the unmodified code: - Add all 34 ms - Remove all 135 ms However, there are some significant functional changes as well that might impact current users: 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to check whether an iteration was in progress. 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). The last point is not easily solved and could potentially cause problems. Finally I think this solution, although it performs well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window and have Scene provide a new combined status property that Node could use for its purposes. Even better however would be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener lists much shorter, which should scale a lot better. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:23 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:23 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Thu, 16 Apr 2020 16:15:20 GMT, John Hendrikx wrote: >> @hjohn I have 12136 change listeners when debugging our application as you suggested. >> >> Please note that I see the issue when the TableView is having items added to it. If you just have a static TableView I do not see the issue. >> >> It is only when you add items to the TableView which causes a myriad of listeners to be deregistered and registered. >> The Visual VM snapshot I attached above was taken as our application was adding items to the TableView. > > I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with 20.000 nested stack panes resulted in these average times: > > - Add all 51 ms > - Remove all 25 ms > > Versus the unmodified code: > > - Add all 34 ms > - Remove all 135 ms > > However, there are some significant functional changes as well that might impact current users: > > 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to check whether an iteration was in progress. > > 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). > > The last point is not easily solved and could potentially cause problems. > > Finally I think this solution, although it performs well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window and have Scene provide a new combined status property that Node could use for its purposes. > > Even better however would be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener lists much shorter, which should scale a lot better. @hjon > 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). Unless I'm missing something I don't think this is the case. I used a LinkedHashMap which preserved the order of notifications. Actually some unit tests failed if the notifications weren't carried out in the same order as registration which was the case when I used a HashMap. See here: https://github.com/openjdk/jfx/pull/108#issuecomment-590883183 @hjohn > 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to the hierarchy as you mentioned). This was mentioned here also: https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:07:32 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:07:32 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Fri, 17 Apr 2020 07:22:20 GMT, dannygonzalez wrote: >> I've tested this pull request locally a few times, and the performance improvement is quite significant. A test with 20.000 nested stack panes resulted in these average times: >> >> - Add all 51 ms >> - Remove all 25 ms >> >> Versus the unmodified code: >> >> - Add all 34 ms >> - Remove all 135 ms >> >> However, there are some significant functional changes as well that might impact current users: >> >> 1. The new code ensures that all listeners are notified even if the list is modified during iteration by always making a **copy** when an event is fired. The old code only did so when it was **actually** modified during iteration. This can be mitigated by making the copy in the code that modifies the list (as the original did) using the `locked` flag to check whether an iteration was in progress. >> >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by `Map.Entry` (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). >> >> 3. Even though the current version of this pull request takes care to notify duplicate listeners the correct amount of times, it does not notify them in the correct order with respect to other listeners. If one registers listeners (a, b, a) the notification order will be (a, a, b). >> >> The last point is not easily solved and could potentially cause problems. >> >> Finally I think this solution, although it performs well is not the full solution. A doubling or quadrupling of nodes would again run into serious limitations. I think this commit https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd should not have introduced another listener for each Node on the Window class. A better solution would be to only have the Scene listen to Window and have Scene provide a new combined status property that Node could use for its purposes. >> >> Even better however would be to change the properties involved to make use of the hierarchy naturally present in Nodes, having child nodes listen to their parent, and the top level node listen to the scene. This would reduce the amount of listeners on a single property in Scene and Window immensely, instead spreading those listeners over the Node hierarchy, keeping listener lists much shorter, which should scale a lot better. > > @hjohn > >> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). > > There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to the hierarchy as you mentioned). > This was mentioned here also: https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 I've implemented an alternative solution: Removing the listeners on `Window.showingProperty` and `Scene.windowProperty` completely. They are in fact only used in two places: `PopupWindow` in order to remove itself if the `Window` is no longer showing, and `ProgressIndicatorSkin`. These two can be easily replaced with their own listeners for these properties instead of burdening **all** nodes with these listeners only to support these two classes. I left the `isTreeShowing` method in, and implemented it simply as `isTreeVisible() && isWindowShowing()` as that's really the only difference between "visible" and "showing" apparently. Here is the test result with 20.000 nested StackPanes with only this change in: - Add all 45 ms - Remove all 25 ms I think this might be a good solution as it completely avoids these listeners. @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:38 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:38 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Fri, 17 Apr 2020 08:07:08 GMT, John Hendrikx wrote: >> @hjohn >> >>> 2. There is a significant increase in memory use. Where before each listener occupied an entry in an array, now each listener is wrapped by Map.Entry (the Integer instance used per entry can be disregarded). I estimate around 4-8x more heap will be consumed (the numbers are small however, still well below 1 MB for 20.000 entries). If this is an issue, a further level could be introduced in the listener implementation hierarchy (singleton -> array -> map). >> >> There was discussion about lazy initialisation of the LinkedHashMap when needed and/or have some sort of strategy where we could use arrays or lists if the number of listeners are less than some threshold (i.e. introducing another level to the hierarchy as you mentioned). >> This was mentioned here also: https://github.com/openjdk/jfx/pull/108#issuecomment-590838942 > > @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped off the hotspots in the same way it did with my pull request. I wasn't fully confident of making changes to the Node hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck which was the listener de-registration slowness. I do worry however that any changes down the road which add listeners to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. I feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I know my changes may be more fundamental and hence risky. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:07:44 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:07:44 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Fri, 17 Apr 2020 08:48:35 GMT, dannygonzalez wrote: >> @dannygonzalez I added a proof of concept here if you want to play with it: https://github.com/openjdk/jfx/pull/185 > > @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped off the hotspots in the same way it did with my pull request. > > I wasn't fully confident of making changes to the Node hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck which was the listener de-registration slowness. > > I do worry however that any changes down the road which add listeners to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. > I feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I know my changes may be more fundamental and hence risky. The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very limited cases, and its addition in the past may have slipped through the cracks. Adding a performance unit test that specifically checks add/remove performance of nodes may prevent such future regressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:51 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:51 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Fri, 17 Apr 2020 10:22:15 GMT, John Hendrikx wrote: >> @hjohn Thanks for looking into this. It looks like your changes do improve the issue with the JavaFX thread being swamped with listener de-registrations. Looking at the JavaFX thread in VisualVM, the removeListener call has dropped off the hotspots in the same way it did with my pull request. >> >> I wasn't fully confident of making changes to the Node hierarchy to remove listeners hence why I approached the issue from the other direction i.e. the obvious bottleneck which was the listener de-registration slowness. >> >> I do worry however that any changes down the road which add listeners to the Node hierarchy again without fully understanding the implications would lead us to the same point we are now where the slowness of listener de-registrations becomes an issue again. There are no tests that catch this scenario. >> I feel that ideally both solutions are needed but am happy to bow to the more experienced OpenJFX devs opinions here as I know my changes may be more fundamental and hence risky. > > The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very limited cases, and its addition in the past may have slipped through the cracks. > > Adding a performance unit test that specifically checks add/remove performance of nodes may prevent such future regressions. @hjohn, agreed regards the issues of adding a listener to each node. Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? I await any further comments from @kevinrushforth et al. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:07:55 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:07:55 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Fri, 17 Apr 2020 10:46:51 GMT, dannygonzalez wrote: >> The problem is that there are usually many nodes, but only very few scenes and windows, so registering a listener for each node on a scene or window is pretty bad design (also consider the amount of notifications that a scene change would trigger in such scenarios). As far as I can see, this is the only such listener and only needed for two very limited cases, and its addition in the past may have slipped through the cracks. >> >> Adding a performance unit test that specifically checks add/remove performance of nodes may prevent such future regressions. > > @hjohn, agreed regards the issues of adding a listener to each node. > > Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? > > I await any further comments from @kevinrushforth et al. I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jpereda at openjdk.java.net Fri Mar 5 16:08:00 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 5 Mar 2021 16:08:00 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Wed, 26 Aug 2020 14:08:37 GMT, dannygonzalez wrote: >> @hjohn, agreed regards the issues of adding a listener to each node. >> >> Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? >> >> I await any further comments from @kevinrushforth et al. > > I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. > > Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". > > [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: - this one #108, that tries to improve the performance of excessive number of `removeListener` calls - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. For the case presented, where new items are constantly added to the TableView, the trace of calls that reach `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) As can be seen, all those calls are triggered by the change of the number of cells in [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). Whenever the cell count changes there is this [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): sheetChildren.clear(); This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes used is given by `sheetChildren.size()`. This means that all the actual cells (nodes) that are used by the `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those calls to unregister those nodes from the scene that ultimately lead to remove the listeners with `ExpressionHelper.removeListener`. However, this seems unnecessary, as the number of actual cells/nodes doesn't change that much, and causes this very bad performance. On a quick test over the sample posted, just removing that line gives a noticeable improvement in performance.. There is a concern though due to the [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): // Fix for RT-13965: Without this line of code, the number of items in // the sheet would constantly grow, leaking memory for the life of the // application. This was especially apparent when the total number of // cells changes - regardless of whether it became bigger or smaller. sheetChildren.clear(); There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't constantly grow and there is no memory leak. Running the attached sample for a long time, and profiling with VisualVM, shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners wouldn't be modified). Thoughts and feedback are welcome. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:08:08 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:08:08 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote: >> I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. >> >> Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". >> >> [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) > > So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: > > - this one #108, that tries to improve the performance of excessive number of `removeListener` calls > - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. > > For the case presented, where new items are constantly added to the TableView, the trace of calls that reach `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: > > ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) > > As can be seen, all those calls are triggered by the change of the number of cells in [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). > > Whenever the cell count changes there is this [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): > > sheetChildren.clear(); > > This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes used is given by `sheetChildren.size()`. > > This means that all the actual cells (nodes) that are used by the `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those calls to unregister those nodes from the scene that ultimately lead to remove the listeners with `ExpressionHelper.removeListener`. > > However, this seems unnecessary, as the number of actual cells/nodes doesn't change that much, and causes this very bad performance. > > On a quick test over the sample posted, just removing that line gives a noticeable improvement in performance.. > > There is a concern though due to the [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): > > // Fix for RT-13965: Without this line of code, the number of items in > // the sheet would constantly grow, leaking memory for the life of the > // application. This was especially apparent when the total number of > // cells changes - regardless of whether it became bigger or smaller. > sheetChildren.clear(); > > There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't constantly grow and there is no memory leak. > > Running the attached sample for a long time, and profiling with VisualVM, shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. > > So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners wouldn't be modified). > > Thoughts and feedback are welcome. I confirmed the sample code (JavaFX Sluggish), This is not scroll performance It seems to reproduce the additional performance issue. Therefore, it is not considered appropriate as a fix for JDK-8185886. I know you are reproducing another performance issue, but I'm proposing to fix scrolling performance issues in #125. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From jhendrikx at openjdk.java.net Fri Mar 5 16:08:13 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 5 Mar 2021 16:08:13 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Wed, 26 Aug 2020 17:44:20 GMT, yosbits wrote: >> So far, there are two alternative fixes for the bad performance issue while scrolling TableView/TreeTableViews: >> >> - this one #108, that tries to improve the performance of excessive number of `removeListener` calls >> - the WIP #185 that avoids registering two listeners (on Scene and on Window) for each and every Node. >> >> For the case presented, where new items are constantly added to the TableView, the trace of calls that reach `com.sun.javafx.binding.ExpressionHelper.removeListener()` is something like this: >> >> ![TraceOpenJFX16ea1](https://user-images.githubusercontent.com/2043230/91322208-c2ba9900-e7bf-11ea-8918-cdbecd457cf2.png) >> >> As can be seen, all those calls are triggered by the change of the number of cells in [VirtualFlow::setCellCount](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L804). >> >> Whenever the cell count changes there is this [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L843): >> >> sheetChildren.clear(); >> >> This happens every time the number of items in the `TableView` changes, as the `VirtualFlow` keeps track of the number of virtual cells (`cellCount` is the total number of items) while the number of actual cells or number of visible nodes used is given by `sheetChildren.size()`. >> >> This means that all the actual cells (nodes) that are used by the `VirtualFlow` are disposed and recreated all over again every time the number of items changes, triggering all those calls to unregister those nodes from the scene that ultimately lead to remove the listeners with `ExpressionHelper.removeListener`. >> >> However, this seems unnecessary, as the number of actual cells/nodes doesn't change that much, and causes this very bad performance. >> >> On a quick test over the sample posted, just removing that line gives a noticeable improvement in performance.. >> >> There is a concern though due to the [comment](https://github.com/openjdk/jfx/blob/master/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L839): >> >> // Fix for RT-13965: Without this line of code, the number of items in >> // the sheet would constantly grow, leaking memory for the life of the >> // application. This was especially apparent when the total number of >> // cells changes - regardless of whether it became bigger or smaller. >> sheetChildren.clear(); >> >> There are some methods in VirtualFlow that already manage the lifecycle of this list of nodes (clear, remove cells, add cells, ...), so I don't think that is the case anymore for that comment: the number of items in the sheet doesn't constantly grow and there is no memory leak. >> >> Running the attached sample for a long time, and profiling with VisualVM, shows improved performance (considerable drop in CPU usage), and no issues regarding memory usage. >> >> So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but wouldn't have any impact in the rest of controls as the other two options (as `ExpressionHelper` or `Node` listeners wouldn't be modified). >> >> Thoughts and feedback are welcome. > > I confirmed the sample code (JavaFX Sluggish), > This is not scroll performance > It seems to reproduce the additional performance issue. > Therefore, it is not considered appropriate as a fix for JDK-8185886. > I know you are reproducing another performance issue, but > I'm proposing to fix scrolling performance issues in #125. The https://github.com/openjdk/jfx/pull/185 is a full fix, not a WIP. It avoids registering the listeners on Scene and Window and moves the only uses of those listeners to their respective controls, PopupWindow and ProgressIndicatorSkin (the property involved is internal, so there is no risk of affecting 3rd parties). Please have a closer look. I updated the title to make it more clear it is no longer a WIP, unless someone has review comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:08:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:13 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote: > So I'd like to propose this third alternative, which would affect only VirtualFlow and the controls that use it, but wouldn't have any impact in the rest of controls as the other two options (as ExpressionHelper or Node listeners wouldn't be modified). Given PR #185, which was mentioned above, (it isn't out for review yet, but I want to evaluate it), this would be a 4th approach. As long as this really doesn't introduce a leak, it seems promising. I note that these are not mutually exclusive. We should discuss this on the list and not just in one or more of of the 3 (soon to be 4) open pull requests. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:08:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:19 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: On Wed, 26 Aug 2020 14:08:37 GMT, dannygonzalez wrote: >> @hjohn, agreed regards the issues of adding a listener to each node. >> >> Would it be worth doing the additional work of updating PopupWindow and ProgressIndicatorSkin to add their own listeners to make this a pull request that can be reviewed officially? >> >> I await any further comments from @kevinrushforth et al. > > I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. > > Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". > > [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: 8252936: Optimize removal of listeners from ExpressionHelper.Generic ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:08:24 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:08:24 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> Message-ID: <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> On Tue, 8 Sep 2020 20:14:48 GMT, Kevin Rushforth wrote: >> I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM and look at the hotspots in the JavaFX thread, you can see that about 45% of the time in the JavaFX thread is spent in removeListener calls. >> >> Note: In CPU settings of VisualVM, I removed all packages from the "Do not profile packages section". >> >> [JavaFXSluggish.java.zip](https://github.com/openjdk/jfx/files/5130298/JavaFXSluggish.java.zip) > > @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: > > 8252936: Optimize removal of listeners from ExpressionHelper.Generic Thanks @kevinrushforth, I've changed the title. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:08:29 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:08:29 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2OiqSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> Message-ID: On Wed, 9 Sep 2020 06:53:11 GMT, dannygonzalez wrote: >> @dannygonzalez Per [this message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html) on the openjfx-dev mailing list, I have filed a new JBS issue for this PR to use. Please change the title to: >> >> 8252936: Optimize removal of listeners from ExpressionHelper.Generic > > Thanks @kevinrushforth, I've changed the title. I have found that fixing this rudimentary problematic code alleviates your problem. **This fix will reduce CPU usage by about 1/3 without your changes.** **This fix improves performance in many widespread use cases.** However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue for a rudimentary issue? @kevinrushforth What should i do? https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 Rewritten so that BitSet is not used. Java @Override public boolean removeAll(Collection c) { if(this.isEmpty() || c.isEmpty()){ return false; } beginChange(); boolean removed = false; for (int i = size()-1; i>=0; i--) { if (c.contains(get(i))) { remove(i); removed = true; } } endChange(); return removed; } @Override public boolean retainAll(Collection c) { if(this.isEmpty() || c.isEmpty()){ return false; } beginChange(); boolean retained = false; for (int i = size()-1; i>=0; i--) { if (!c.contains(get(i))) { remove(i); retained = true; } } endChange(); return retained; } ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:08:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:08:36 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> Message-ID: On Thu, 10 Sep 2020 09:48:07 GMT, yosbits wrote: >> Thanks @kevinrushforth, I've changed the title. > > I have found that fixing this rudimentary problematic code alleviates your problem. > > **This fix will reduce CPU usage by about 1/3 without your changes.** > **This fix improves performance in many widespread use cases.** > > However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue for a rudimentary issue? > > @kevinrushforth What should i do? > > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 > > Rewritten so that BitSet is not used. > Java > @Override > public boolean removeAll(Collection c) { > if(this.isEmpty() || c.isEmpty()){ > return false; > } > beginChange(); > boolean removed = false; > for (int i = size()-1; i>=0; i--) { > if (c.contains(get(i))) { > remove(i); > removed = true; > } > } > endChange(); > return removed; > } > > @Override > public boolean retainAll(Collection c) { > if(this.isEmpty() || c.isEmpty()){ > return false; > } > beginChange(); > boolean retained = false; > for (int i = size()-1; i>=0; i--) { > if (!c.contains(get(i))) { > remove(i); > retained = true; > } > } > endChange(); > return retained; > } @yososs Please file a new JBS issue for this. You will need to prove that your proposed change is functionally equivalent (or that any perceived changes are incidental and still conform to the spec). You should also think about whether your proposed change needs additional tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+7517141+yososs at openjdk.java.net Fri Mar 5 16:08:42 2021 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Fri, 5 Mar 2021 16:08:42 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com> <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com> <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com> <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com> <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com> Message-ID: On Thu, 10 Sep 2020 13:41:00 GMT, Kevin Rushforth wrote: >> I have found that fixing this rudimentary problematic code alleviates your problem. >> >> **This fix will reduce CPU usage by about 1/3 without your changes.** >> **This fix improves performance in many widespread use cases.** >> >> However, I'm wondering how to report the problem. Should it be handled in this issue? Should I deal with a new issue for a rudimentary issue? >> >> @kevinrushforth What should i do? >> >> https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java#L170-L206 >> >> Rewritten so that BitSet is not used. >> Java >> @Override >> public boolean removeAll(Collection c) { >> if(this.isEmpty() || c.isEmpty()){ >> return false; >> } >> beginChange(); >> boolean removed = false; >> for (int i = size()-1; i>=0; i--) { >> if (c.contains(get(i))) { >> remove(i); >> removed = true; >> } >> } >> endChange(); >> return removed; >> } >> >> @Override >> public boolean retainAll(Collection c) { >> if(this.isEmpty() || c.isEmpty()){ >> return false; >> } >> beginChange(); >> boolean retained = false; >> for (int i = size()-1; i>=0; i--) { >> if (!c.contains(get(i))) { >> remove(i); >> retained = true; >> } >> } >> endChange(); >> return retained; >> } > > @yososs Please file a new JBS issue for this. You will need to prove that your proposed change is functionally equivalent (or that any perceived changes are incidental and still conform to the spec). You should also think about whether your proposed change needs additional tests. Because it is such a small correction Problem from me I feel that it is not easy to register, but I will try to register. It has passed two existing tests for compatibility: * gradle base:test * gradle controls:test I have just reported it as an enhancement proposal. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at openjdk.java.net Fri Mar 5 16:09:02 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Mar 2021 16:09:02 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: Message-ID: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> On Thu, 6 Feb 2020 16:13:33 GMT, dannygonzalez wrote: > https://bugs.openjdk.java.net/browse/JDK-8185886 > > Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. > > This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. > > This may alleviate some of the issues seen here: > > TableView has a horrific performance with many columns #409 > https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 > > JDK-8088394 : Huge memory consumption in TableView with too many columns > JDK-8166956: JavaFX TreeTableView slow scroll performance > JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction > > OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 283: > 281: // while the observers are being notified is safe > 282: final Map curInvalidationList = new LinkedHashMap<>(invalidationListeners); > 283: final Map, Integer> curChangeList = new LinkedHashMap<>(changeListeners); You only need the entry set, so you don't need to copy the map, just the set. modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 285: > 283: final Map, Integer> curChangeList = new LinkedHashMap<>(changeListeners); > 284: > 285: curInvalidationList.entrySet().forEach(entry -> fireInvalidationListeners(entry)); The lambda can be converted to a method reference. modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelperBase.java line 64: > 62: ((WeakListener)t).wasGarbageCollected(); > 63: > 64: listeners.entrySet().removeIf(e -> p.test(e.getKey())); This can be `listeners.keySet().removeIf(p::test);`. modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 197: > 195: private T currentValue; > 196: private int weakChangeListenerGcCount = 2; > 197: private int weakInvalidationListenerGcCount = 2; Why are these set to 2 and why do you need them at all? The previous implementation needed to grow and shrink the array so it had to keep these, but `Map` takes care of this for you. modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 194: > 192: > 193: private Map invalidationListeners = new LinkedHashMap<>(); > 194: private Map, Integer> changeListeners = new LinkedHashMap<>(); Two comments on this: 1. The old implementation initialized these lazily, so we might want to preserve that behavior. I think it is reasonable since in most cases an observable won't have both types of listeners attached to it. 2. Since we're dealing wither performance optimizations here, we should think about what the `initialCapcity` and `loadFactor` of these maps should be, as it can greatly increase performance when dealing with a large amount of entries. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:09:19 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:09:19 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 09:59:28 GMT, Nir Lisker wrote: >> As far as I know a LinkedHashMap doesn't automatically remove weak listener entries. The listener maps can be holding weak listeners as well as normal listeners. >> So we need to keep the original behaviour from before where a count was checked on every addListener call and the weak references were purged from the array using the original calculation for this count. >> Otherwise the map would never garbage collect these weak references. >> >> The initial value of 2 for these counts was just the starting count although this is not necessarily strictly accurate. To be completely accurate then we would have to set the appropriate count in each constructor as follows: >> >> i.e. in the Constructor with 2 InvalidationListeners: >> weakChangeListenerGcCount = 0 >> weakInvalidationListenerGcCount = 2 >> >> in the Constructor with 2 ChangeListeners: >> weakChangeListenerGcCount = 2 >> weakInvalidationListenerGcCount = 0 >> >> in the Constructor with 1 InvalidationListener and 1 ChangeListener: >> weakChangeListenerGcCount = 1 >> weakInvalidationListenerGcCount = 1 >> >> Now, I could have used a WeakHashMap to store the listeners where it would automatically purge weak listeners but this doesn't maintain insertion order. Even though the specification doesn't mandate that listeners should be called back in the order they are registered, the unit tests failed when I didn't maintain order. >> >> I am happy to remove this weak listener purge code (as it would make the code much simpler) but then we wouldn't automatically remove the weak listeners, but this may not be deemed a problem anyway? > >> So we need to keep the original behaviour from before where a count was checked on every addListener call and the weak references were purged from the array using the original calculation for this count. > > The GC'd weak listeners do need to be purged, but why is the original behavior of the counters still applicable? Just wanted to keep a similar behaviour as before using the same calculation based originally on the size of the listeners array list and now based on the size of the map. So in theory the weak listeners should be trimmed at the same rate as before. Happy to hear alternatives. >> Nope, actually: >> `listeners.keySet().removeIf(p::test) ` >> >> is not the same as: >> `listeners.entrySet().removeIf(e -> p.test(e.getKey()));` >> >> We need to test against the entrySet.key not the entrySet itself. > >> We need to test against the entrySet.key not the entrySet itself. > > I suggested to test against the elements in `keySet()`, which are the same as the ones in `entrySet().getKey()`. Gotcha, sorry I missed that. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at openjdk.java.net Fri Mar 5 16:09:18 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Mar 2021 16:09:18 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 09:14:51 GMT, dannygonzalez wrote: > So we need to keep the original behaviour from before where a count was checked on every addListener call and the weak references were purged from the array using the original calculation for this count. The GC'd weak listeners do need to be purged, but why is the original behavior of the counters still applicable? > We need to test against the entrySet.key not the entrySet itself. I suggested to test against the elements in `keySet()`, which are the same as the ones in `entrySet().getKey()`. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:09:16 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:09:16 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 08:14:02 GMT, dannygonzalez wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 197: >> >>> 195: private T currentValue; >>> 196: private int weakChangeListenerGcCount = 2; >>> 197: private int weakInvalidationListenerGcCount = 2; >> >> Why are these set to 2 and why do you need them at all? The previous implementation needed to grow and shrink the array so it had to keep these, but `Map` takes care of this for you. > > I agree, I kept these in as I wasn't sure if there was a need to manually force the garbage collection of weak listeners at the same rate as the original implementation. > Removing this would make sense to me also. > > Updated my thoughts on this, see my comments below. As far as I know a LinkedHashMap doesn't automatically remove weak listener entries. The listener maps can be holding weak listeners as well as normal listeners. So we need to keep the original behaviour from before where a count was checked on every addListener call and the weak references were purged from the array using the original calculation for this count. Otherwise the map would never garbage collect these weak references. The initial value of 2 for these counts was just the starting count although this is not necessarily strictly accurate. To be completely accurate then we would have to set the appropriate count in each constructor as follows: i.e. in the Constructor with 2 InvalidationListeners: weakChangeListenerGcCount = 0 weakInvalidationListenerGcCount = 2 in the Constructor with 2 ChangeListeners: weakChangeListenerGcCount = 2 weakInvalidationListenerGcCount = 0 in the Constructor with 1 InvalidationListener and 1 ChangeListener: weakChangeListenerGcCount = 1 weakInvalidationListenerGcCount = 1 Now, I could have used a WeakHashMap to store the listeners where it would automatically purge weak listeners but this doesn't maintain insertion order. Even though the specification doesn't mandate that listeners should be called back in the order they are registered, the unit tests failed when I didn't maintain order. I am happy to remove this weak listener purge code (as it would make the code much simpler) but then we wouldn't automatically remove the weak listeners, but this may not be deemed a problem anyway? >> modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelperBase.java line 64: >> >>> 62: ((WeakListener)t).wasGarbageCollected(); >>> 63: >>> 64: listeners.entrySet().removeIf(e -> p.test(e.getKey())); >> >> This can be `listeners.keySet().removeIf(p::test);`. > > Agreed, will change. Nope, actually: `listeners.keySet().removeIf(p::test) ` is not the same as: `listeners.entrySet().removeIf(e -> p.test(e.getKey()));` We need to test against the entrySet.key not the entrySet itself. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From nlisker at openjdk.java.net Fri Mar 5 16:09:21 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 5 Mar 2021 16:09:21 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 11:04:26 GMT, dannygonzalez wrote: >> Just wanted to keep a similar behaviour as before using the same calculation based originally on the size of the listeners array list and now based on the size of the map. So in theory the weak listeners should be trimmed at the same rate as before. >> Happy to hear alternatives. > > Also bear in mind that the trimming of weak listeners is extremely slow as it has to iterate through each listener performing the weak listener test. We can't call this every time we add a listener as this would lock up the JavaFX thread completely (I tried it). > I assume this is why the original calculation was used where it backs of the rate the weak listener trimming code was called as the array list grew. I honestly don't quite understand the old cleanup behavior of `(oldCapacity * 3)/2 + 1`. Why is it grown by x1.5? In your tests, can you try to change the cleanup threshold to higher and lower values and see what differences you get? At the very least, the initial values of the counters should be set according to the specific constructor used. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From kcr at openjdk.java.net Fri Mar 5 16:09:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Mar 2021 16:09:23 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 23:45:03 GMT, Nir Lisker wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185886 >> >> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. >> >> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. >> >> This may alleviate some of the issues seen here: >> >> TableView has a horrific performance with many columns #409 >> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 >> >> JDK-8088394 : Huge memory consumption in TableView with too many columns >> JDK-8166956: JavaFX TreeTableView slow scroll performance >> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction >> >> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html > > modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 194: > >> 192: >> 193: private Map invalidationListeners = new LinkedHashMap<>(); >> 194: private Map, Integer> changeListeners = new LinkedHashMap<>(); > > Two comments on this: > > 1. The old implementation initialized these lazily, so we might want to preserve that behavior. I think it is reasonable since in most cases an observable won't have both types of listeners attached to it. > 2. Since we're dealing wither performance optimizations here, we should think about what the `initialCapcity` and `loadFactor` of these maps should be, as it can greatly increase performance when dealing with a large amount of entries. Adding to this, we need to ensure that the simple case of a few listeners doesn't suffer memory bloat. It may make sense to initially allocate a Map with a small capacity and load factor, and then reallocate it if someone adds more than a certain number of listeners. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:09:11 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:09:11 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Sun, 23 Feb 2020 01:05:25 GMT, Nir Lisker wrote: >> https://bugs.openjdk.java.net/browse/JDK-8185886 >> >> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed. >> >> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews. >> >> This may alleviate some of the issues seen here: >> >> TableView has a horrific performance with many columns #409 >> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033 >> >> JDK-8088394 : Huge memory consumption in TableView with too many columns >> JDK-8166956: JavaFX TreeTableView slow scroll performance >> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction >> >> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html > > modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 283: > >> 281: // while the observers are being notified is safe >> 282: final Map curInvalidationList = new LinkedHashMap<>(invalidationListeners); >> 283: final Map, Integer> curChangeList = new LinkedHashMap<>(changeListeners); > > You only need the entry set, so you don't need to copy the map, just the set. Thanks, yes the EntrySet would make more sense here. I'll fix that up. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 285: > >> 283: final Map, Integer> curChangeList = new LinkedHashMap<>(changeListeners); >> 284: >> 285: curInvalidationList.entrySet().forEach(entry -> fireInvalidationListeners(entry)); > > The lambda can be converted to a method reference. Agreed, I'll fix. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelperBase.java line 64: > >> 62: ((WeakListener)t).wasGarbageCollected(); >> 63: >> 64: listeners.entrySet().removeIf(e -> p.test(e.getKey())); > > This can be `listeners.keySet().removeIf(p::test);`. Agreed, will change. > modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 197: > >> 195: private T currentValue; >> 196: private int weakChangeListenerGcCount = 2; >> 197: private int weakInvalidationListenerGcCount = 2; > > Why are these set to 2 and why do you need them at all? The previous implementation needed to grow and shrink the array so it had to keep these, but `Map` takes care of this for you. I agree, I kept these in as I wasn't sure if there was a need to manually force the garbage collection of weak listeners at the same rate as the original implementation. Removing this would make sense to me also. Updated my thoughts on this, see my comments below. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:09:21 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:09:21 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: On Mon, 24 Feb 2020 10:16:55 GMT, dannygonzalez wrote: >>> So we need to keep the original behaviour from before where a count was checked on every addListener call and the weak references were purged from the array using the original calculation for this count. >> >> The GC'd weak listeners do need to be purged, but why is the original behavior of the counters still applicable? > > Just wanted to keep a similar behaviour as before using the same calculation based originally on the size of the listeners array list and now based on the size of the map. So in theory the weak listeners should be trimmed at the same rate as before. > Happy to hear alternatives. Also bear in mind that the trimming of weak listeners is extremely slow as it has to iterate through each listener performing the weak listener test. We can't call this every time we add a listener as this would lock up the JavaFX thread completely (I tried it). I assume this is why the original calculation was used where it backs of the rate the weak listener trimming code was called as the array list grew. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:09:27 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:09:27 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <4tfk4L9Ilj9ZSYFAcDdAqPZ_KV6Bpggbb_q_Of6GMqY=.245fbeea-935b-4f74-96da-1c0ea4e1bf68@github.com> Message-ID: <2xJupVJ8yVfGmT067-IDqMCujwOFu40bCsTtubaVyfg=.d028adb4-17aa-461e-9286-b328f8ffeb4c@github.com> On Tue, 25 Feb 2020 00:45:06 GMT, Kevin Rushforth wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/binding/ExpressionHelper.java line 194: >> >>> 192: >>> 193: private Map invalidationListeners = new LinkedHashMap<>(); >>> 194: private Map, Integer> changeListeners = new LinkedHashMap<>(); >> >> Two comments on this: >> >> 1. The old implementation initialized these lazily, so we might want to preserve that behavior. I think it is reasonable since in most cases an observable won't have both types of listeners attached to it. >> 2. Since we're dealing wither performance optimizations here, we should think about what the `initialCapcity` and `loadFactor` of these maps should be, as it can greatly increase performance when dealing with a large amount of entries. > > Adding to this, we need to ensure that the simple case of a few listeners doesn't suffer memory bloat. It may make sense to initially allocate a Map with a small capacity and load factor, and then reallocate it if someone adds more than a certain number of listeners. Agree with the lazy initialisation and the initial setting of capacity and load factor to reduce memory footprint unless it's needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From github.com+6702882+dannygonzalez at openjdk.java.net Fri Mar 5 16:06:28 2021 From: github.com+6702882+dannygonzalez at openjdk.java.net (dannygonzalez) Date: Fri, 5 Mar 2021 16:06:28 GMT Subject: RFR: 8252936: Optimize removal of listeners from ExpressionHelper.Generic In-Reply-To: References: <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com> <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com> <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com> Message-ID: On Wed, 26 Feb 2020 09:49:04 GMT, Jeanette Winzenburg wrote: > Hmm .. personally, I would consider changing such a basic (and probably highly optimized) implementation used all over the framework is a very high risk change that at the worst outcome would detoriate internal and external code. So before going that lane, I would try - as you probably have, just me not seeing it :) - to tackle the problem from the other end: > > > I know that in our application, the **thousands of listeners** unregistering when using a TableView was stalling the JavaFX thread. > > .. sounds like a lot. Any idea, where exactly they come into play? I did start to look at why there were so many change listeners unregistering but felt that would take a deeper understanding of the architecture and design decisions of JavaFX scene graph and I didn't have that time to invest. I do know that there are thousands of them unregistering in a TableView and unregistering them is a bottleneck for the JavaFX thread. There are multiple change listeners on a Node for example, so you can imagine with the number of nodes in a TableView this is going to be a problem if the unregistering is slow. To get our application usable I profiled the code and saw this unregistering as a major bottleneck, hence why I looked at this more obvious solution. I'm happy to look at the problem from the other angle and happy to listen to suggestions from people with more experience of the design and architecture but tackling the problem from the perspective of re-architecting the behaviour of listeners in the scene graph would be more work than I could feasibly take on. ------------- PR: https://git.openjdk.java.net/jfx/pull/108 From martin at martinfox.com Fri Mar 5 17:19:50 2021 From: martin at martinfox.com (Martin Fox) Date: Fri, 5 Mar 2021 09:19:50 -0800 Subject: Mac key event code and accelerator fixes Message-ID: I?m working on fixing some of the long-standing Mac bugs related to key codes and accelerator key processing. KeyCodeCombination and KeyCharacterCombination are failing for different reasons but I think I have a roadmap for fixing both. The relevant JDK bugs that I could find are listed below. These bugs also tend to generate a lot of duplicate bugs entered against various Mac apps built using JavaFX, I could easily pull more than five out of the Defold issues list. Is anyone else working on this at the moment? These bugs are all unassigned and most are years old. Thanks, Martin Fox https://bugs.openjdk.java.net/browse/JDK-8090257 https://bugs.openjdk.java.net/browse/JDK-8134723 https://bugs.openjdk.java.net/browse/JDK-8088120 https://bugs.openjdk.java.net/browse/JDK-8087915 https://bugs.openjdk.java.net/browse/JDK-8092396 https://bugs.openjdk.java.net/browse/JDK-8134723 https://bugs.openjdk.java.net/browse/JDK-8090257 https://bugs.openjdk.java.net/browse/JDK-8087486 https://bugs.openjdk.java.net/browse/JDK-8089894 From arapte at openjdk.java.net Fri Mar 5 17:42:29 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 5 Mar 2021 17:42:29 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v2] In-Reply-To: References: <1XxY-iJq1cWXvIkgJOM_waH8Ve_KoNDwfKEqphSUeJ8=.7666e389-ef43-4ff4-a36e-87e3f4ae3b1d@github.com> Message-ID: On Thu, 4 Mar 2021 21:56:49 GMT, Kevin Rushforth wrote: > 1. The new method is only needed for Labeled because of the way it constructs the child graph, right? Is there anything that would preclude some other control from using this in the future, if a similar situation would arise? Yes, new method is needed only because the font size property is shared between parent(Labeled) and child(LabeledText) control. Given that method only recalculates relatively sized properties, I can't think of anything that would preclude it from reuse. > 2. Have you done any performance testing to ensure that there are no regressions? I wouldn't think there would be, given that this only applies the fix when the size of a Labeled control changes. I did a performance test today using 10,000 Label controls. The program is attached to JBS. The readings show that performance does reduce by a some amount. Following are the 10 time(in ms) readings(each is an average of 25 readings) of time taken for onShown listener of a Stage to be executed with 10,000 Labels with relatively sized properties. Time taken to show stage without this change is around 960 ms and with change it is around 1090 ms. Looks like an average increase by 130 ms for 10,000 Labels. Time in ms: With this change: 1098.04 1114.08 1081.88 1099.76 1081.52 1104.80 1088.48 1079.44 1097.84 1083.40 Without change: 967.96 951.04 964.76 1040.92 932.64 985.68 948.96 960.64 961.64 952.88 Also a point to note is that, this scenario occurs only when the sizes are provided such that Label's and LabeledText's font size does not match. otherwise the recalculation of properties does not happen and performance remains same. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 630: > >> 628: ParsedValue resolved = resolveLookups(node, cssValue, styleMap, transitionStates[0], whence, new HashSet<>()); >> 629: boolean isRelative = ParsedValueImpl.containsFontRelativeSize(resolved, false); >> 630: if (!isRelative) { > > Is it possible to have a property that is absolute with sub-properties that might be relative? If so, then I think you need to add a check for `numSubProperties == 0` so you don't skip this case. I referred the [css ref](https://openjfx.io/javadoc/15/javafx.graphics/javafx/scene/doc-files/cssref.html) document which records the Available CSS Properties tables for different controls. I could find that only two css properties of region have sub properties `-fx-region-background` and `-fx-region-border`. No other control has a css property with sub properties. None of these two region css properties can be directly specified in css style but they are created using any of their sub properties if specified. Because these two properties cannot be set from css the code flow does not enter the `if (style != null)` block. So it seems safe to me to proceed without sub properties check in the if block. I also verified by printing the css properties and only two of these properties shown to have sub properties. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 707: > >> 705: } >> 706: >> 707: private boolean transitionStateInProgress = false; > > Minor: I recommend a blank line here. Corrected. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 664: > >> 662: >> 663: if (originOfCalculatedValue == null) { >> 664: assert false : styleableProperty.toString(); > > We don't generally use `assert` in our code (although I see this part is copied from the original method, so I understand if you prefer to leave it). Removed assert. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 603: > >> 601: for (int n = 0; n < numStyleables; n++) { >> 602: >> 603: final CssMetaData cssMetaData = > > This may need the ` @SuppressWarnings("unchecked")` annotation, as done in the original method. Added back the annotation. > modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 337: > >> 335: System.err.println("p2FontSize: " + p2FontSize); >> 336: System.err.println("p3FontSize: " + p3FontSize); >> 337: System.err.println("p4FontSize: " + p4FontSize); > > Are you planning to leave these print statements in? It seems like noise now that you are done debugging the test. They are removed now, I overlooked when cleaning up. > modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 224: > >> 222: double p2FontSize = rootFontSize * 0.7; >> 223: double p3FontSize = p1FontSize * 0.6; >> 224: double p4FontSize = p2FontSize * 0.5; > > Is it worth a note that the expected font size is relative to the node's grandparent if both the node and its parent are relative? This is one of the oddities of font size that we are (intentionally) preserving, so it seems worth documenting it. Especially given your comment on the next test (the one that is `@Ignore`d). Added a comment to explain the behavior. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 578: > >> 576: // Currently this method is executed only by Labeled.fontProperty().set(), when it's font size >> 577: // is changed by LabeledText. >> 578: void recalculateRelativeSizeProperties(final Node node, Font fontForRelativeSizes) { > > Given the tricky nature of this fix, I would like to see a little more description in the comment explaining why it is needed and how it works. Specifically, it should say why the originally calculated value is incorrect, and indicate that a second pass is needed for certain cases. Updated the comment with more details. ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Fri Mar 5 17:42:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 5 Mar 2021 17:42:25 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v3] In-Reply-To: References: Message-ID: <21wLrCS2heJDc0KY1ArezzhqooS7a-E9UMSfi_2ZVyk=.f37770d8-3c77-4aab-a207-fb3b23189ec9@github.com> > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - update to address review - Merge branch 'master' into 8204568_css_relative_size - update to recalculate properties when font size changes - fix and test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/397/files - new: https://git.openjdk.java.net/jfx/pull/397/files/816304de..1b17d26a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=01-02 Stats: 2293 lines in 85 files changed: 1874 ins; 240 del; 179 mod Patch: https://git.openjdk.java.net/jfx/pull/397.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397 PR: https://git.openjdk.java.net/jfx/pull/397 From kcr at openjdk.java.net Sat Mar 6 01:50:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 6 Mar 2021 01:50:07 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v3] In-Reply-To: <21wLrCS2heJDc0KY1ArezzhqooS7a-E9UMSfi_2ZVyk=.f37770d8-3c77-4aab-a207-fb3b23189ec9@github.com> References: <21wLrCS2heJDc0KY1ArezzhqooS7a-E9UMSfi_2ZVyk=.f37770d8-3c77-4aab-a207-fb3b23189ec9@github.com> Message-ID: On Fri, 5 Mar 2021 17:42:25 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - update to address review > - Merge branch 'master' into 8204568_css_relative_size > - update to recalculate properties when font size changes > - fix and test Thanks for the response to the performance question. For the stress test you added, the performance hit seems reasonable to achieve correct rendering behavior. Especially since it is only applied for those cases where needed and only the first time, or when the font size changes. I left a few wording suggestions inline. modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 220: > 218: > 219: // When a Parent and its Parent's font size is relative then that Parent's > 220: // font size is computed in relative to it's grand parent's font size. Very mInor: grandparent is one word (I only mention in case there are other changes you are making at the same time). modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 256: > 254: // This should have been the behavior of font size calculation with nested > 255: // set of parents and controls, that a Parent's font size is calculated with reference > 256: // to its Parent and not grand parent. We are not changing current behaviour to avoid Very minor: grandparent. Also very minor: you use both behavior and behaviour in this paragraph. Since this isn't public docs, I don't care which one you use, but you might want to pick one and stick with it. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 574: > 572: } > 573: > 574: // The font size property of the Controls that are inherited from class Labeled is a shared a property, Extra "a" here: "is a shared a property" --> "is a shared property" modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 577: > 575: // it is shared with a child LabeledText. The Control's(inherited from Labeled) css properties are > 576: // first computed relative to the font size that was computed for the Control. And when the font size > 577: // is computed for LabeledText, it computes a different font size(which is not same as what was computed for Control). Minor: add a space before the `(` here in the line above. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 584: > 582: // is changed by LabeledText. > 583: // This method is a reduced version of transitionToState() method, it is added as a fix for JDK-8204568. > 584: // Any modifications to the method transitionToStates() should be relatively applied here if needed. I might drop the word "relatively" since it could be confusing (with relative font size). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/397 From org.openjdk at io7m.com Sat Mar 6 12:21:35 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sat, 6 Mar 2021 12:21:35 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210215134043.09b57608@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> Message-ID: <20210306122135.06963b52@sunflower.int.arc7.info> On 2021-02-15T13:40:43 +0000 Mark Raynsford wrote: > Hello! > > I'd like to use JavaFX for the UI of an application that will > involve rendering using an existing Vulkan-based renderer. For the sake > of example, assume that the application looks and behaves a bit like > the Unreal Engine 4 editing tools.... Apologies for the delay in responding (I've read and digested every reply). So... Having read everything, I'm reasonably sure that the ability to do this in the "traditional" way - that is, having a node in the JavaFX scene graph that displays the contents of a GPU-side image/texture - isn't going to be happening any time soon. There are multiple intersecting issues that make this intractably difficult to achieve: 1. There are software boundaries; JavaFX doesn't expose the internal rendering context it uses and, even if it did, there is a combinatorial explosion of possibilities with regards to which rendering API the _user_ might be using, and which rendering API JavaFX might be using (if any!). Traditional stateful APIs like OpenGL make it far too easy for external code to screw up the rendering context anyway, so exposing JavaFX's own context would be a bad idea. 2. There are hardware and concurrency issues; Let's assume that JavaFX is using OpenGL or DirectX internally. Let's also assume that the user is using some kind of API that explicitly provides for managing concurrency with primitives such as fences, semaphores, etc. The user would have to somehow magically arrange for an image transfer on the GPU into an image that JavaFX knew about, and would have to somehow set up all of the right memory barriers and notify JavaFX when the transfer was completed. This is likely to be intensely error-prone at the very least. The thought of implementing this directly brings me out in a cold sweat. So how about another approach entirely? In the past, I've rendered UI elements using entirely software rendering and then uploaded the software-rendered UI as a texture to be overlaid on top of the 3D rendered view. I could obviously continue to do this, but maintaining entire software-rendered UI toolkits myself is a burden, and it would be great if I could use an existing known-good toolkit instead like JavaFX. JavaFX _does_ have a software renderer. What if we could have JavaFX work with entirely software rendering into an offscreen BufferedImage? To make this work, we'd need the following: 1. We'd need to be able to initialize JavaFX in a manner that _didn't_ require JavaFX to "own" the primary stage. That is, right now JavaFX will invoke a user's Application subclass with a Stage that JavaFX created by itself. This won't work for most rendering engines, as typically the programmer has to do a fair bit of work to open a graphics context with the correct settings. Consider the typical code needed to open a window over GLFW with Vulkan... https://github.com/io7m/jcoronado/blob/develop/com.io7m.jcoronado.examples/src/main/java/com/io7m/jcoronado/examples/HelloVulkan.java 2. We'd need to be able to force JavaFX to operate entirely using Java2D software rendering. This shouldn't be a problem at all. 3. We'd need to be able to make JavaFX render to an offscreen BufferedImage. It would be the responsibility of the programmer to submit keyboard and mouse events to JavaFX manually, because JavaFX would no longer "own" the primary application window. I believe the first half of this is already doable in the sense that the Node class allows for taking snapshots of a scene; these snapshots could be uploaded to the GPU as textures. The second half I believe is not exposed in any sense; JavaFX opens its own windows, and consumes input events from those windows directly. I wonder if it would be possible to, for example, add some kind of WindowFactory API to JavaFX so that, when JavaFX wants to create a Window, there's the option to delegate window creation to the user. The created windows might not even be operating system windows (for window-in-window UI systems)[0]. As long as the returned Window instance acted like a Window in terms of returning dimensions, producing the right input events... Would JavaFX even know that it wasn't dealing with an operating system window? [0] https://softcamel.com/wp-content/uploads/2019/03/Transport-Tycoon-Deluxe-2.png -- Mark Raynsford | https://www.io7m.com From arapte at openjdk.java.net Sat Mar 6 16:10:18 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 6 Mar 2021 16:10:18 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v4] In-Reply-To: References: Message-ID: > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: rephrasing comment statements and review corrections ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/397/files - new: https://git.openjdk.java.net/jfx/pull/397/files/1b17d26a..ba8b4ba0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=02-03 Stats: 27 lines in 2 files changed: 4 ins; 1 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/397.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397 PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Sat Mar 6 16:10:18 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Sat, 6 Mar 2021 16:10:18 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v3] In-Reply-To: References: <21wLrCS2heJDc0KY1ArezzhqooS7a-E9UMSfi_2ZVyk=.f37770d8-3c77-4aab-a207-fb3b23189ec9@github.com> Message-ID: On Sat, 6 Mar 2021 01:47:28 GMT, Kevin Rushforth wrote: > I left a few wording suggestions inline. Thanks for the review comments. Please take a look at new commit. I have rephrased comment statements and made corrections as per review comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From kcr at openjdk.java.net Sat Mar 6 16:39:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 6 Mar 2021 16:39:11 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v4] In-Reply-To: References: Message-ID: <0b5HTRS8PqEAuhmRX-nHftBNlM3jCd9BLiWLs2byC6k=.87b6374c-bb9f-4e6d-8c89-f36513599714@github.com> On Sat, 6 Mar 2021 16:10:18 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > rephrasing comment statements and review corrections Two additional comments, and otherwise looks good to me. modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 219: > 217: p4.setStyle("-fx-font-size: 0.5em"); > 218: > 219: // Ideally relative font size of a parent should be relative to font size of its parent. This is a bit confusing. I think you are saying that the relative size of a (node's) parent should be relative to the size of _that parent's_ parent, right? If so, then maybe something like this? // Ideally the relative font size of a parent should be relative to the font size of that parent's parent. modules/javafx.controls/src/test/java/test/javafx/css/PropertySizeTest.java line 257: > 255: // The expected behavior of -fx-font-size calculation with nested set of parents is that > 256: // the font size of a parent is always calculated relative to font size of its parent. > 257: // But currently it is calculated relative to font size of grandparent. Minor suggestion: "...relative to _the_ font size of _its_ grandparent." ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From tsayao at openjdk.java.net Sat Mar 6 23:32:20 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 6 Mar 2021 23:32:20 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v21] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: It's probably good now ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/b5547410..ece5f926 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=19-20 Stats: 22 lines in 2 files changed: 16 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Sat Mar 6 23:43:16 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 6 Mar 2021 23:43:16 GMT Subject: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v22] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: One more small issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/ece5f926..c601603d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=20-21 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Sat Mar 6 23:56:16 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 6 Mar 2021 23:56:16 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v23] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Replace the window size & positining code Default to 320x200 if no size is assigned Hopefully fix all "extra resize" problems due to frame extents. Small change to reuse get_net_frame_extents_atom() Fix more tests (restore 1 behaviour) More test fixes Partial progress Adjust positioning (not 100% yet) It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. It's probably good now One more small issue - Merge pull request #17 from openjdk/master Pull from origin - Merge pull request #16 from openjdk/master Update - Merge pull request #15 from openjdk/master Update from jfx - Merge pull request #14 from openjdk/master Merge master - Merge pull request #13 from openjdk/master Merge master - Merge pull request #12 from openjdk/master Merge with main - Merge pull request #11 from openjdk/master Merge from upstream - Merge pull request #10 from openjdk/master Update from master - Merge pull request #9 from openjdk/master Merge from upstream - ... and 5 more: https://git.openjdk.java.net/jfx/compare/e394b0a6...34518b8e ------------- Changes: https://git.openjdk.java.net/jfx/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=22 Stats: 630 lines in 5 files changed: 170 ins; 337 del; 123 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From tsayao at openjdk.java.net Sat Mar 6 23:56:17 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sat, 6 Mar 2021 23:56:17 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Wed, 3 Mar 2021 12:14:47 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP to reduce sizing events. > > Changed to WIP while we run some more tests to make sure latest changes are ok. > I'm fixing some residual "extra resize" issues (these issues exists on the current versions, so this makes it better, hopefully). Looks good now. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From neil at codelerity.com Sun Mar 7 12:22:11 2021 From: neil at codelerity.com (Neil C Smith) Date: Sun, 7 Mar 2021 12:22:11 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210306122135.06963b52@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210306122135.06963b52@sunflower.int.arc7.info> Message-ID: Hi, A few comments from my perspective here, mainly coming from frustration at the number of times I've had to tell clients or users that JavaFX isn't a viable option for them .. On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote: > there is a > combinatorial explosion of possibilities with regards to which > rendering API the _user_ might be using, and which rendering API > JavaFX might be using (if any!). I agree that's a difficult one, but also surely not an insurmountable one?! There are precedents around Java APIs that provide querying and access to optional support on a platform by platform basis. A library integrating JavaFX with some other platform / renderer specific API is always going to have to handle the situation by either failing gracefully or falling back to a less performant alternative. > Traditional stateful APIs like > OpenGL make it far too easy for external code to screw up the > rendering context anyway, so exposing JavaFX's own context would > be a bad idea. I remain of the view that this shouldn't really be that concerning?! It's a bug in the library if it does so. The current PixelBuffer API already allows enough access for a library to *really* screw up the rendering context, by bringing the whole thing crashing down. But, concurrency issues aside, adding that access has been a real boon. With access comes responsibility. > JavaFX _does_ have a software renderer. What if we could have JavaFX > work with entirely software rendering into an offscreen BufferedImage? Why BufferedImage? What about a reuse / extension / parallel of PixelBuffer? That could allow a range of implementation and the potential for using renderers that can output without a visible window to do this while at least keeping all pixel data off heap? Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From mp at jugs.org Sun Mar 7 13:39:16 2021 From: mp at jugs.org (Michael Paus) Date: Sun, 7 Mar 2021 14:39:16 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210306122135.06963b52@sunflower.int.arc7.info> Message-ID: <1da9d054-eb18-cafe-a45d-cc8cd584e7bf@jugs.org> Why don't you just give it a try? I'd start with the native PixelBuffer option first because it is relatively simple and the performance is sufficient for most use cases. There is, of course, an overhead caused by the GPU -> CPU -> GPU memory transfer but it is not so bad if done right. I've been able to interface a JavaFX application with the external VLC video player that way. I could watch 4K videos without a problem and without stressing the CPU too much. I do not even have a dedicated GPU in my Mac Mini - just the internal Intel graphic. The nice thing about this approach is that the maximum overhead is constant. It depends only on your hardware and the size of your rendering area but not on the complexity of your rendering. Another advantage is that this approach is fully integrated into JavaFX. This means you can do anything with the rendering you can do with a JavaFX ImageView. E.g., drawing something on top of the rendering via JavaFX costs you nothing. Even double-buffering is possible if you know how to do that. And if this is not enough for you, there still is DriftFX which avoids this GPU -> CPU -> GPU memory transfer but is a bit more ambitious to handle. So I would keep that in mind as an option if necessary. Michael Am 07.03.21 um 13:22 schrieb Neil C Smith: > Hi, > > A few comments from my perspective here, mainly coming from > frustration at the number of times I've had to tell clients or users > that JavaFX isn't a viable option for them .. > > On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote: >> there is a >> combinatorial explosion of possibilities with regards to which >> rendering API the _user_ might be using, and which rendering API >> JavaFX might be using (if any!). > I agree that's a difficult one, but also surely not an insurmountable > one?! There are precedents around Java APIs that provide querying and > access to optional support on a platform by platform basis. A library > integrating JavaFX with some other platform / renderer specific API is > always going to have to handle the situation by either failing > gracefully or falling back to a less performant alternative. > >> Traditional stateful APIs like >> OpenGL make it far too easy for external code to screw up the >> rendering context anyway, so exposing JavaFX's own context would >> be a bad idea. > I remain of the view that this shouldn't really be that concerning?! > It's a bug in the library if it does so. The current PixelBuffer API > already allows enough access for a library to *really* screw up the > rendering context, by bringing the whole thing crashing down. But, > concurrency issues aside, adding that access has been a real boon. > With access comes responsibility. > >> JavaFX _does_ have a software renderer. What if we could have JavaFX >> work with entirely software rendering into an offscreen BufferedImage? > Why BufferedImage? What about a reuse / extension / parallel of > PixelBuffer? That could allow a range of implementation and the > potential for using renderers that can output without a visible window > to do this while at least keeping all pixel data off heap? > > Best wishes, > > Neil > > From org.openjdk at io7m.com Sun Mar 7 15:35:58 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Sun, 7 Mar 2021 15:35:58 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210306122135.06963b52@sunflower.int.arc7.info> Message-ID: <20210307153558.47c1ada6@sunflower.int.arc7.info> On 2021-03-07T12:22:11 +0000 Neil C Smith wrote: > Hi, > > A few comments from my perspective here, mainly coming from > frustration at the number of times I've had to tell clients or users > that JavaFX isn't a viable option for them .. > > On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote: > > there is a > > combinatorial explosion of possibilities with regards to which > > rendering API the _user_ might be using, and which rendering API > > JavaFX might be using (if any!). > > I agree that's a difficult one, but also surely not an insurmountable > one?! There are precedents around Java APIs that provide querying and > access to optional support on a platform by platform basis... I think it's insurmountable due to the complexity of the semantics of the thing (the GPU) that's being abstracted over. The basic primitive that would be required is "transfer this image to this other image". You'd need to expose that operation in way that would work for every possible pair of rendering APIs, including getting all of the synchronization right that lower level APIs like Vulkan and DX12 require. The complexity of handling that would need to be pushed onto each person trying to use the API. JavaFX would effectively need to know when it was safe to use an image that was being transferred in, without actually being able to know where the image was coming from or who to talk to about it. The only methods it _could_ use would involve CPU-side fences, which would then have performance implications. To clarify a bit: Let's say we lived in an ideal world and JavaFX had a Vulkan backend, and contained code that was willing to cooperate with the user's Vulkan-based rendering code. The user could tell JavaFX "here's the image to use for this node, but don't use it until this semaphore becomes available". This is generally highly efficient as a semaphore (in Vulkan terms) is a GPU-side primitive that just controls parallelism across different queue instances on the GPU, with no CPU-side interaction at all. We have no way to get to that ideal world whilst JavaFX and the user's code have no common API over which to communicate. Everything would have to go via CPU-based abstractions. > > Traditional stateful APIs like > > OpenGL make it far too easy for external code to screw up the > > rendering context anyway, so exposing JavaFX's own context would > > be a bad idea. > > I remain of the view that this shouldn't really be that concerning?! > It's a bug in the library if it does so. It's definitely concerning. Have you worked with OpenGL much? If you're *lucky* you'll get a crash, because at least then you'll see the exact location where the mistake occured. What you'll typically get instead is corrupted rendering, a black screen, or just bad performance as the driver desperately tries to make sense of what you asked it to do, usually in completely unrelated parts of the rendering process. It's the prime reason I jumped ship to Vulkan the second it came out. :) > > JavaFX _does_ have a software renderer. What if we could have JavaFX > > work with entirely software rendering into an offscreen BufferedImage? > > Why BufferedImage? What about a reuse / extension / parallel of > PixelBuffer? Yes indeed. I said BufferedImage just because I assumed that would be more familiar. I'd not personally care where the output went as long as I could get the raw bytes out of it in order to upload to the GPU. -- Mark Raynsford | https://www.io7m.com From tom.schindl at bestsolution.at Sun Mar 7 17:12:17 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 7 Mar 2021 18:12:17 +0100 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210307153558.47c1ada6@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210306122135.06963b52@sunflower.int.arc7.info> <20210307153558.47c1ada6@sunflower.int.arc7.info> Message-ID: <329e8743-2929-067f-c2ec-3b2bcd07032f@bestsolution.at> Hi, If I got you right you now changed your idea to render JavaFX into an PixelBuffer and integrate that into a scene renderer with Vulkan, ... . This exactly how the integration into SWT and Swing is done, the internal API for that is found in "com.sun.javafx.embed". Before we implemented DriftFX we integrated a JavaFX-Scene into our application exactly this way. For that purpose we hacked FXCanvas and published the changed code at our customers github account [1]. You see there at [2] how one fills the buffer from an offscreen scene. My gut feeling is that getting a "com.sun.javafx.embed"-API is much more likely than an DriftFX-Like-API but that just my personal opinion. Anyways our/my focus still is DriftFX and I/we are quite confident that what we have today in DriftFX is a good API where we today support JavaFX-8 to JavaFX-15 (I haven't tested 16 but I have not seen any changes going into it that would require us to change our code) Tom [1] https://github.com/eclipsesource/FXCanvas/blob/master/FXCanvas/src/javafx/embed/swt/FXCanvas.java [2] https://github.com/eclipsesource/FXCanvas/blob/master/FXCanvas/src/javafx/embed/swt/FXCanvas.java#L631 Am 07.03.21 um 16:35 schrieb Mark Raynsford: > On 2021-03-07T12:22:11 +0000 > Neil C Smith wrote: > >> Hi, >> >> A few comments from my perspective here, mainly coming from >> frustration at the number of times I've had to tell clients or users >> that JavaFX isn't a viable option for them .. >> >> On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote: >>> there is a >>> combinatorial explosion of possibilities with regards to which >>> rendering API the _user_ might be using, and which rendering API >>> JavaFX might be using (if any!). >> >> I agree that's a difficult one, but also surely not an insurmountable >> one?! There are precedents around Java APIs that provide querying and >> access to optional support on a platform by platform basis... > > I think it's insurmountable due to the complexity of the semantics of > the thing (the GPU) that's being abstracted over. The basic primitive > that would be required is "transfer this image to this other image". > You'd need to expose that operation in way that would work for every > possible pair of rendering APIs, including getting all of the > synchronization right that lower level APIs like Vulkan and DX12 > require. The complexity of handling that would need to be pushed onto > each person trying to use the API. JavaFX would effectively need to > know when it was safe to use an image that was being transferred in, > without actually being able to know where the image was coming from or > who to talk to about it. The only methods it _could_ use would involve > CPU-side fences, which would then have performance implications. > > To clarify a bit: Let's say we lived in an ideal world and JavaFX had a > Vulkan backend, and contained code that was willing to cooperate with > the user's Vulkan-based rendering code. The user could tell JavaFX > "here's the image to use for this node, but don't use it until this > semaphore becomes available". This is generally highly efficient as a > semaphore (in Vulkan terms) is a GPU-side primitive that just controls > parallelism across different queue instances on the GPU, with no > CPU-side interaction at all. > > We have no way to get to that ideal world whilst JavaFX and the user's > code have no common API over which to communicate. Everything would > have to go via CPU-based abstractions. > >>> Traditional stateful APIs like >>> OpenGL make it far too easy for external code to screw up the >>> rendering context anyway, so exposing JavaFX's own context would >>> be a bad idea. >> >> I remain of the view that this shouldn't really be that concerning?! >> It's a bug in the library if it does so. > > It's definitely concerning. Have you worked with OpenGL much? If you're > *lucky* you'll get a crash, because at least then you'll see the > exact location where the mistake occured. What you'll typically get > instead is corrupted rendering, a black screen, or just bad performance > as the driver desperately tries to make sense of what you asked it to > do, usually in completely unrelated parts of the rendering process. It's > the prime reason I jumped ship to Vulkan the second it came out. :) > >>> JavaFX _does_ have a software renderer. What if we could have JavaFX >>> work with entirely software rendering into an offscreen BufferedImage? >> >> Why BufferedImage? What about a reuse / extension / parallel of >> PixelBuffer? > > Yes indeed. I said BufferedImage just because I assumed that would be > more familiar. I'd not personally care where the output went as long as > I could get the raw bytes out of it in order to upload to the GPU. > From tsayao at openjdk.java.net Sun Mar 7 21:40:19 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 7 Mar 2021 21:40:19 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v24] In-Reply-To: References: Message-ID: > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Small compilation fix for ubuntu 16.04 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/34518b8e..6a48f2a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=22-23 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From arapte at openjdk.java.net Mon Mar 8 07:49:23 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Mar 2021 07:49:23 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v5] In-Reply-To: References: Message-ID: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: minor corrections in comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/397/files - new: https://git.openjdk.java.net/jfx/pull/397/files/ba8b4ba0..8c97bf94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=397&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/397.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/397/head:pull/397 PR: https://git.openjdk.java.net/jfx/pull/397 From arapte at openjdk.java.net Mon Mar 8 07:49:23 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Mar 2021 07:49:23 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v4] In-Reply-To: <0b5HTRS8PqEAuhmRX-nHftBNlM3jCd9BLiWLs2byC6k=.87b6374c-bb9f-4e6d-8c89-f36513599714@github.com> References: <0b5HTRS8PqEAuhmRX-nHftBNlM3jCd9BLiWLs2byC6k=.87b6374c-bb9f-4e6d-8c89-f36513599714@github.com> Message-ID: <4dAGfFNESnJLBOOlY0W0ykI2gxaqDO9urSw_VdH329U=.7d14fc41-3e95-415c-a5b6-efde017e0bc4@github.com> On Sat, 6 Mar 2021 16:36:27 GMT, Kevin Rushforth wrote: > Two additional comments, and otherwise looks good to me. Thanks for the review, both the comments are addressed in next commit. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From github.com+1519324+primosk at openjdk.java.net Mon Mar 8 08:21:08 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Mon, 8 Mar 2021 08:21:08 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 06:41:53 GMT, Arun Joseph wrote: > Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. Hi dear OpenJdk team, At first I would like to thank you for looking into this. I am the author of original `8262276` ticket. I would just like to share some additional information with you. I've fetched and checked out this pull request (`pull/417`) and tried to run the build once more inside exactly the same environment in which original `8262276` ticket was produced. The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): * Where: Build file 'C:\jfx-arun-joseph\build.gradle' line: 3453 Please let me know if you need any further information. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From aghaisas at openjdk.java.net Mon Mar 8 11:33:14 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 8 Mar 2021 11:33:14 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v5] In-Reply-To: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> References: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> Message-ID: On Mon, 8 Mar 2021 07:49:23 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > minor corrections in comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From aghaisas at openjdk.java.net Mon Mar 8 12:14:11 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 8 Mar 2021 12:14:11 GMT Subject: RFR: 8089913: CSS pseudo classes missing by default for some controls [v5] In-Reply-To: References: Message-ID: On Fri, 5 Mar 2021 16:07:59 GMT, mstr2 wrote: >> The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. > > mstr2 has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to TreeCell, TreeTableRow Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From kcr at openjdk.java.net Mon Mar 8 12:38:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 12:38:10 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v5] In-Reply-To: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> References: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> Message-ID: On Mon, 8 Mar 2021 07:49:23 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > minor corrections in comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From jvos at openjdk.java.net Mon Mar 8 13:08:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 8 Mar 2021 13:08:10 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 03:58:17 GMT, Alexander Matveev wrote: > - Added support to compile media on arm. > - libffi is based on 3.3. Marked as reviewed by jvos (Reviewer). I didn't test it on real hardware, but it looks good and doesn't cause regression. ------------- PR: https://git.openjdk.java.net/jfx/pull/412 From kcr at openjdk.java.net Mon Mar 8 14:09:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 14:09:07 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 08:16:51 GMT, PrimosK wrote: >> Fixing the Debug build of WebKit. >> >> Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. > > Hi dear OpenJdk team, > > At first I would like to thank you for looking into this. I am the author of original `8262276` ticket. > > I would just like to share some additional information with you. I've fetched and checked out this pull request (`pull/417`) and tried to run the build once more inside exactly the same environment in which original `8262276` ticket was produced. > > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): > > * Where: > Build file 'C:\jfx-arun-joseph\build.gradle' line: 3453 > > Please let me know if you need any further information. > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): > ... > > Please let me know if you need any further information. You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: * gradle 6.3 * cmake 3.13.3 * ninja 1.8.2 3. Have you tried building on a platform other than Windows? ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From dgrieve at openjdk.java.net Mon Mar 8 14:31:12 2021 From: dgrieve at openjdk.java.net (David Grieve) Date: Mon, 8 Mar 2021 14:31:12 GMT Subject: RFR: 8204568: Relative CSS-Attributes don't work all time [v5] In-Reply-To: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> References: <2rMsKIt4BW5RZZI-ubPcoOfySNYxK7eGuwZnv1TDnsM=.faf3f760-db6c-4c44-86af-2bcd42d4a780@github.com> Message-ID: On Mon, 8 Mar 2021 07:49:23 GMT, Ambarish Rapte wrote: >> Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. >> >> Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). >> >> Fix is very specific to this scenario and did not show any side effect nor any test failure. >> >> There are 12 new unit tests added along with fix: >> - Two tests fail before and pass after this fix. These test verify the reported failing scenario. >> sameRelativeFontSizeNestedParentTest >> relativeFontSizeDeepNestedParentControlTest >> - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. >> propertySizesRelativeToFontSizeOfControlTest >> propertySizesRelativeToFontSizeOfParentTest >> - Other 8 tests are sanity tests which pass both before and after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > minor corrections in comments Marked as reviewed by dgrieve (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From neil at codelerity.com Mon Mar 8 14:59:12 2021 From: neil at codelerity.com (Neil C Smith) Date: Mon, 8 Mar 2021 14:59:12 +0000 Subject: Layering JavaFX onto an external rendering context In-Reply-To: <20210307153558.47c1ada6@sunflower.int.arc7.info> References: <20210215134043.09b57608@sunflower.int.arc7.info> <20210306122135.06963b52@sunflower.int.arc7.info> <20210307153558.47c1ada6@sunflower.int.arc7.info> Message-ID: On Sun, 7 Mar 2021 at 15:36, Mark Raynsford wrote: > The basic primitive > that would be required is "transfer this image to this other image". > You'd need to expose that operation in way that would work for every > possible pair of rendering APIs ... The complexity of handling that would need to be pushed onto > each person trying to use the API. Surely that is the point? I'm also not sure what you mean by "pair of rendering APIs", or why you'd want to try and support every possible pairing internally in JavaFX? > JavaFX would effectively need to > know when it was safe to use an image that was being transferred in, > without actually being able to know where the image was coming from or > who to talk to about it. The only methods it _could_ use would involve > CPU-side fences, which would then have performance implications. CPU-side fences may be required, yes. The problem you outline is already the problem we have, and have had to hack around, with the PixelBuffer API. That already lacks a way to tell JavaFX that the backing memory is no longer safe to use, or for JavaFX to communicate back that the memory is safe to reclaim - it's uni-directional. Somehow, that really needs to be made bi-directional, such that either side can take ownership and release the data as necessary. Solve that issue and you're possibly on the way to solving the same safe / unsafe concerns raised here? So, yes, potentially performance implications over complete unfettered access, no doubt. > > > Traditional stateful APIs like > > > OpenGL make it far too easy for external code to screw up the > > > rendering context anyway, so exposing JavaFX's own context would > > > be a bad idea. > > > > I remain of the view that this shouldn't really be that concerning?! > > It's a bug in the library if it does so. > > It's definitely concerning. Have you worked with OpenGL much? Yes, quite a lot. I mean "concerning" specifically to the JavaFX project, not to the library developer making use of the ability. I realise that it's a fine line to draw between the amount of access you provide, the amount you hinder future evolution, the amount you make certain use cases unviable, and the amount you allow users to shoot themselves in the foot. Best wishes, Neil -- Neil C Smith Codelerity Ltd. www.codelerity.com Codelerity Ltd. is a company registered in England and Wales Registered company number : 12063669 Registered office address : Office 4 219 Kensington High Street, Kensington, London, England, W8 6BD From jvos at openjdk.java.net Mon Mar 8 15:10:05 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 8 Mar 2021 15:10:05 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 14:06:02 GMT, Kevin Rushforth wrote: >> Hi dear OpenJdk team, >> >> At first I would like to thank you for looking into this. I am the author of original `8262276` ticket. >> >> I would just like to share some additional information with you. I've fetched and checked out this pull request (`pull/417`) and tried to run the build once more inside exactly the same environment in which original `8262276` ticket was produced. >> >> The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): >> >> * Where: >> Build file 'C:\jfx-arun-joseph\build.gradle' line: 3453 >> >> Please let me know if you need any further information. > >> The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): >> ... >> >> Please let me know if you need any further information. > > You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: > > 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. > > 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: > * gradle 6.3 > * cmake 3.13.3 > * ninja 1.8.2 > > 3. Have you tried building on a platform other than Windows? when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From github.com+43553916+mstr2 at openjdk.java.net Mon Mar 8 16:02:10 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Mon, 8 Mar 2021 16:02:10 GMT Subject: Integrated: 8089913: CSS pseudo classes missing by default for some controls In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 15:17:23 GMT, mstr2 wrote: > The Slider control does not have the ":horizontal" CSS pseudo-class set by default. The pseudo-class is only set once the "orientation" property is changed. This PR fixes that. This pull request has now been integrated. Changeset: 3374f479 Author: mstr2 <43553916+mstr2 at users.noreply.github.com> Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3374f479 Stats: 51 lines in 8 files changed: 51 ins; 0 del; 0 mod 8089913: CSS pseudo classes missing by default for some controls Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/413 From github.com+1519324+primosk at openjdk.java.net Mon Mar 8 16:24:06 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Mon, 8 Mar 2021 16:24:06 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: <9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com> On Mon, 8 Mar 2021 15:07:30 GMT, Johan Vos wrote: >>> The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): >>> ... >>> >>> Please let me know if you need any further information. >> >> You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: >> >> 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. >> >> 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: >> * gradle 6.3 >> * cmake 3.13.3 >> * ninja 1.8.2 >> >> 3. Have you tried building on a platform other than Windows? > > when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. > > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): > > ... > > Please let me know if you need any further information. > > You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: > > 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. > 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: > > * gradle 6.3 > * cmake 3.13.3 > * ninja 1.8.2 > > 1. Have you tried building on a platform other than Windows? **1.** No, it doesn't work. As already stated in the [JDK-8262276](https://bugs.openjdk.java.net/browse/JDK-8262276), the build fails for me with the exactly same error also when I set: COMPILE_WEBKIT = true CONF = Release in `gradle.properties`. **2.** ATM I am using these libraries: - Javafx (`pull/417`) - Java 15 (installed on Windows) - Ant 1.10.5 (installed on Windows) - **CMake 3.13.3** (installed on Windows) - Visual Studio 2017 community edition (**Ninja 1.8.2**) - **Gradlew 6.3** - CygWin (installed on Windows) with the following packages: - bison 3.0.4-1 - flex 2.6.4-2 - gcc-g++ 10.2.0-1 - git 2.30.0-1 - gperf 3.1-1 - make 4.3-1 - makedepend 1.0.6-1 - openssh 8.4p1-2 - perl 5.32.1-1 - python27 2.7.18-4 - ruby 2.6.4-1 - unzip 6.0-17 - zip 3.0-12 But I am seeing exactly the same error. **3.** No - I've tried it only with Windows as we need debug symbols there... Side note: Could you guys please provide me with the versions of the above libraries that are used in the case of your CI build system? Is now Visual Studio the only difference? I tried to check it by myself by going through the log files at https://github.com/arun-Joseph/jfx/runs/2028653928 but I couldn't found CygWin plugin versions (bison, flex...). Tomorrow I will try building it using Visual Studio 2019. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From arapte at openjdk.java.net Mon Mar 8 16:49:06 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 8 Mar 2021 16:49:06 GMT Subject: Integrated: 8204568: Relative CSS-Attributes don't work all time In-Reply-To: References: Message-ID: <7HyqiR-Fie_TiR_AvtcQ9zAY6UsDmooQ9OBW8hzeZhM=.441604ba-9515-4932-9920-dd3e32a2026a@github.com> On Mon, 8 Feb 2021 11:37:35 GMT, Ambarish Rapte wrote: > Issue is that the size of properties that are relatively(`em`) sized is not computed correctly when the reference `-fx-font-size` is also specified relatively and is nested. > > Fix is a slight variation of an earlier suggestion in [the PR](https://github.com/javafxports/openjdk-jfx/pull/94). > > Fix is very specific to this scenario and did not show any side effect nor any test failure. > > There are 12 new unit tests added along with fix: > - Two tests fail before and pass after this fix. These test verify the reported failing scenario. > sameRelativeFontSizeNestedParentTest > relativeFontSizeDeepNestedParentControlTest > - Two other tests fail both before and after this fix. They are not related to the fix. These two tests are ignored. I shall file new JBS issues to track these cases and update PR with the IDs added to @Ignore. > propertySizesRelativeToFontSizeOfControlTest > propertySizesRelativeToFontSizeOfParentTest > - Other 8 tests are sanity tests which pass both before and after this fix. This pull request has now been integrated. Changeset: 9c7cf172 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/9c7cf172 Stats: 700 lines in 5 files changed: 696 ins; 0 del; 4 mod 8204568: Relative CSS-Attributes don't work all time Reviewed-by: dgrieve, kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/397 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 20:38:20 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 20:38:20 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action Message-ID: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. ------------- Commit messages: - 8263204: Add Gradle Wrapper Validation Action Changes: https://git.openjdk.java.net/jfx/pull/419/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263204 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/419/head:pull/419 PR: https://git.openjdk.java.net/jfx/pull/419 From kcr at openjdk.java.net Mon Mar 8 20:41:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 20:41:09 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 20:34:05 GMT, John Neffenger wrote: > 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. This sounds like a good plan to test it. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 21:28:24 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 21:28:24 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action [v2] In-Reply-To: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: > See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: > > 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Add the Official Gradle Wrapper Validation Action ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/419/files - new: https://git.openjdk.java.net/jfx/pull/419/files/710bb40e..886a54a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=00-01 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/419/head:pull/419 PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 21:28:24 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 21:28:24 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 20:38:09 GMT, Kevin Rushforth wrote: >> See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: >> >> 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. >> 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. >> 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. > >> 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. >> 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. >> 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. > > This sounds like a good plan to test it. So far, so good. The tampered file was not detected: ![all-checks-have-passed](https://user-images.githubusercontent.com/1413266/110383521-411ab200-8011-11eb-88ee-27102e0b6d81.png) The next commit will add the Official Gradle Wrapper Validation Action. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From kcr at openjdk.java.net Mon Mar 8 21:47:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 21:47:05 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 21:23:47 GMT, John Neffenger wrote: >>> 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. >>> 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. >>> 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. >> >> This sounds like a good plan to test it. > > So far, so good. The tampered file was not detected: > > ![all-checks-have-passed](https://user-images.githubusercontent.com/1413266/110383521-411ab200-8011-11eb-88ee-27102e0b6d81.png) > > The next commit will add the Official Gradle Wrapper Validation Action. It might be better to include the validation task in the same [`submit.yml`](https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml) file as the pre-submit tests, as a separate job. That way it will get the same set of conditions triggering it as the other pre-submit jobs. In particular, we don't use the "on pull_request" trigger for our github actions run, since all actions triggered on any pull request in any repo in the openjdk org will be run in the context of the openjdk organization and we would blow our limits too quickly. Also, this should be limited to the set of branches that `submit.yml` uses. If there is a good reason to keep it in a separate file, then I would at least duplicate this part from submit.yml: on: # Run GitHub actions on every push to all branches except the main production branches, also # exclude any branch starting with "WIP". push: branches-ignore: - master - main - 'jfx[0-9]+' - 'WIP*' ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 22:03:09 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 22:03:09 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 21:44:03 GMT, Kevin Rushforth wrote: >> So far, so good. The tampered file was not detected: >> >> ![all-checks-have-passed](https://user-images.githubusercontent.com/1413266/110383521-411ab200-8011-11eb-88ee-27102e0b6d81.png) >> >> The next commit will add the Official Gradle Wrapper Validation Action. > > It might be better to include the validation task in the same [`submit.yml`](https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml) file as the pre-submit tests, as a separate job. That way it will get the same set of conditions triggering it as the other pre-submit jobs. In particular, we don't use the "on pull_request" trigger for our github actions run, since all actions triggered on any pull request in any repo in the openjdk org will be run in the context of the openjdk organization and we would blow our limits too quickly. Also, this should be limited to the set of branches that `submit.yml` uses. > > If there is a good reason to keep it in a separate file, then I would at least duplicate this part from submit.yml: > > on: > # Run GitHub actions on every push to all branches except the main production branches, also > # exclude any branch starting with "WIP". > push: > branches-ignore: > - master > - main > - 'jfx[0-9]+' > - 'WIP*' Thanks, Kevin. I'll merge the two workflow files. The test results aren't what I expected: ![some-checks-were-not-successful](https://user-images.githubusercontent.com/1413266/110386542-424dde00-8015-11eb-9cef-97d2ff2a5d27.png) I assumed the wrapper validation would fail and prevent the builds from running. Should I try to make the three build steps dependent on the success of the wrapper validation? There might be a way to make the steps sequential and conditional. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From kcr at openjdk.java.net Mon Mar 8 22:16:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 22:16:07 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: <_KnE168BaUDM6xHboMEvPfvinVIV2ltwu7aem2Steqo=.e48a830b-1f62-4e64-854b-a932aa51e3b5@github.com> On Mon, 8 Mar 2021 22:00:14 GMT, John Neffenger wrote: >> It might be better to include the validation task in the same [`submit.yml`](https://github.com/openjdk/jfx/blob/master/.github/workflows/submit.yml) file as the pre-submit tests, as a separate job. That way it will get the same set of conditions triggering it as the other pre-submit jobs. In particular, we don't use the "on pull_request" trigger for our github actions run, since all actions triggered on any pull request in any repo in the openjdk org will be run in the context of the openjdk organization and we would blow our limits too quickly. Also, this should be limited to the set of branches that `submit.yml` uses. >> >> If there is a good reason to keep it in a separate file, then I would at least duplicate this part from submit.yml: >> >> on: >> # Run GitHub actions on every push to all branches except the main production branches, also >> # exclude any branch starting with "WIP". >> push: >> branches-ignore: >> - master >> - main >> - 'jfx[0-9]+' >> - 'WIP*' > > Thanks, Kevin. I'll merge the two workflow files. > > The test results aren't what I expected: > > ![some-checks-were-not-successful](https://user-images.githubusercontent.com/1413266/110386542-424dde00-8015-11eb-9cef-97d2ff2a5d27.png) > > I assumed the wrapper validation would fail and prevent the builds from running. Should I try to make the three build steps dependent on the success of the wrapper validation? There might be a way to make the steps sequential and conditional. If it isn't too hard to make the running of the other three jobs dependent on the wrapper validation job, that would be good, as long as the validation job is fast. The other three still need to run in parallel with each other. Alternatively, you could make the wrapper validation a task that is replicated in each of the three jobs. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 22:27:18 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 22:27:18 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action [v3] In-Reply-To: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: <6ZaJZYOIBlrFmoNUci1NNYDEuBHSarlph927pZWr5gQ=.c5830ed5-3ba7-4233-82c7-49dd0a8cd34a@github.com> > See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: > > 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Make build jobs dependent on wrapper validation Consolidate the two GitHub workflow files and make the three build jobs dependent on the success of the Gradle Wrapper validation. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/419/files - new: https://git.openjdk.java.net/jfx/pull/419/files/886a54a4..b2a737ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=01-02 Stats: 24 lines in 2 files changed: 11 ins; 13 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/419/head:pull/419 PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 22:40:08 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 22:40:08 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: <_KnE168BaUDM6xHboMEvPfvinVIV2ltwu7aem2Steqo=.e48a830b-1f62-4e64-854b-a932aa51e3b5@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> <_KnE168BaUDM6xHboMEvPfvinVIV2ltwu7aem2Steqo=.e48a830b-1f62-4e64-854b-a932aa51e3b5@github.com> Message-ID: On Mon, 8 Mar 2021 22:13:09 GMT, Kevin Rushforth wrote: >> Thanks, Kevin. I'll merge the two workflow files. >> >> The test results aren't what I expected: >> >> ![some-checks-were-not-successful](https://user-images.githubusercontent.com/1413266/110386542-424dde00-8015-11eb-9cef-97d2ff2a5d27.png) >> >> I assumed the wrapper validation would fail and prevent the builds from running. Should I try to make the three build steps dependent on the success of the wrapper validation? There might be a way to make the steps sequential and conditional. > > If it isn't too hard to make the running of the other three jobs dependent on the wrapper validation job, that would be good, as long as the validation job is fast. The other three still need to run in parallel with each other. > > Alternatively, you could make the wrapper validation a task that is replicated in each of the three jobs. Okay, this is looking better! The validation took only 23 seconds, and GitHub shows the following results: ![some-checks-were-not-successful-2](https://user-images.githubusercontent.com/1413266/110390566-0b7ac680-801b-11eb-8090-f1548046094e.png) The screenshot below shows the notification I received by e-mail: ![run-failed-message](https://user-images.githubusercontent.com/1413266/110390602-17ff1f00-801b-11eb-9870-c5f955b4739c.png) Now we'll see whether the three build jobs still run in parallel when the wrapper validation succeeds. My next commit will restore the Gradle Wrapper JAR file. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 22:47:16 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 22:47:16 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action [v4] In-Reply-To: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: > See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: > > 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Restore the Gradle version 4.8 Wrapper JAR file ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/419/files - new: https://git.openjdk.java.net/jfx/pull/419/files/b2a737ad..9a4b0215 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=419&range=02-03 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/419/head:pull/419 PR: https://git.openjdk.java.net/jfx/pull/419 From kcr at openjdk.java.net Mon Mar 8 22:58:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 22:58:08 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> <_KnE168BaUDM6xHboMEvPfvinVIV2ltwu7aem2Steqo=.e48a830b-1f62-4e64-854b-a932aa51e3b5@github.com> Message-ID: On Mon, 8 Mar 2021 22:55:18 GMT, John Neffenger wrote: >> Okay, this is looking better! The validation took only 23 seconds, and GitHub shows the following results: >> >> ![some-checks-were-not-successful-2](https://user-images.githubusercontent.com/1413266/110390566-0b7ac680-801b-11eb-8090-f1548046094e.png) >> >> The screenshot below shows the notification I received by e-mail: >> >> ![run-failed-message](https://user-images.githubusercontent.com/1413266/110390602-17ff1f00-801b-11eb-9870-c5f955b4739c.png) >> >> Now we'll see whether the three build jobs still run in parallel when the wrapper validation succeeds. My next commit will restore the Gradle Wrapper JAR file. > > Looks good: two preliminary checks followed conditionally by the three concurrent build jobs: > > ![some-checks-haven?t-completed-yet](https://user-images.githubusercontent.com/1413266/110392468-d15ef400-801d-11eb-8a1c-1bf49ed32a2a.png) > > Once the build jobs finish, this pull request is finally ready for review. Thanks for your timely help, Kevin. Yep, they are running in parallel. And this provides a nice view: https://github.com/jgneff/jfx/actions/runs/633879096 ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From github.com+1413266+jgneff at openjdk.java.net Mon Mar 8 22:58:07 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 8 Mar 2021 22:58:07 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> <_KnE168BaUDM6xHboMEvPfvinVIV2ltwu7aem2Steqo=.e48a830b-1f62-4e64-854b-a932aa51e3b5@github.com> Message-ID: On Mon, 8 Mar 2021 22:37:10 GMT, John Neffenger wrote: >> If it isn't too hard to make the running of the other three jobs dependent on the wrapper validation job, that would be good, as long as the validation job is fast. The other three still need to run in parallel with each other. >> >> Alternatively, you could make the wrapper validation a task that is replicated in each of the three jobs. > > Okay, this is looking better! The validation took only 23 seconds, and GitHub shows the following results: > > ![some-checks-were-not-successful-2](https://user-images.githubusercontent.com/1413266/110390566-0b7ac680-801b-11eb-8090-f1548046094e.png) > > The screenshot below shows the notification I received by e-mail: > > ![run-failed-message](https://user-images.githubusercontent.com/1413266/110390602-17ff1f00-801b-11eb-9870-c5f955b4739c.png) > > Now we'll see whether the three build jobs still run in parallel when the wrapper validation succeeds. My next commit will restore the Gradle Wrapper JAR file. Looks good: two preliminary checks followed conditionally by the three concurrent build jobs: ![some-checks-haven?t-completed-yet](https://user-images.githubusercontent.com/1413266/110392468-d15ef400-801d-11eb-8a1c-1bf49ed32a2a.png) Once the build jobs finish, this pull request is finally ready for review. Thanks for your timely help, Kevin. ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From jpereda at openjdk.java.net Mon Mar 8 23:47:19 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 8 Mar 2021 23:47:19 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode Message-ID: This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. Tested successfully on Android with ComboBox controls in different positions. ------------- Commit messages: - Change parameter names to accommodate class calculations Changes: https://git.openjdk.java.net/jfx/pull/420/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=420&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8206253 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/420.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/420/head:pull/420 PR: https://git.openjdk.java.net/jfx/pull/420 From kcr at openjdk.java.net Mon Mar 8 23:50:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Mar 2021 23:50:08 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 23:43:10 GMT, Jose Pereda wrote: > This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). > > As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. > > Tested successfully on Android with ComboBox controls in different positions. Since this touches shared code, what testing have you done to ensure that it works as expected on other platforms? ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From jpereda at openjdk.java.net Tue Mar 9 01:22:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Mar 2021 01:22:10 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 23:47:32 GMT, Kevin Rushforth wrote: >> This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). >> >> As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. >> >> Tested successfully on Android with ComboBox controls in different positions. > > Since this touches shared code, what testing have you done to ensure that it works as expected on other platforms? I've tested Mac (via touchPad), but even setting `com.sun.javafx.gestures.scroll` to true, `ScrollGestureRecognizer` doesn't get called (via `GlassViewEventHandler::handleEndTouchEvent`), as the flow of scroll events goes through `GlassViewEventHandler::handleScrollGestureEvent`. Same on Linux and Windows (via touchPad), where the flow of scroll events goes through `GlassViewEventHandler::handleScrollEvent`. I've also tested on Windows with a touch enabled display (and `com.sun.javafx.gestures.scroll` set to true). In this case, scroll events are handled mostly via `GlassViewEventHandler::handleScrollGestureEvent`, but also by `ScrollGestureRecognizer`. Before this PR, the latter added wrong coordinates to the gesture, causing the scroll to stop. With the changes, there are a few events, but they are now exactly the same as those from handleScrollGestureEvent (so there are duplicated calls to `scene.sceneListener.scrollEvent`), and the scroll is more fluid, doesn't stop. (Anyway, I don't think it is expected to set `com.sun.javafx.gestures.scroll` in this platform) ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From github.com+1519324+primosk at openjdk.java.net Tue Mar 9 06:33:04 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Tue, 9 Mar 2021 06:33:04 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: <9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com> References: <9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com> Message-ID: On Mon, 8 Mar 2021 16:20:21 GMT, PrimosK wrote: >> when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. > >> > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): >> > ... >> > Please let me know if you need any further information. >> >> You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: >> >> 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. >> 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: >> >> * gradle 6.3 >> * cmake 3.13.3 >> * ninja 1.8.2 >> >> 1. Have you tried building on a platform other than Windows? > > **1.** > No, it doesn't work. As already stated in the [JDK-8262276](https://bugs.openjdk.java.net/browse/JDK-8262276), the build fails for me with the exactly same error also when I set: > COMPILE_WEBKIT = true > CONF = Release > > in `gradle.properties`. > > **2.** > ATM I am using these libraries: > > - Javafx (`pull/417`) > - Java 15 (installed on Windows) > - Ant 1.10.5 (installed on Windows) > - **CMake 3.13.3** (installed on Windows) > - Visual Studio 2017 community edition (**Ninja 1.8.2**) > - **Gradlew 6.3** > - CygWin (installed on Windows) with the following packages: > - bison 3.0.4-1 > - flex 2.6.4-2 > - gcc-g++ 10.2.0-1 > - git 2.30.0-1 > - gperf 3.1-1 > - make 4.3-1 > - makedepend 1.0.6-1 > - openssh 8.4p1-2 > - perl 5.32.1-1 > - python27 2.7.18-4 > - ruby 2.6.4-1 > - unzip 6.0-17 > - zip 3.0-12 > > But I am seeing exactly the same error. > > **3.** > No - I've tried it only with Windows as we need debug symbols there... > > Side note: > > Could you guys please provide me with the versions of the above libraries that are used in the case of your CI build system? Is now Visual Studio the only difference? I tried to check it by myself by going through the log files at https://github.com/arun-Joseph/jfx/runs/2028653928 but I couldn't found CygWin plugin versions (bison, flex...). > > Tomorrow I will try building it using Visual Studio 2019. Hi everyone, Today I've tried to create a build using **Visual Studio 2019** but with no success. I am seeing the same error. There is a complete output of `./gradlew --scan`: [build-output.txt](https://github.com/openjdk/jfx/files/6106294/build-output.txt) The build scan is available there: https://scans.gradle.com/s/dimrfirscg7hm OS: - Windows 10 Repository: - JavaFx (pull/417) Installed libraries: - Java 15 (15+36-1562) - Ant 1.10.5 - Gradlew 6.3 - CMake 3.13.3 - Visual Studio 2019 community edition (VS2019-16.7.2+1.0) - Ninja 1.8.2 CygWin (installed on Windows) with the following packages: - bison 3.0.4-1 - flex 2.6.4-2 - gcc-g++ 10.2.0-1 - git 2.30.0-1 - gperf 3.1-1 - make 4.3-1 - makedepend 1.0.6-1 - openssh 8.4p1-2 - perl 5.32.1-1 - python27 2.7.18-4 - ruby 2.6.4-1 - unzip 6.0-17 - zip 3.0-12 `gradle.properties`: COMPILE_WEBKIT = true CONF = DebugNative Content of `windows.tools`: WINDOWS_VS_DEVENVDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE WINDOWS_VS_DEVENVCMD=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/devenv.com WINDOWS_VS_VCINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC WINDOWS_VS_VSINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community WINDOWS_VS_MSVCDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC WINDOWS_VS_INCLUDE=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0.1904 1.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt WINDOWS_VS_LIB=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x86 WINDOWS_VS_LIBPATH=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/10.0.19041.0;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/10.0.19041.0;C:/Windows/Microsoft.NET/Framework/v4.0.30319 WINDOWS_VS_PATH=;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX64/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/x64;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerf CollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x64;C:/Program Files (x86)/Windows Kits/10/bin/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX86/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExten sions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x86;C:/Program Files (x86)/Windows Kits/10/bin/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/cygwin64/usr/local/bin;C:/cygwin64/bin;C:/Windows/system32;C:/Windows;C:/Windows/System32/Wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Windows/System32/OpenSSH;C:/Program Files/CMake/bin;C:/Users/WDAGU tilityAccount/AppData/Local/Microsoft/WindowsApps;C:/Program Files/jdk-15/bin;C:/apache-ant-1.10.5/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja WINDOWS_VS_VER=150 WINDOWS_SDK_DIR=C:/Program Files (x86)/Windows Kits/10 WINDOWS_SDK_VERSION=10.0.19041.0 Side note: Please let me know if I should rather discuss this through another channel (maybe mailing list?). ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From github.com+1519324+primosk at openjdk.java.net Tue Mar 9 06:42:05 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Tue, 9 Mar 2021 06:42:05 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: <9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com> Message-ID: On Tue, 9 Mar 2021 06:30:46 GMT, PrimosK wrote: >>> > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): >>> > ... >>> > Please let me know if you need any further information. >>> >>> You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: >>> >>> 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. >>> 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: >>> >>> * gradle 6.3 >>> * cmake 3.13.3 >>> * ninja 1.8.2 >>> >>> 1. Have you tried building on a platform other than Windows? >> >> **1.** >> No, it doesn't work. As already stated in the [JDK-8262276](https://bugs.openjdk.java.net/browse/JDK-8262276), the build fails for me with the exactly same error also when I set: >> COMPILE_WEBKIT = true >> CONF = Release >> >> in `gradle.properties`. >> >> **2.** >> ATM I am using these libraries: >> >> - Javafx (`pull/417`) >> - Java 15 (installed on Windows) >> - Ant 1.10.5 (installed on Windows) >> - **CMake 3.13.3** (installed on Windows) >> - Visual Studio 2017 community edition (**Ninja 1.8.2**) >> - **Gradlew 6.3** >> - CygWin (installed on Windows) with the following packages: >> - bison 3.0.4-1 >> - flex 2.6.4-2 >> - gcc-g++ 10.2.0-1 >> - git 2.30.0-1 >> - gperf 3.1-1 >> - make 4.3-1 >> - makedepend 1.0.6-1 >> - openssh 8.4p1-2 >> - perl 5.32.1-1 >> - python27 2.7.18-4 >> - ruby 2.6.4-1 >> - unzip 6.0-17 >> - zip 3.0-12 >> >> But I am seeing exactly the same error. >> >> **3.** >> No - I've tried it only with Windows as we need debug symbols there... >> >> Side note: >> >> Could you guys please provide me with the versions of the above libraries that are used in the case of your CI build system? Is now Visual Studio the only difference? I tried to check it by myself by going through the log files at https://github.com/arun-Joseph/jfx/runs/2028653928 but I couldn't found CygWin plugin versions (bison, flex...). >> >> Tomorrow I will try building it using Visual Studio 2019. > > Hi everyone, > > Today I've tried to create a build using **Visual Studio 2019** but with no success. I am seeing the same error. > > There is a complete output of `./gradlew --scan`: > [build-output.txt](https://github.com/openjdk/jfx/files/6106294/build-output.txt) > > The build scan is available there: > https://scans.gradle.com/s/dimrfirscg7hm > > OS: > - Windows 10 > > Repository: > - JavaFx (pull/417) > > Installed libraries: > - Java 15 (15+36-1562) > - Ant 1.10.5 > - Gradlew 6.3 > - CMake 3.13.3 > - Visual Studio 2019 community edition (VS2019-16.7.2+1.0) > - Ninja 1.8.2 > > CygWin (installed on Windows) with the following packages: > - bison 3.0.4-1 > - flex 2.6.4-2 > - gcc-g++ 10.2.0-1 > - git 2.30.0-1 > - gperf 3.1-1 > - make 4.3-1 > - makedepend 1.0.6-1 > - openssh 8.4p1-2 > - perl 5.32.1-1 > - python27 2.7.18-4 > - ruby 2.6.4-1 > - unzip 6.0-17 > - zip 3.0-12 > > `gradle.properties`: > COMPILE_WEBKIT = true > CONF = DebugNative > > Content of `windows.tools`: > WINDOWS_VS_DEVENVDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE > WINDOWS_VS_DEVENVCMD=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/devenv.com > WINDOWS_VS_VCINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC > WINDOWS_VS_VSINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community > WINDOWS_VS_MSVCDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC > WINDOWS_VS_INCLUDE=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0.19 041.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt > WINDOWS_VS_LIB=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x86 > WINDOWS_VS_LIBPATH=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/10.0.19041.0;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/10.0.19041.0;C:/Windows/Microsoft.NET/Framework/v4.0.30319 > WINDOWS_VS_PATH=;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX64/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/x64;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPe rfCollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x64;C:/Program Files (x86)/Windows Kits/10/bin/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX86/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExt ensions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x86;C:/Program Files (x86)/Windows Kits/10/bin/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework/v4.0.30319;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/cygwin64/usr/local/bin;C:/cygwin64/bin;C:/Windows/system32;C:/Windows;C:/Windows/System32/Wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Windows/System32/OpenSSH;C:/Program Files/CMake/bin;C:/Users/WDA GUtilityAccount/AppData/Local/Microsoft/WindowsApps;C:/Program Files/jdk-15/bin;C:/apache-ant-1.10.5/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja > WINDOWS_VS_VER=150 > WINDOWS_SDK_DIR=C:/Program Files (x86)/Windows Kits/10 > WINDOWS_SDK_VERSION=10.0.19041.0 > > Side note: > Please let me know if I should rather discuss this through another channel (maybe mailing list?). Update: I've just found out there are few **_C1060: compiler is out of heap space_** in my log file so this might very well explain it. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From jvos at openjdk.java.net Tue Mar 9 09:07:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 9 Mar 2021 09:07:10 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 23:43:10 GMT, Jose Pereda wrote: > This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). > > As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. > > Tested successfully on Android with ComboBox controls in different positions. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 265: > 263: } > 264: > 265: private void sendScrollStartedEvent(double centerAbsX, double centerAbsY, int touchCount) { It's probably better to use other names here, as centerAbsX/Y are already used as instance variables. ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From kcr at openjdk.java.net Tue Mar 9 12:00:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Mar 2021 12:00:10 GMT Subject: RFR: 8263204: Add Gradle Wrapper Validation Action [v4] In-Reply-To: References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 22:47:16 GMT, John Neffenger wrote: >> See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: >> >> 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. >> 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. >> 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Restore the Gradle version 4.8 Wrapper JAR file Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From kcr at openjdk.java.net Tue Mar 9 12:40:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Mar 2021 12:40:05 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: <9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com> Message-ID: On Tue, 9 Mar 2021 06:30:46 GMT, PrimosK wrote: > Please let me know if I should rather discuss this through another channel (maybe mailing list?). If you still have problems after resolving your "out of heap space" issue, then asking on the [openjfx-dev](https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev) mailing list is probably best, given that you are unable to compile WebKit even without `-PCONF=DebugNative`. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From kcr at openjdk.java.net Tue Mar 9 12:44:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Mar 2021 12:44:07 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: <3g9fklgIWJpn1xuUYNxvhtIfa2FXCPJVI7U3n5pqJx8=.4e54644e-771d-42af-84d6-f2eaccccfbba@github.com> On Mon, 8 Mar 2021 15:07:30 GMT, Johan Vos wrote: > when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. Interesting. I don't see this problem. I am able to build with or without `--info`. I am also now (with this patch) able to build with or without `-PCONF=DebugNative`. As mentioned earlier, some of the unit tests fail to run in debug mode. Arun will look into these failures. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From ebresie at gmail.com Tue Mar 9 13:34:34 2021 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 9 Mar 2021 07:34:34 -0600 Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: bxYKsEAlmKt9tF9Nq10WccoWCNLBgLccNu1OzqkVKYE=.9cb6d1d3-fad0-4da2-b079-3b2e3fad1b30@github.com References: O8yuSvUEhykyDXtj3tgIfMOZiS_N7tbCRGmWtxYVZPw=.4d8a36d4-8811-4006-8eca-7d3c34284660@github.com m0ubnVRIBEHyM4DEhPsBgv_xuigPkjb_cYoHOII94LE=.975e13f2-416d-40eb-8d43-5b6722e394da@github.com Fy7dRFZLr6-iGzDFJJ_HHtYdzKelacJB-ILa6y2BUfU=.fa8c91d9-46e1-4b75-ae4f-ae6713ecc873@github.com E7rPmpgxSgi3B9sZmbBfOoDbTY1JX1eWUww5reYWXXY=.518ed5e5-9b29-489d-a3a3-7c1ab81d72ea@github.com 9ils6KD8jv-MKMnc9ZNxOwNK9NvdISvZR7Qus6gOw-0=.57d44af9-5b30-4ffe-bd5b-01837adfe8b4@github.com ZOcrHdMNbZRpq1lJh7rcZwXlnSNthzJz8vVf4H0HYMU=.2b067b05-ab52-4a2f-994d-1468d8407220@github.com ZOcrHdMNbZRpq1lJh7rcZwXlnSNthzJz8vVf4H0HYMU=.2b067b05-ab52-4a2f-994d-1468d8407220@github.com Message-ID: Silly question, when building, at what point would any sort of memory setting be provided? Is that a lack of enough physical memory, not enough memory based on an environment variable or config file? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On March 9, 2021 at 12:42:05 AM CST, PrimosK wrote: > On Tue, 9 Mar 2021 06:30:46 GMT, PrimosK wrote: > > > > > > The build failed again. The only difference I can spot at this time is the line at which the build failed (it changed from 3445 to 3453): > > > > > ... > > > > > Please let me know if you need any further information. > > > > > > > > You might be running into a different problem then, since this patch solve the compilation problem for Arun, for me, and for our CI build systems, when building with `-PCONF=DebugNative` (as a side note, we have some problems running the unit tests, but that's a separate issue). I have a couple questions for you: > > > > > > > > 1. Does the build work if you build without `-PCONF=DebugNative`? If it still fails, then you are definitely running into a different problem, likely something in your environment. > > > > 2. Can you double-check the versions of the build tools that you are using? We build using Visual Studio 2019 rather than the 2017 that you are using, although it will build with the latest VS2017 update. The versions of the other tools should be: > > > > > > > > * gradle 6.3 > > > > * cmake 3.13.3 > > > > * ninja 1.8.2 > > > > > > > > 1. Have you tried building on a platform other than Windows? > > > > > > **1.** > > > No, it doesn't work. As already stated in the [JDK-8262276](https://bugs.openjdk.java.net/browse/JDK-8262276), the build fails for me with the exactly same error also when I set: > > > COMPILE_WEBKIT = true > > > CONF = Release > > > > > > in `gradle.properties`. > > > > > > **2.** > > > ATM I am using these libraries: > > > > > > - Javafx (`pull/417`) > > > - Java 15 (installed on Windows) > > > - Ant 1.10.5 (installed on Windows) > > > - **CMake 3.13.3** (installed on Windows) > > > - Visual Studio 2017 community edition (**Ninja 1.8.2**) > > > - **Gradlew 6.3** > > > - CygWin (installed on Windows) with the following packages: > > > - bison 3.0.4-1 > > > - flex 2.6.4-2 > > > - gcc-g++ 10.2.0-1 > > > - git 2.30.0-1 > > > - gperf 3.1-1 > > > - make 4.3-1 > > > - makedepend 1.0.6-1 > > > - openssh 8.4p1-2 > > > - perl 5.32.1-1 > > > - python27 2.7.18-4 > > > - ruby 2.6.4-1 > > > - unzip 6.0-17 > > > - zip 3.0-12 > > > > > > But I am seeing exactly the same error. > > > > > > **3.** > > > No - I've tried it only with Windows as we need debug symbols there... > > > > > > Side note: > > > > > > Could you guys please provide me with the versions of the above libraries that are used in the case of your CI build system? Is now Visual Studio the only difference? I tried to check it by myself by going through the log files at https://github.com/arun-Joseph/jfx/runs/2028653928 but I couldn't found CygWin plugin versions (bison, flex...). > > > > > > Tomorrow I will try building it using Visual Studio 2019. > > > > Hi everyone, > > > > Today I've tried to create a build using **Visual Studio 2019** but with no success. I am seeing the same error. > > > > There is a complete output of `./gradlew --scan`: > > [build-output.txt](https://github.com/openjdk/jfx/files/6106294/build-output.txt) > > > > The build scan is available there: > > https://scans.gradle.com/s/dimrfirscg7hm > > > > OS: > > - Windows 10 > > > > Repository: > > - JavaFx (pull/417) > > > > Installed libraries: > > - Java 15 (15+36-1562) > > - Ant 1.10.5 > > - Gradlew 6.3 > > - CMake 3.13.3 > > - Visual Studio 2019 community edition (VS2019-16.7.2+1.0) > > - Ninja 1.8.2 > > > > CygWin (installed on Windows) with the following packages: > > - bison 3.0.4-1 > > - flex 2.6.4-2 > > - gcc-g++ 10.2.0-1 > > - git 2.30.0-1 > > - gperf 3.1-1 > > - make 4.3-1 > > - makedepend 1.0.6-1 > > - openssh 8.4p1-2 > > - perl 5.32.1-1 > > - python27 2.7.18-4 > > - ruby 2.6.4-1 > > - unzip 6.0-17 > > - zip 3.0-12 > > > > `gradle.properties`: > > COMPILE_WEBKIT = true > > CONF = DebugNative > > > > Content of `windows.tools`: > > WINDOWS_VS_DEVENVDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE > > WINDOWS_VS_DEVENVCMD=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/devenv.com (http://devenv.com) > > WINDOWS_VS_VCINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC > > WINDOWS_VS_VSINSTALLDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community > > WINDOWS_VS_MSVCDIR=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC > > WINDOWS_VS_INCLUDE=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/include;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/include;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/ucrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/shared;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/um;C:/Program Files (x86)/Windows Kits/10/include/10.0. 19 > 041.0/winrt;C:/Program Files (x86)/Windows Kits/10/include/10.0.19041.0/cppwinrt > > WINDOWS_VS_LIB=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x64;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/ucrt/x86;C:/Program Files (x86)/Windows Kits/10/lib/10.0.19041.0/um/x86 > > WINDOWS_VS_LIBPATH=C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/10.0.19041.0;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program (http://Microsoft.NET/Framework64/v4.0.30319;C:/Program) Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/ATLMFC/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/lib/x86/store/references;C:/Program Files (x86)/Windows Kits/10/UnionMetadata/10.0.19041.0;C:/Program Files (x86)/Windows Kits/10/References/1 0.0.19041.0;C:/Windows/Microsoft.NET/Framework/v4.0.30319 (http://Microsoft.NET/Framework/v4.0.30319) > > WINDOWS_VS_PATH=;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX64/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/x64;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VS Pe > rfCollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x64;C:/Program Files (x86)/Windows Kits/10/bin/x64;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework64/v4.0.30319;C:/Program (http://Microsoft.NET/Framework64/v4.0.30319;C:/Program) Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/Extensions/Microsoft/IntelliCode/CLI;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/HostX86/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/VC/VCPackages;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/TestWindow;C:/Program Files (x86)/Mi crosoft Visual Studio/2019/Community/Common7/IDE/CommonExt > ensions/Microsoft/TeamFoundation/Team Explorer;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/bin/Roslyn;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Team Tools/Performance Tools;C:/Program Files (x86)/Microsoft Visual Studio/Shared/Common/VSPerfCollectionTools/vs2019/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/devinit;C:/Program Files (x86)/Windows Kits/10/bin/10.0.19041.0/x86;C:/Program Files (x86)/Windows Kits/10/bin/x86;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin;C:/Windows/Microsoft.NET/Framework/v4.0.30319;C:/Program (http://Microsoft.NET/Framework/v4.0.30319;C:/Program) Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/Tools/;C:/cygwin64/usr/local/bin;C:/cygwin64/bin;C:/Windows/system32;C:/Windows;C:/Windows/System32/Wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Windows/ System32/OpenSSH;C:/Program Files/CMake/bin;C:/Users/WDA > GUtilityAccount/AppData/Local/Microsoft/WindowsApps;C:/Program Files/jdk-15/bin;C:/apache-ant-1.10.5/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin;C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja > > WINDOWS_VS_VER=150 > > WINDOWS_SDK_DIR=C:/Program Files (x86)/Windows Kits/10 > > WINDOWS_SDK_VERSION=10.0.19041.0 > > > > Side note: > > Please let me know if I should rather discuss this through another channel (maybe mailing list?). > > Update: > I've just found out there are few **_C1060: compiler is out of heap space_** in my log file so this might very well explain it. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/417 From github.com+1519324+primosk at openjdk.java.net Tue Mar 9 14:59:09 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Tue, 9 Mar 2021 14:59:09 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: <3g9fklgIWJpn1xuUYNxvhtIfa2FXCPJVI7U3n5pqJx8=.4e54644e-771d-42af-84d6-f2eaccccfbba@github.com> References: <3g9fklgIWJpn1xuUYNxvhtIfa2FXCPJVI7U3n5pqJx8=.4e54644e-771d-42af-84d6-f2eaccccfbba@github.com> Message-ID: On Tue, 9 Mar 2021 12:41:41 GMT, Kevin Rushforth wrote: >> when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. > >> when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. > > Interesting. I don't see this problem. I am able to build with or without `--info`. I am also now (with this patch) able to build with or without `-PCONF=DebugNative`. > > As mentioned earlier, some of the unit tests fail to run in debug mode. Arun will look into these failures. I think this is actually a lack of physical memory. I was doing tests inside Windows Sandbox which has 4GB of memory by default. After repeating the build procedure inside VM with 16GB of memory the build succeeded. Side question - I see there was: `C:\jfx\build\modular-sdk\modules_libs\javafx.web\jfxwebkit.dll` produced but I don't see any PDB files (debugging and project state information) despite `CONF = DebugNative` is present. Am I missing something? ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From ajoseph at openjdk.java.net Tue Mar 9 15:49:08 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 9 Mar 2021 15:49:08 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: <3g9fklgIWJpn1xuUYNxvhtIfa2FXCPJVI7U3n5pqJx8=.4e54644e-771d-42af-84d6-f2eaccccfbba@github.com> Message-ID: On Tue, 9 Mar 2021 14:55:59 GMT, PrimosK wrote: >>> when passing `--info` to gradle, the build succeeds. Without passing `--info` it fails. I'll do more testing later. >> >> Interesting. I don't see this problem. I am able to build with or without `--info`. I am also now (with this patch) able to build with or without `-PCONF=DebugNative`. >> >> As mentioned earlier, some of the unit tests fail to run in debug mode. Arun will look into these failures. > > I think this is actually a lack of physical memory. I was doing tests inside Windows Sandbox which has 4GB of memory by default. > > After repeating the build procedure inside VM with 16GB of memory the build succeeded. > > Side question - I see there was: > `C:\jfx\build\modular-sdk\modules_libs\javafx.web\jfxwebkit.dll` > produced but I don't see any PDB files (debugging and project state information) despite `CONF = DebugNative` is present. Am I missing something? The PDB files are located in `modules\javafx.web\build\win\Debug\bin\jfxwebkit.pdb`. At present, they are not copied to sdk. This bug (https://bugs.openjdk.java.net/browse/JDK-8263259) is created to fix the same. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From jpereda at openjdk.java.net Tue Mar 9 16:45:11 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Mar 2021 16:45:11 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 09:04:00 GMT, Johan Vos wrote: >> This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). >> >> As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. >> >> Tested successfully on Android with ComboBox controls in different positions. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 265: > >> 263: } >> 264: >> 265: private void sendScrollStartedEvent(double centerAbsX, double centerAbsY, int touchCount) { > > It's probably better to use other names here, as centerAbsX/Y are already used as instance variables. Yes, that makes sense. We could refactor the three `sendScrollXXXEvent` methods to something like: sendScrollXXXEvent(double xAbs, double yAbs, int touchCount) or to: sendScrollXXXEvent(double x, double y, double xAbs, double yAbs, int touchCount) Any preference? ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From github.com+1413266+jgneff at openjdk.java.net Tue Mar 9 17:34:08 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 9 Mar 2021 17:34:08 GMT Subject: Integrated: 8263204: Add Gradle Wrapper Validation Action In-Reply-To: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> References: <3--jRLEdbsAfTuZx0PMCyMbLDNOgU6bg50M9KwOnsyA=.3f8e377c-36b3-4fe1-a161-a25048fac858@github.com> Message-ID: On Mon, 8 Mar 2021 20:34:05 GMT, John Neffenger wrote: > See the [Gradle Wrapper Validation Action](https://github.com/marketplace/actions/gradle-wrapper-validation) for details on this pull request. I'll test the changes with the following sequence of commits: > > 1. This commit adds a tampered Gradle Wrapper JAR file, which should go undetected. > 2. The next commit will add the Official Gradle Wrapper Validation Action, which should detect the tampered file. > 3. The final commit will remove the tampered file and replace it with the original Gradle 4.8 Wrapper. This pull request has now been integrated. Changeset: 75b4c15c Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/75b4c15c Stats: 14 lines in 1 file changed: 11 ins; 3 del; 0 mod 8263204: Add Gradle Wrapper Validation Action Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/419 From jpereda at openjdk.java.net Tue Mar 9 18:51:22 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Mar 2021 18:51:22 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode [v2] In-Reply-To: References: Message-ID: > This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). > > As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. > > Tested successfully on Android with ComboBox controls in different positions. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Refactor parameter names ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/420/files - new: https://git.openjdk.java.net/jfx/pull/420/files/eab42ceb..fedc68a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=420&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=420&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/420.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/420/head:pull/420 PR: https://git.openjdk.java.net/jfx/pull/420 From jpereda at openjdk.java.net Tue Mar 9 18:51:22 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Mar 2021 18:51:22 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode [v2] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 16:42:09 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/ScrollGestureRecognizer.java line 265: >> >>> 263: } >>> 264: >>> 265: private void sendScrollStartedEvent(double centerAbsX, double centerAbsY, int touchCount) { >> >> It's probably better to use other names here, as centerAbsX/Y are already used as instance variables. > > Yes, that makes sense. > > We could refactor the three `sendScrollXXXEvent` methods to something like: > > sendScrollXXXEvent(double xAbs, double yAbs, int touchCount) > or to: > > sendScrollXXXEvent(double x, double y, double xAbs, double yAbs, int touchCount) > > Any preference? For now, I've done the first approach, given that there is no conflict with the `centerX, centerY` variables. ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From fkirmaier at openjdk.java.net Tue Mar 9 21:54:17 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 9 Mar 2021 21:54:17 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup Message-ID: Fixing deadlock when calling Application.launch in the FXThread after Platform.startup ------------- Commit messages: - JDK-8263322 Changes: https://git.openjdk.java.net/jfx/pull/421/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263322 Stats: 85 lines in 2 files changed: 84 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From github.com+1413266+jgneff at openjdk.java.net Tue Mar 9 22:24:16 2021 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 9 Mar 2021 22:24:16 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Message-ID: This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. #### Motivation The only conclusive way to verify a software package is to reproduce it. That's the main point of the Linux Foundation article [Preventing Supply Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source Supply Chain Security. "In the longer term," he writes, "I know of only one strong countermeasure for this kind of attack: verified reproducible builds." It's not enough anymore to trust the person, organization, or company that publishes a software package. David Wheeler explains, "Assuming a system can 'never be broken into' is a failing strategy." As I see it, any project that doesn't yet allow for reproducible builds is on a list of possible attack vectors. I'd like to get OpenJFX off that list. This is a huge undertaking involving the entire open-source community. Just [Debian, for example][3], has over 30,000 source packages to build in a reproducible manner. Remarkably, it's almost 96 percent complete. The OpenJFX package is one of three percent still failing. Our first step towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` specification][4]. #### Implementation When you want to build 30,000 packages in a reproducible manner, [command-line flags][5] unique to each package aren't so helpful. The environment variable needs to be set, anyway, for the tools invoked by Gradle to pick it up. We could allow for a Gradle property in addition to the environment variable. The Gradle property would override the default current date and export the environment variable, and the environment variable would override the command-line property. I think it makes more sense in the OpenJFX build to support the environment variable directly. With these considerations, I added the support just as recommended by the example for "Java / gradle" on the Reproducible Builds [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does the reverse, using the *configure* script option `--with-source-date` to export the `SOURCE_DATE_EPOCH` environment variable. [1]: https://github.com/openjdk/jfx/pull/99 [2]: https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds [3]: https://tests.reproducible-builds.org/debian/reproducible.html [4]: https://reproducible-builds.org/specs/source-date-epoch/ [5]: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion [6]: https://reproducible-builds.org/docs/source-date-epoch/ [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 ------------- Commit messages: - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Changes: https://git.openjdk.java.net/jfx/pull/422/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=422&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238650 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/422.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/422/head:pull/422 PR: https://git.openjdk.java.net/jfx/pull/422 From kcr at openjdk.java.net Tue Mar 9 22:38:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Mar 2021 22:38:10 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <9xhmEnlgzmpderHWX82GxweaVeW64T2TbgLM4SVwFz8=.2b2270db-8f60-4b1b-94a4-bb911d78ae08@github.com> On Tue, 9 Mar 2021 22:20:10 GMT, John Neffenger wrote: > This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. > > #### Motivation > > The only conclusive way to verify a software package is to reproduce it. That's the main point of the Linux Foundation article [Preventing Supply Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source Supply Chain Security. "In the longer term," he writes, "I know of only one strong countermeasure for this kind of attack: verified reproducible builds." > > It's not enough anymore to trust the person, organization, or company that publishes a software package. David Wheeler explains, "Assuming a system can 'never be broken into' is a failing strategy." As I see it, any project that doesn't yet allow for reproducible builds is on a list of possible attack vectors. I'd like to get OpenJFX off that list. > > This is a huge undertaking involving the entire open-source community. Just [Debian, for example][3], has over 30,000 source packages to build in a reproducible manner. Remarkably, it's almost 96 percent complete. The OpenJFX package is one of three percent still failing. Our first step towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` specification][4]. > > #### Implementation > > When you want to build 30,000 packages in a reproducible manner, [command-line flags][5] unique to each package aren't so helpful. The environment variable needs to be set, anyway, for the tools invoked by Gradle to pick it up. We could allow for a Gradle property in addition to the environment variable. The Gradle property would override the default current date and export the environment variable, and the environment variable would override the command-line property. I think it makes more sense in the OpenJFX build to support the environment variable directly. > > With these considerations, I added the support just as recommended by the example for "Java / gradle" on the Reproducible Builds [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does the reverse, using the *configure* script option `--with-source-date` to export the `SOURCE_DATE_EPOCH` environment variable. > > [1]: https://github.com/openjdk/jfx/pull/99 > [2]: https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds > [3]: https://tests.reproducible-builds.org/debian/reproducible.html > [4]: https://reproducible-builds.org/specs/source-date-epoch/ > [5]: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion > [6]: https://reproducible-builds.org/docs/source-date-epoch/ > [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 This is a simple enough change by itself, but since it is intended as the start of a larger effort, I'd like @johanvos (or someone else he designates from Gluon) to be a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From github.com+1519324+primosk at openjdk.java.net Wed Mar 10 10:03:08 2021 From: github.com+1519324+primosk at openjdk.java.net (PrimosK) Date: Wed, 10 Mar 2021 10:03:08 GMT Subject: RFR: 8262276: Debug build of WebKit fails In-Reply-To: References: <3g9fklgIWJpn1xuUYNxvhtIfa2FXCPJVI7U3n5pqJx8=.4e54644e-771d-42af-84d6-f2eaccccfbba@github.com> Message-ID: On Tue, 9 Mar 2021 15:46:06 GMT, Arun Joseph wrote: >> I think this is actually a lack of physical memory. I was doing tests inside Windows Sandbox which has 4GB of memory by default. >> >> After repeating the build procedure inside VM with 16GB of memory the build succeeded. >> >> Side question - I see there was: >> `C:\jfx\build\modular-sdk\modules_libs\javafx.web\jfxwebkit.dll` >> produced but I don't see any PDB files (debugging and project state information) despite `CONF = DebugNative` is present. Am I missing something? > > The PDB files are located in `modules\javafx.web\build\win\Debug\bin\jfxwebkit.pdb`. At present, they are not copied to sdk. This bug (https://bugs.openjdk.java.net/browse/JDK-8263259) is created to fix the same. @arun-Joseph , thanks. This is exactly where PDB files were located. To give something back to the community I've prepared a script ([openjfx-build-env.zip](https://github.com/openjdk/jfx/files/6114811/openjfx-build-env.zip)) which installs [Chocolatey ](https://chocolatey.org/) and all required dependencies needed to came up with `JavaFX` & `WebKit` Windows build environment quickly - _please use at your own risk_). I suggest using dedicated/clean Windows 10 Virtual machine or Windows Sandbox (?[with 8GB memory](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file#memory-in-mb)). Steps needed to create JavaFX build from JFX Github repository (with included pull/417): 1. Run `PowerShell` as `Administrator` 2. Run `openjfx-build-env.bat` (extracted from [openjfx-build-env.zip](https://github.com/openjdk/jfx/files/6114811/openjfx-build-env.zip)) 3. Run `Cygwin` 4. Run (last two commands won't be needed anymore after this pull request will be merged to the master): `git clone https://github.com/openjdk/jfx.git` (from `C:`) `git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417`(from `C:/jfx`) `git checkout pull/417` (from `C:/jfx`) 5. OPTIONAL: Only if `WebKit` and native debug is needed: Edit `gradle.properties` (renamed from `gradle.properties.template`) inside `C:/jfx` and set: `COMPILE_WEBKIT = true` `CONF = DebugNative` 6. Run `chmod +x gradlew` (from `C:/jfx`) 7. Run `./gradlew --console=plain` (from `C:/jfx`) Side notes: - Due to [JDK-8263259](https://bugs.openjdk.java.net/browse/JDK-8263259), the PDB files will be placed inside `c:/jfx/modules/javafx.web/build/win/Debug/bin/jfxwebkit.pdb`. ------------- PR: https://git.openjdk.java.net/jfx/pull/417 From kevin.rushforth at oracle.com Wed Mar 10 11:57:09 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Mar 2021 03:57:09 -0800 Subject: CFV: New OpenJFX Committer: John Neffenger Message-ID: I hereby nominate John Neffenger [1] to OpenJFX Committer. John is an OpenJFX community member, who has contributed 10 commits [2] to OpenJFX. Votes are due by March 24, 2021 at 12:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#jgneff [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From johan.vos at gluonhq.com Wed Mar 10 12:01:55 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 10 Mar 2021 13:01:55 +0100 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: Vote: yes On Wed, Mar 10, 2021 at 12:58 PM Kevin Rushforth wrote: > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits [2] > to OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > > From kevin.rushforth at oracle.com Wed Mar 10 12:03:38 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Mar 2021 04:03:38 -0800 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: <8d4c5bd9-a4e3-3cfb-354b-2178ab4d304e@oracle.com> Vote: YES -- Kevin On 3/10/2021 3:57 AM, Kevin Rushforth wrote: > I hereby nominate John Neffenger [1] to OpenJFX Committer. From nlisker at gmail.com Wed Mar 10 12:06:23 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Mar 2021 14:06:23 +0200 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: <8d4c5bd9-a4e3-3cfb-354b-2178ab4d304e@oracle.com> References: <8d4c5bd9-a4e3-3cfb-354b-2178ab4d304e@oracle.com> Message-ID: Vote: YES On Wed, Mar 10, 2021 at 2:04 PM Kevin Rushforth wrote: > Vote: YES > > -- Kevin > > > On 3/10/2021 3:57 AM, Kevin Rushforth wrote: > > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > From jvos at openjdk.java.net Wed Mar 10 12:23:09 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 10 Mar 2021 12:23:09 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode [v2] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 18:48:49 GMT, Jose Pereda wrote: >> Yes, that makes sense. >> >> We could refactor the three `sendScrollXXXEvent` methods to something like: >> >> sendScrollXXXEvent(double xAbs, double yAbs, int touchCount) >> or to: >> >> sendScrollXXXEvent(double x, double y, double xAbs, double yAbs, int touchCount) >> >> Any preference? > > For now, I've done the first approach, given that there is no conflict with the `centerX, centerY` variables. I am ok with that. With this rename, the conflict is resolved. ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From kcr at openjdk.java.net Wed Mar 10 12:23:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 12:23:08 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode [v2] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 18:51:22 GMT, Jose Pereda wrote: >> This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). >> >> As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. >> >> Tested successfully on Android with ComboBox controls in different positions. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Refactor parameter names Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From jvos at openjdk.java.net Wed Mar 10 12:39:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 10 Mar 2021 12:39:08 GMT Subject: RFR: 8206253: No/Wrong scroll events from touch input in window mode [v2] In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 18:51:22 GMT, Jose Pereda wrote: >> This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). >> >> As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. >> >> Tested successfully on Android with ComboBox controls in different positions. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Refactor parameter names Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From jpereda at openjdk.java.net Wed Mar 10 12:39:09 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 10 Mar 2021 12:39:09 GMT Subject: Integrated: 8206253: No/Wrong scroll events from touch input in window mode In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 23:43:10 GMT, Jose Pereda wrote: > This PR changes the parameter names to accommodate class calculations related to screen event coordinates (AbsX, AbsY). > > As [discussed](https://bugs.openjdk.java.net/browse/JDK-8206253?focusedCommentId=14405707&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14405707), the sendScrollXXXEvent methods are currently passing the screen coordinates (AbsX, AbsY) to the local ones, but they shouldn't modify those, but the screen ones. > > Tested successfully on Android with ComboBox controls in different positions. This pull request has now been integrated. Changeset: 1473ea96 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/1473ea96 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8206253: No/Wrong scroll events from touch input in window mode Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/420 From guru.hb at oracle.com Wed Mar 10 13:13:07 2021 From: guru.hb at oracle.com (Guru Prasad H B) Date: Wed, 10 Mar 2021 13:13:07 +0000 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: Vote: yes Thanks, Guru > On 10-Mar-2021, at 5:27 PM, Kevin Rushforth wrote: > > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits [2] to OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From fastegal at swingempire.de Wed Mar 10 13:39:37 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 10 Mar 2021 14:39:37 +0100 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: <20210310143937.Horde.PbI8ncCNwGKgQ6B8Jrc0Hw1@webmail.df.eu> Vote: YES Zitat von Kevin Rushforth : > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits > [2] to OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] > https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer From kcr at openjdk.java.net Wed Mar 10 13:57:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 13:57:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 21:49:36 GMT, Florian Kirmaier wrote: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup The idea behind the fix is good. A few changes are needed: 1. The check should be split into two separate `if` statements, each with their own error message (see inline). 2. This should be documented in the API docs for the Application::launch method as an additional case that will throw an IllegalStateException. It will need a reasonably trivial CSR since we are specifying a new case that will cause an exception to be thrown. 3. The system test need to be broken up into separate files, one for each `@Test` method, since application launching tests need to run in their own JVM. If you want to share any code, you could refactor it into a common class that has methods (not annotated with `@Test`) to perform the testing, and separate classes that will subclass the common class, each with a single `@Test` method that simply calls into the method in the common class to do the testing. See any number of examples in `tests/system/src/test/java/test/com/sun/javafx/application/` (which is also a better location for your new test). You will want to add a cleanup method annotated with `@AfterClass` that calls `Platform.exit()`. I think three tests would be good: * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed) * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should throw ISE) * Initalize the FX runtime via Application.launch and then launch a second Application on another thread (should throw ISE). I note that when I run your test, it hangs (on Windows...I didn't try it on other platforms). gradle --info -PFULL_TEST=true cleanTest :systemTests:test --test InitializeJavaFXTest This might be resolved by ensuring each test is in its own JVM as requested above. Additional comments are inline. modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 174: > 172: final String[] args) { > 173: > 174: if (com.sun.glass.ui.Application.isEventThread() || launchCalled.getAndSet(true)) { Can you do this as two separate `if` checks, with the `isEventThread` check first? The error message for this case should be something like "Application launch must not be called on the JavaFX Application Thread". tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 1: > 1: package test.javafx.scene; 1. Missing Copyright header block 2. Other platform startup tests are in `test.com.sun.javafx.application`; can you move this test there as well? tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 24: > 22: } > 23: > 24: public static void initializeApplication() throws Exception { This method is unused, along with the `InitializeApp` class. Did you plan to use it? tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 28: > 26: Application.launch(InitializeApp.class); > 27: }).start(); > 28: appLatch.await(); Presuming you intend to use this (as opposed to removing it), this should be changed to an await with a timeout. tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 36: > 34: latch.countDown(); > 35: }); > 36: latch.await(); This needs to be changed to a flavor of await with a timeout (you can assert that it doesn't timeout). Also, I don't think this needs to be its own method, since the only thing the `initialize` method does is call this. tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 65: > 63: } catch (Exception e) { > 64: System.out.println("got exception: " + e); > 65: e.printStackTrace(); You should rethrow the exception in this case, since it indicates an unexpected error. Better still, you can remove this block and not catch the Exception in the first place. tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 53: > 51: } > 52: > 53: @Test All of the test methods should take a timeout parameter: `@Test (timeout = 15000)` tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 77: > 75: Application.launch(TestApp.class); > 76: System.out.println("Finished launch!"); > 77: throw new Exception("We excpect an error!"); Usual practice in this case would be to use the junit `Assert.fail` method (or else `throw new AssertionError(...)`). tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 56: > 54: public void testStartupThenLaunchInFX() throws Exception { > 55: CountDownLatch latch = new CountDownLatch(1); > 56: Platform.runLater(() -> { I recommend using `Util.runAndWait` since it will propagate exceptions from the `runLater` lambda to the caller. tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 68: > 66: } > 67: }); > 68: Assert.assertTrue("Timeout", latch.await(10, TimeUnit.SECONDS)); If you use `runAndWait` you won't need this. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 14:21:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 14:21:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 13:54:14 GMT, Kevin Rushforth wrote: > * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should throw ISE) That should be: * Initalize the FX runtime via Platform.startup and then launch an Application on the FX Application thread (should throw ISE) ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 15:32:08 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 15:32:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 14:17:57 GMT, Kevin Rushforth wrote: >> The idea behind the fix is good. A few changes are needed: >> >> 1. The check should be split into two separate `if` statements, each with their own error message (see inline). >> >> 2. This should be documented in the API docs for the Application::launch method as an additional case that will throw an IllegalStateException. It will need a reasonably trivial CSR since we are specifying a new case that will cause an exception to be thrown. >> >> 3. The system test need to be broken up into separate files, one for each `@Test` method, since application launching tests need to run in their own JVM. If you want to share any code, you could refactor it into a common class that has methods (not annotated with `@Test`) to perform the testing, and separate classes that will subclass the common class, each with a single `@Test` method that simply calls into the method in the common class to do the testing. See any number of examples in `tests/system/src/test/java/test/com/sun/javafx/application/` (which is also a better location for your new test). You will want to add a cleanup method annotated with `@AfterClass` that calls `Platform.exit()`. I think three tests would be good: >> * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed) >> * Initalize the FX runtime via Platform.startup and then launch an Application ~~on another thread~~ the FX Application Thread (should throw ISE) >> * Initalize the FX runtime via Application.launch and then launch a second Application on another thread (should throw ISE). >> >> >> I note that when I run your test, it hangs (on Windows...I didn't try it on other platforms). >> >> gradle --info -PFULL_TEST=true cleanTest :systemTests:test --test InitializeJavaFXTest >> >> This might be resolved by ensuring each test is in its own JVM as requested above. >> >> >> Additional comments are inline. > >> * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should throw ISE) > > That should be: > > * Initalize the FX runtime via Platform.startup and then launch an Application on the FX Application thread (should throw ISE) Contribution.MD states, that it's automatically checked for whitespace errors? Is this not true? As a clarification, this PR restores the previous behavior before Platform.startup. With this PR Application.launch and Platform.startup behaves the same. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 15:53:10 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 15:53:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 13:14:15 GMT, Kevin Rushforth wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 24: > >> 22: } >> 23: >> 24: public static void initializeApplication() throws Exception { > > This method is unused, along with the `InitializeApp` class. Did you plan to use it? It's useful to compare it with the behavior of the two methods to start JavaFX. If it would be my codebase, I would keep it, so if someone investigates it later, it's easier to investigate for differences. But I can also delete it, what would you prefer? > modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 174: > >> 172: final String[] args) { >> 173: >> 174: if (com.sun.glass.ui.Application.isEventThread() || launchCalled.getAndSet(true)) { > > Can you do this as two separate `if` checks, with the `isEventThread` check first? The error message for this case should be something like "Application launch must not be called on the JavaFX Application Thread". done > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 1: > >> 1: package test.javafx.scene; > > 1. Missing Copyright header block > 2. Other platform startup tests are in `test.com.sun.javafx.application`; can you move this test there as well? done ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 16:07:10 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:07:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 13:19:03 GMT, Kevin Rushforth wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 65: > >> 63: } catch (Exception e) { >> 64: System.out.println("got exception: " + e); >> 65: e.printStackTrace(); > > You should rethrow the exception in this case, since it indicates an unexpected error. Better still, you can remove this block and not catch the Exception in the first place. If I would rethrow it, it would just print it out, it's currently doing. I could save the Exception in a variable, to rethrow it from the other thread, but I think that would be unnecessarily complicated. > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 53: > >> 51: } >> 52: >> 53: @Test > > All of the test methods should take a timeout parameter: `@Test (timeout = 15000)` done > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 56: > >> 54: public void testStartupThenLaunchInFX() throws Exception { >> 55: CountDownLatch latch = new CountDownLatch(1); >> 56: Platform.runLater(() -> { > > I recommend using `Util.runAndWait` since it will propagate exceptions from the `runLater` lambda to the caller. This significantly simplifies the test! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 16:22:30 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:22:30 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: - JDK-8263322 Added missing change - JDK-8263322 Small changes based on code review - JDK-8263322 Small changes based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/9a70d349..6abe618e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=00-01 Stats: 195 lines in 3 files changed: 109 ins; 84 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 16:22:31 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:22:31 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 13:50:02 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: >> >> - JDK-8263322 >> Added missing change >> - JDK-8263322 >> Small changes based on code review >> - JDK-8263322 >> Small changes based on code review > > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 68: > >> 66: } >> 67: }); >> 68: Assert.assertTrue("Timeout", latch.await(10, TimeUnit.SECONDS)); > > If you use `runAndWait` you won't need this. Done > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 77: > >> 75: Application.launch(TestApp.class); >> 76: System.out.println("Finished launch!"); >> 77: throw new Exception("We excpect an error!"); > > Usual practice in this case would be to use the junit `Assert.fail` method (or else `throw new AssertionError(...)`). done > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 28: > >> 26: Application.launch(InitializeApp.class); >> 27: }).start(); >> 28: appLatch.await(); > > Presuming you intend to use this (as opposed to removing it), this should be changed to an await with a timeout. done ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 16:26:07 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:26:07 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 15:29:37 GMT, Florian Kirmaier wrote: >>> * Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should throw ISE) >> >> That should be: >> >> * Initalize the FX runtime via Platform.startup and then launch an Application on the FX Application thread (should throw ISE) > > Contribution.MD states, that it's automatically checked for whitespace errors? Is this not true? > > As a clarification, this PR restores the previous behavior before Platform.startup. With this PR Application.launch and Platform.startup behaves the same. I forgot to commit a part of the fix, which is why the second test hang. It's now part of the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 16:26:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:26:11 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 13:15:43 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: >> >> - JDK-8263322 >> Added missing change >> - JDK-8263322 >> Small changes based on code review >> - JDK-8263322 >> Small changes based on code review > > tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 36: > >> 34: latch.countDown(); >> 35: }); >> 36: latch.await(); > > This needs to be changed to a flavor of await with a timeout (you can assert that it doesn't timeout). Also, I don't think this needs to be its own method, since the only thing the `initialize` method does is call this. I actually prefer it as a separate method. It makes it more reusable. And it makes it also easier to compare the behavior, between the two possible ways to initialize JavaFX ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From jose.pereda at gluonhq.com Wed Mar 10 16:28:02 2021 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Wed, 10 Mar 2021 17:28:02 +0100 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: Vote: YES Jose On Wed, Mar 10, 2021 at 12:57 PM Kevin Rushforth wrote: > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits [2] > to OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > > -- From arun.aj.joseph at oracle.com Wed Mar 10 16:28:12 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Wed, 10 Mar 2021 16:28:12 +0000 Subject: CFV: New OpenJFX Committer: John Neffenger In-Reply-To: References: Message-ID: <6312D7D9-E609-4B00-BE7D-C1B1A220DB20@oracle.com> Vote: YES ? Arun Joseph > On 10-Mar-2021, at 5:27 PM, Kevin Rushforth wrote: > > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits [2] to OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com&s=author-date&type=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From fkirmaier at openjdk.java.net Wed Mar 10 16:45:08 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 16:45:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:23:53 GMT, Florian Kirmaier wrote: >> Contribution.MD states, that it's automatically checked for whitespace errors? Is this not true? >> >> As a clarification, this PR restores the previous behavior before Platform.startup. With this PR Application.launch and Platform.startup behaves the same. > > I forgot to commit a part of the fix, which is why the second test hang. It's now part of the PR. About the CSR: This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 17:05:05 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 17:05:05 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:42:41 GMT, Florian Kirmaier wrote: >> I forgot to commit a part of the fix, which is why the second test hang. It's now part of the PR. > > About the CSR: > This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. > How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? `Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed)` I don't think that should succeed. I would expect it to throw an exception. If that would be the case, then both startup-methods would result in different states, which wouldn't be so good. I've now restructured the tests. It's a total of 4 tests. 2 after Application.launch and 2 after Platform.startup. In both cases I check what happens, a Application is launched from another thread, or from the javafx thread. In all cases an exception is expected. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 17:05:08 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 17:05:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:01:42 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 65: >> >>> 63: } catch (Exception e) { >>> 64: System.out.println("got exception: " + e); >>> 65: e.printStackTrace(); >> >> You should rethrow the exception in this case, since it indicates an unexpected error. Better still, you can remove this block and not catch the Exception in the first place. > > If I would rethrow it, it would just print it out, it's currently doing. I could save the Exception in a variable, to rethrow it from the other thread, but I think that would be unnecessarily complicated. Not relevant anymore, because of Util.runAndWait() >> tests/system/src/test/java/test/javafx/scene/InitializeJavaFXTest.java line 24: >> >>> 22: } >>> 23: >>> 24: public static void initializeApplication() throws Exception { >> >> This method is unused, along with the `InitializeApp` class. Did you plan to use it? > > It's useful to compare it with the behavior of the two methods to start JavaFX. > If it would be my codebase, I would keep it, so if someone investigates it later, it's easier to investigate for differences. But I can also delete it, what would you prefer? It's now used because i added more test cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From arapte at openjdk.java.net Wed Mar 10 17:20:19 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 10 Mar 2021 17:20:19 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX Message-ID: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double java.lang.Character java.lang.Boolean This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. Calls like the following to create array get autoboxed so it does not require a change. `Double dArr[] = new Double[] {10.1, 20.2};` ------------- Commit messages: - replace depr cotrs with valueOf() Changes: https://git.openjdk.java.net/jfx/pull/423/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257512 Stats: 75 lines in 27 files changed: 0 ins; 0 del; 75 mod Patch: https://git.openjdk.java.net/jfx/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/423/head:pull/423 PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Wed Mar 10 17:23:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 17:23:12 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 15:29:37 GMT, Florian Kirmaier wrote: > Contribution.MD states, that it's automatically checked for whitespace errors? Is this not true? Yes, Skara's jcheck does basic sanity checking (tabs, trailing white space, line endings). Why do you ask? I didn't raise this as a question in this PR. Do you have reason to believe that this isn't working? > As a clarification, this PR restores the previous behavior before Platform.startup. With this PR Application.launch and Platform.startup behaves the same. Not quite. `Platform.startup` is a new method that was previously available only via an internal implementation class, which simply starts up the FX runtime without running any of the application life cycle. Once this was added to public API, it became possible (but is seldom necessary) to call `Platform.startup` and then later call `Application.launch`, which should work fine as long as the latter call is _not_ on the FX Application Thread. What was missed is a check to make sure that `Application.launch` is not called on the FX Application thread. This should have been documented to throw an exception. It is somewhat similar to, but not the same as, the case of calling `Application.launch` more than once. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 17:27:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 17:27:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 17:00:41 GMT, Florian Kirmaier wrote: > Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed) I don't think that should succeed. I would expect it to throw an exception. If that would be the case, then both startup-methods would result in different states, which wouldn't be so good. No, this really should succeed. Internally, it is a similar case to what the special Java launcher method does when launching a Java class that extends `Application` and which may have a main method that calls `Application.launch`. We check the various cases of launching an application with/without it extending `Application` in the tests under [tests/system/src/test/java/test/launchertest/](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/launchertest/). ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 17:33:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 17:33:05 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 17:24:47 GMT, Kevin Rushforth wrote: >> `Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed)` >> I don't think that should succeed. I would expect it to throw an exception. If that would be the case, then both startup-methods would result in different states, which wouldn't be so good. >> >> I've now restructured the tests. >> It's a total of 4 tests. 2 after Application.launch and 2 after Platform.startup. >> In both cases I check what happens, a Application is launched from another thread, or from the javafx thread. In all cases an exception is expected. > >> Initalize the FX runtime via Platform.startup and then launch an Application on another thread (should succeed) > I don't think that should succeed. I would expect it to throw an exception. If that would be the case, then both startup-methods would result in different states, which wouldn't be so good. > > No, this really should succeed. Internally, it is a similar case to what the special Java launcher method does when launching a Java class that extends `Application` and which may have a main method that calls `Application.launch`. We check the various cases of launching an application with/without it extending `Application` in the tests under [tests/system/src/test/java/test/launchertest/](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/launchertest/). To further clarify, `Application.launch` will start the FX platform only if it is not already started by some other means. Then it will (in all cases) run the applicaiton life-cycle. Note this from the `Application` class docs: Life-cycle The entry point for JavaFX applications is the Application class. The JavaFX runtime does the following, in order, whenever an application is launched: 1. Starts the JavaFX runtime, if not already started (see Platform.startup(Runnable) for more information) ... ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 17:33:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 17:33:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v2] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:42:41 GMT, Florian Kirmaier wrote: > About the CSR: > This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. Not quite. See my reply above. > How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? Almost. Go to your bug in JBS, and use the "More" pull-down menu. There is a "Create CSR" option. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From tsayao at openjdk.java.net Wed Mar 10 18:23:24 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Mar 2021 18:23:24 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25] In-Reply-To: References: Message-ID: <6sIpV4u0HHYjpWFr8WdQKwm-_c9QDcHEOHC4By8T_7k=.dada501a-782f-4e76-a194-35fba3f40210@github.com> > This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): > ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix bug in content oriented child windows ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/6a48f2a6..0dd478a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=23-24 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From arapte at openjdk.java.net Wed Mar 10 19:24:22 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 10 Mar 2021 19:24:22 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v2] In-Reply-To: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: > The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. > > java.lang.Byte > java.lang.Short > java.lang.Integer > java.lang.Long > java.lang.Float > java.lang.Double > java.lang.Character > java.lang.Boolean > > This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. > Calls like the following to create array get autoboxed so it does not require a change. > > `Double dArr[] = new Double[] {10.1, 20.2};` Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: use autoboxing when obvious ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/423/files - new: https://git.openjdk.java.net/jfx/pull/423/files/17e6ea28..588ec4ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/423/head:pull/423 PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Wed Mar 10 19:40:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 19:40:10 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v2] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: On Wed, 10 Mar 2021 19:24:22 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > use autoboxing when obvious Looks good with a couple problems (in code that we must not be building) noted below. apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInterop.java line 222: > 220: private Pane createBrowser() { > 221: Double widthDouble = Integer.valueOf(PANEL_WIDTH).doubleValue(); > 222: Double heightDouble = Integer.valueOf(PANEL_HEIGHT).doubleValue(); I think `Double.valueof(PANEL_WIDTH)` would be simpler? Or, you can use auto-boxing and just say: Double widthDouble = PANEL_WIDTH; Double heightDouble = PANEL_HEIGHT; modules/javafx.graphics/src/test/jslc/com/sun/scenario/effect/compiler/parser/PrimaryExprTest.java line 68: > 66: Expr tree = parseTreeFor("1.234"); > 67: assertTrue(tree instanceof LiteralExpr); > 68: assertEquals(((LiteralExpr)tree).getValue(), Float.valueOf(1.234)); We must not be building or running these tests. This won't compile without casting to `float` or using a float constant, `1.234f`. modules/javafx.graphics/src/test/jslc/com/sun/scenario/effect/compiler/parser/UnaryExprTest.java line 62: > 60: UnaryExpr tree = parseTreeFor("+72.4"); > 61: assertEquals(tree.getOp(), UnaryOpType.PLUS); > 62: assertEquals(((LiteralExpr)tree.getExpr()).getValue(), Float.valueOf(72.4)); Same problem here (and in the next method). This needs to be `72.4f` ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Wed Mar 10 19:49:25 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 10 Mar 2021 19:49:25 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> > The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. > > java.lang.Byte > java.lang.Short > java.lang.Integer > java.lang.Long > java.lang.Float > java.lang.Double > java.lang.Character > java.lang.Boolean > > This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. > Calls like the following to create array get autoboxed so it does not require a change. > > `Double dArr[] = new Double[] {10.1, 20.2};` Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: correct Float.valueOf() ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/423/files - new: https://git.openjdk.java.net/jfx/pull/423/files/588ec4ce..e34c6a8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/423/head:pull/423 PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Wed Mar 10 20:03:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 20:03:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: <5K-Ek9l2IvzWMZNkSflf_ufB7wo3o0rXZck0gCvMxzU=.9263d98e-64bc-4f6b-92ba-5b1abdd7b147@github.com> On Wed, 10 Mar 2021 19:37:51 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > Looks good with a couple problems (in code that we must not be building) noted below. This is a simple change, but it would be good to have a second pair of eyes on it. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Wed Mar 10 21:22:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 21:22:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> Message-ID: <3eXuZzh7Bn3O0u0MMbVyGA-f1VPr1v-O6qwpHk2OjZc=.744e56c4-df14-442d-965a-0ce4a8caa679@github.com> On Wed, 10 Mar 2021 19:49:25 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct Float.valueOf() Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From fkirmaier at openjdk.java.net Wed Mar 10 21:54:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 21:54:32 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v3] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: - JDK-8263322 removed unused imports, added missing change - JDK-8263322 Updated the unit-test so they match the wanted behavior discussed in the PR - JDK-8263322 Added the tests for both cases, when JavaFX was initialized with Application.launch and Platform.startup ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/6abe618e..0abc71e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=01-02 Stats: 307 lines in 5 files changed: 200 ins; 106 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 22:06:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 22:06:09 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 21:54:32 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: > > - JDK-8263322 > removed unused imports, added missing change > - JDK-8263322 > Updated the unit-test so they match the wanted behavior discussed in the PR > - JDK-8263322 > Added the tests for both cases, when JavaFX was initialized with Application.launch and Platform.startup modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 661: > 659: > 660: // Note, this method is called on the FX Application Thread > 661: PlatformImpl.startup(() -> startupLatch.countDown()); Glad to see this reverted. I was going to ask you why it was needed (it shouldn't be). ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 22:13:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 22:13:03 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 17:30:21 GMT, Kevin Rushforth wrote: >> About the CSR: >> This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. >> How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? > >> About the CSR: >> This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. > > Not quite. See my reply above. > >> How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? > > Almost. Go to your bug in JBS, and use the "More" pull-down menu. There is a "Create CSR" option. Regarding the CSR, it is only concerned with the public API, including the specification (javadoc-generated API documentation), and any behavioral changes. You can leave the CSR in the Draft state until there is something to document in the Specification section, and the review of the PR is far enough along so that those changes are likely to be final. For this PR, the changes that need to be documented in the CSR haven't been made yet. The changes needed will be in the javadoc comments of public `Application::launch` methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 22:29:22 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 22:29:22 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene Message-ID: Fixing a memory leak. A node hard references its old parent after CSS layout and getting removed. This shouldn't be the case, this is very counterintuitive. The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. This should be fine because the CSS should only depend on it if it's still the real parent. In that case, it doesn't get collected. ------------- Commit messages: - 8263402 Changes: https://git.openjdk.java.net/jfx/pull/424/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263402 Stats: 116 lines in 2 files changed: 107 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Wed Mar 10 22:33:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 22:33:07 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier wrote: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. Since this touches CSS, it needs a second reviewer. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Wed Mar 10 22:35:31 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 22:35:31 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 updated the javadoc to mention the new case. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/0abc71e0..c16b6067 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 22:35:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 22:35:32 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:10:04 GMT, Kevin Rushforth wrote: >>> About the CSR: >>> This commit actually restores original behavior, when JavaFX was called with Application.launch, so it's not really a change in the API, it's more like a fix for a regression. >> >> Not quite. See my reply above. >> >>> How would I create a CSR? Just by creating a ticket at https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20CSR with the type CSR? >> >> Almost. Go to your bug in JBS, and use the "More" pull-down menu. There is a "Create CSR" option. > > Regarding the CSR, it is only concerned with the public API, including the specification (javadoc-generated API documentation), and any behavioral changes. > > You can leave the CSR in the Draft state until there is something to document in the Specification section, and the review of the PR is far enough along so that those changes are likely to be final. For this PR, the changes that need to be documented in the CSR haven't been made yet. The changes needed will be in the javadoc comments of public `Application::launch` methods. I've now added the new Exception to the JavaDoc of the Application. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 22:35:33 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 22:35:33 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:03:52 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with three additional commits since the last revision: >> >> - JDK-8263322 >> removed unused imports, added missing change >> - JDK-8263322 >> Updated the unit-test so they match the wanted behavior discussed in the PR >> - JDK-8263322 >> Added the tests for both cases, when JavaFX was initialized with Application.launch and Platform.startup > > modules/javafx.graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java line 661: > >> 659: >> 660: // Note, this method is called on the FX Application Thread >> 661: PlatformImpl.startup(() -> startupLatch.countDown()); > > Glad to see this reverted. I was going to ask you why it was needed (it shouldn't be). It was added, because I thought it shouldn't be allowed to call Application.launch after Platform.startup. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 22:43:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 22:43:07 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:32:26 GMT, Florian Kirmaier wrote: >> Regarding the CSR, it is only concerned with the public API, including the specification (javadoc-generated API documentation), and any behavioral changes. >> >> You can leave the CSR in the Draft state until there is something to document in the Specification section, and the review of the PR is far enough along so that those changes are likely to be final. For this PR, the changes that need to be documented in the CSR haven't been made yet. The changes needed will be in the javadoc comments of public `Application::launch` methods. > > I've now added the new Exception to the JavaDoc of the Application. The API spec changes look good. You can add that to the Specification section of the CSR. You can either paste the diffs for the javadoc comments, or else just add the one new line for each method. Either way, the name of the class (javafx.application.Application) should be listed prior to the diffs / additions. Also, make it clear which methods are getting the new `@exception` tags. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 10 22:54:05 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 10 Mar 2021 22:54:05 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: <4_XZ8FQbqcA-Kj0h6ycy2gVj6vvnkjgYKFhSKnMbQsA=.64d0108a-dc94-4ecd-80b5-2e611124b2e0@github.com> On Wed, 10 Mar 2021 22:40:26 GMT, Kevin Rushforth wrote: >> I've now added the new Exception to the JavaDoc of the Application. > > The API spec changes look good. You can add that to the Specification section of the CSR. You can either paste the diffs for the javadoc comments, or else just add the one new line for each method. Either way, the name of the class (javafx.application.Application) should be listed prior to the diffs / additions. Also, make it clear which methods are getting the new `@exception` tags. Great, I've updated the CSR! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 23:20:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 23:20:09 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > updated the javadoc to mention the new case. The fix looks good. I have a couple comments on the tests, mainly about making them more robust by having only a single `@Test` method in each file. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXStartupTest.java line 46: > 44: > 45: @Test (timeout = 15000) > 46: public void testStartupThenLaunch() throws Exception { It will be more robust for these two test methods to be in separate files. Otherwise they might interfere with each other. If `testStartupThenLaunchInFX` runs first, then an error in that test (e.g., if the fix isn't applied and it times out) will cause the `testStartupThenLaunch` to fail. Conversely, if `testStartupThenLaunch` runs first, then the system is in a state where the Application has already been started by the time `testStartupThenLaunchInFX` runs. It will still pass, but won't be a solid test of the fix, since that case would fail today. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 46: > 44: > 45: @Test (timeout = 15000) > 46: public void testStartupThenLaunch() throws Exception { It will be more robust for these two test methods to be in separate files. Otherwise they might interfere with each other. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 80: > 78: System.out.println("Finished launch!"); > 79: Assert.fail("Error: No Exception was thrown - expected IllegalStateException"); > 80: } catch (IllegalStateException e) { Maybe add a comment that this exception is expected? ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 10 23:49:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Mar 2021 23:49:06 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon In-Reply-To: References: Message-ID: <90H30Rt8yC99rx4dtTsWcWN83TsUZXuOAcWTDSHT2iM=.407b3315-ecea-47e3-b964-bfc9de15e180@github.com> On Fri, 26 Feb 2021 03:58:17 GMT, Alexander Matveev wrote: > - Added support to compile media on arm. > - libffi is based on 3.3. This breaks the build on Windows. cl.exe -DFFI_BUILDING -DGSTREAMER_LITE -I../../../3rd_party/libffi/include -I../../../3rd_party/libffi/include/win/x64 -nologo -W3 -WX- -EHsc -GS -fp:precise -Gm- -Zc:wchar_t -Zc:forScope -Gd -wd"4430" -analyze- -errorReport:queue -O1 -Oy -MD -Gy -GF -DX86_WIN64 -TC -c -Fo.../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj ../../../3rd_party/libffi/src/java_raw_api.c ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: Cannot open include file: 'ffitarget.h': No such file or directory make[1]: *** [Makefile.ffi:79: .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/closures.obj] Error 2 make[1]: *** Waiting for unfinished jobs.... java_raw_api.c ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: Cannot open include file: 'ffitarget.h': No such file or directory make[1]: *** [Makefile.ffi:79: .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj] Error 2 make[1]: Leaving directory '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' make: *** [Makefile:60: .../jfx/modules/javafx.media/build/native/win/Release/libffi.lib] Error 2 make: Leaving directory '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' FAILURE: Build failed with an exception. * Where: Build file '...\jfx\build.gradle' line: 3284 * What went wrong: Execution failed for task ':media:buildWinGlib'. > Process 'command 'make'' finished with non-zero exit value 2 ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/412 From nlisker at openjdk.java.net Thu Mar 11 00:48:11 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 11 Mar 2021 00:48:11 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> Message-ID: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> On Wed, 10 Mar 2021 19:49:25 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct Float.valueOf() I left some comments where I think autoboxing does the same work explicit boxing does. Unless I'm missing something, all these places can be simplified. apps/samples/Ensemble8/src/app/java/ensemble/samplepage/PieChartDataVisualizer.java line 92: > 90: } > 91: try { > 92: return (Double) Double.valueOf(string); Looks like an unnecessary cast. apps/toys/LayoutDemo/src/layout/CustomPane.java line 92: > 90: Collections.sort(sortedManagedChidlren, (c1, c2) > 91: -> Double.valueOf(c2.prefHeight(-1)).compareTo( > 92: Double.valueOf(c1.prefHeight(-1)))); This can be replaced with Collections.sort(sortedManagedChidlren, (c1, c2) -> Double.compare(c2.prefHeight(-1), c1.prefHeight(-1))); or Collections.sort(sortedManagedChidlren, Comparator.comparingDouble(n -> n.prefHeight(-1)).reversed()); I think. Same for the other places that do comparing. modules/javafx.controls/src/test/java/test/javafx/scene/control/MenuBarTest.java line 582: > 580: > 581: boolean click = true; > 582: final Boolean firstClick = Boolean.valueOf(click); Autobox? apps/samples/3DViewer/src/main/java/com/javafx/experiments/shape3d/SkinningMesh.java line 110: > 108: for (int i = 0; i < nPoints; i++) { > 109: if (weights[j][i] != 0.0f) { > 110: weightIndices[j].add(Integer.valueOf(i)); Autobox? apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SampleTableModel.java line 54: > 52: {Double.valueOf(567), Double.valueOf(956), Double.valueOf(1154)}, > 53: {Double.valueOf(1292), Double.valueOf(1665), Double.valueOf(1927)}, > 54: {Double.valueOf(1292), Double.valueOf(2559), Double.valueOf(2774)} Autobox? modules/javafx.base/src/test/java/test/com/sun/javafx/collections/MappingChangeTest.java line 52: > 50: @Test > 51: public void testAddRemove() { > 52: Change change = new NonIterableChange.SimpleRemovedChange(0, 1, Integer.valueOf(5), originalList); Autobox? modules/javafx.base/src/test/java/test/javafx/util/DurationTest.java line 289: > 287: @Test public void add_ZERO_and_INDEFINITE_ResultsInIndefinite() { > 288: //assertTrue(0.0 + Double.POSITIVE_INFINITY == Double.POSITIVE_INFINITY); // sanity check > 289: assertEquals(Double.valueOf(Double.POSITIVE_INFINITY), Double.valueOf(0.0 + Double.POSITIVE_INFINITY)); // sanity check I don't understand why convert to `Double` for the assertion test, but more than that, I don't understand why this test is needed for `Duration`. Isn't this is a guaranteed behavior of fp arithmetic? Same for all other such asserts. modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYChartTest.java line 85: > 83: Font f = yaxis.getTickLabelFont(); > 84: // default caspian value for font size = 10 > 85: assertEquals(10, Double.valueOf(f.getSize()).intValue()); Any reason to convert `f.getSize()` to `int` and then to `Double`? Is it for flooring the `double`? Same for the other places. modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 643: > 641: ComboBox cb = new ComboBox(); > 642: StringConverter sc = cb.getConverter(); > 643: assertEquals("42", sc.toString(Integer.valueOf(42))); Autobox? modules/javafx.graphics/src/main/java/com/sun/prism/es2/X11GLFactory.java line 171: > 169: deviceDetails.put("XVisualID", Long.valueOf(nGetVisualID(nativeCtxInfo))); > 170: deviceDetails.put("XDisplay", Long.valueOf(nGetDisplay(nativeCtxInfo))); > 171: deviceDetails.put("XScreenID", Integer.valueOf(nGetDefaultScreen(nativeCtxInfo))); Autobox? modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java line 64: > 62: @Override > 63: public ResourceFactory getResourceFactory(Screen screen) { > 64: Integer index = Integer.valueOf(screen.getAdapterOrdinal()); Autobox? Same for the other similar places. modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 477: > 475: v.set(value); > 476: NodeTest.syncNode(node); > 477: assertTrue(numbersEquals(Integer.valueOf(value), Autobox? Same for similar places. modules/javafx.web/src/ios/java/javafx/scene/web/JSONDecoder.java line 101: > 99: long val = Long.parseLong(sNum); > 100: if ((val <= Integer.MAX_VALUE) && (Integer.MIN_VALUE <= val)) { > 101: return Integer.valueOf(int) val); Autobox? ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 05:50:12 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 05:50:12 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: <41WJPSMg6DE_LUi3MQIQpgm000eQb51Jad-YEWA_2SU=.d8ae1350-0242-481c-a28e-8aa8a2a3b966@github.com> On Thu, 11 Mar 2021 00:41:48 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.web/src/ios/java/javafx/scene/web/JSONDecoder.java line 101: > >> 99: long val = Long.parseLong(sNum); >> 100: if ((val <= Integer.MAX_VALUE) && (Integer.MIN_VALUE <= val)) { >> 101: return Integer.valueOf(int) val); > > Autobox? I think, when LHS is of type `Object`, it is good to be explicit on creating Object, it improves readability. In this case, type of val is `long`, so autobox would create an object of `Long` not `Integer`. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 06:04:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 06:04:09 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 00:26:38 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 643: > >> 641: ComboBox cb = new ComboBox(); >> 642: StringConverter sc = cb.getConverter(); >> 643: assertEquals("42", sc.toString(Integer.valueOf(42))); > > Autobox? >From this test code the type of parameter of `sc.toString()` is not obvious. `StringConverter` is a template class. `toString()` accepts a template type parameter. Using autoboxing at such instances would hamper the readability. So I think autoboxing should be used only when the type is very obvious from just a glance of code. > apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SampleTableModel.java line 54: > >> 52: {Double.valueOf(567), Double.valueOf(956), Double.valueOf(1154)}, >> 53: {Double.valueOf(1292), Double.valueOf(1665), Double.valueOf(1927)}, >> 54: {Double.valueOf(1292), Double.valueOf(2559), Double.valueOf(2774)} > > Autobox? The array is of type Object. When LHS is Object then autobox chooses a suitable type by itself. So here, if we autobox then the values get autoboxed to `Integer`. We do not intend to change the test behavior as part of this fix so let's keep this as `Double.valueOf`. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 06:10:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 06:10:10 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 00:12:25 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.base/src/test/java/test/com/sun/javafx/collections/MappingChangeTest.java line 52: > >> 50: @Test >> 51: public void testAddRemove() { >> 52: Change change = new NonIterableChange.SimpleRemovedChange(0, 1, Integer.valueOf(5), originalList); > > Autobox? First two parameters are primitive type integer and the third parameter is template type. Changing it to autobox would make it less readable. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 06:32:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 06:32:10 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: <1a4pm3ctdRk0vM7OExvxB5tGM6rYEfJORDAaAT9CwBo=.052ebe1a-7381-47ec-886f-56b1e2b2eb2c@github.com> On Thu, 11 Mar 2021 00:23:48 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYChartTest.java line 85: > >> 83: Font f = yaxis.getTickLabelFont(); >> 84: // default caspian value for font size = 10 >> 85: assertEquals(10, Double.valueOf(f.getSize()).intValue()); > > Any reason to convert `f.getSize()` to `int` and then to `Double`? Is it for flooring the `double`? > > Same for the other places. `f.getSize()` returns a double value, the statement can also be written as `assertEquals(10, f.getSize(), 0f);` But, as this change is a cleanup and is intended to remove the calls to deprecated constructors, I think it should be limited to changing calls to autobox or to use `valueOf()` method. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From almatvee at openjdk.java.net Thu Mar 11 06:42:29 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 11 Mar 2021 06:42:29 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] In-Reply-To: References: Message-ID: > - Added support to compile media on arm. > - libffi is based on 3.3. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/412/files - new: https://git.openjdk.java.net/jfx/pull/412/files/99f8788f..ca11a752 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=412&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=412&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/412.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/412/head:pull/412 PR: https://git.openjdk.java.net/jfx/pull/412 From almatvee at openjdk.java.net Thu Mar 11 06:42:29 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 11 Mar 2021 06:42:29 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] In-Reply-To: <90H30Rt8yC99rx4dtTsWcWN83TsUZXuOAcWTDSHT2iM=.407b3315-ecea-47e3-b964-bfc9de15e180@github.com> References: <90H30Rt8yC99rx4dtTsWcWN83TsUZXuOAcWTDSHT2iM=.407b3315-ecea-47e3-b964-bfc9de15e180@github.com> Message-ID: On Wed, 10 Mar 2021 23:46:39 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] > > This breaks the build on Windows. > > cl.exe -DFFI_BUILDING -DGSTREAMER_LITE -I../../../3rd_party/libffi/include -I../../../3rd_party/libffi/include/win/x64 -nologo -W3 -WX- -EHsc -GS -fp:precise -Gm- -Zc:wchar_t -Zc:forScope -Gd -wd"4430" -analyze- -errorReport:queue -O1 -Oy -MD -Gy -GF -DX86_WIN64 -TC -c -Fo.../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj ../../../3rd_party/libffi/src/java_raw_api.c > ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: Cannot open include file: 'ffitarget.h': No such file or directory > make[1]: *** [Makefile.ffi:79: .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/closures.obj] Error 2 > make[1]: *** Waiting for unfinished jobs.... > java_raw_api.c > ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: Cannot open include file: 'ffitarget.h': No such file or directory > make[1]: *** [Makefile.ffi:79: .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj] Error 2 > make[1]: Leaving directory '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' > make: *** [Makefile:60: .../jfx/modules/javafx.media/build/native/win/Release/libffi.lib] Error 2 > make: Leaving directory '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' > > FAILURE: Build failed with an exception. > > * Where: > Build file '...\jfx\build.gradle' line: 3284 > > * What went wrong: > Execution failed for task ':media:buildWinGlib'. >> Process 'command 'make'' finished with non-zero exit value 2 Windows build should be fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/412 From arapte at openjdk.java.net Thu Mar 11 06:55:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 06:55:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 00:18:17 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.base/src/test/java/test/javafx/util/DurationTest.java line 289: > >> 287: @Test public void add_ZERO_and_INDEFINITE_ResultsInIndefinite() { >> 288: //assertTrue(0.0 + Double.POSITIVE_INFINITY == Double.POSITIVE_INFINITY); // sanity check >> 289: assertEquals(Double.valueOf(Double.POSITIVE_INFINITY), Double.valueOf(0.0 + Double.POSITIVE_INFINITY)); // sanity check > > I don't understand why convert to `Double` for the assertion test, but more than that, I don't understand why this test is needed for `Duration`. Isn't this is a guaranteed behavior of fp arithmetic? > > Same for all other such asserts. >From the look of these tests, many look unnecessary to be here. But As these tests exist from very beginning, there might have been a good reason that they were added. As long as they don't harm, and if you don't have any hard call on them, let's keep them as is.(with just the `valueOf` change) ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 06:59:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 06:59:09 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Wed, 10 Mar 2021 23:59:05 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > apps/toys/LayoutDemo/src/layout/CustomPane.java line 92: > >> 90: Collections.sort(sortedManagedChidlren, (c1, c2) >> 91: -> Double.valueOf(c2.prefHeight(-1)).compareTo( >> 92: Double.valueOf(c1.prefHeight(-1)))); > > This can be replaced with > > Collections.sort(sortedManagedChidlren, (c1, c2) -> Double.compare(c2.prefHeight(-1), c1.prefHeight(-1))); > > or > > Collections.sort(sortedManagedChidlren, Comparator.comparingDouble(n -> n.prefHeight(-1)).reversed()); > > I think. > Same for the other places that do comparing. As this change is a cleanup and intended to replace deprecated constructor calls with autoboxing or `valueOf()` method, I think we should not make other changes as part of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 07:37:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 07:37:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 00:29:41 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.graphics/src/main/java/com/sun/prism/es2/X11GLFactory.java line 171: > >> 169: deviceDetails.put("XVisualID", Long.valueOf(nGetVisualID(nativeCtxInfo))); >> 170: deviceDetails.put("XDisplay", Long.valueOf(nGetDisplay(nativeCtxInfo))); >> 171: deviceDetails.put("XScreenID", Integer.valueOf(nGetDefaultScreen(nativeCtxInfo))); > > Autobox? I think the statements look more readable the way they are. The type of LHS of the expression is Object, so a reader will have to find return type of those methods to understand what type of Object gets created. I think such calls which use a return value from a method should use explicit calls. But then on other side in case if return type of the method is changed, then we need to also change these explicit calls. Sounds like a decision to make for other time. What do you think ? ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 07:41:23 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 07:41:23 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v4] In-Reply-To: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: <3THfjQH4PzSd6g9Z2JlJD13YXDS1GlxOJiRP55-IXGc=.29513dac-da2b-45cf-b310-cd650096453d@github.com> > The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. > > java.lang.Byte > java.lang.Short > java.lang.Integer > java.lang.Long > java.lang.Float > java.lang.Double > java.lang.Character > java.lang.Boolean > > This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. > Calls like the following to create array get autoboxed so it does not require a change. > > `Double dArr[] = new Double[] {10.1, 20.2};` Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: some more autoboxing ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/423/files - new: https://git.openjdk.java.net/jfx/pull/423/files/e34c6a8f..b104b373 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=02-03 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/423/head:pull/423 PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Thu Mar 11 13:36:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 13:36:09 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <41WJPSMg6DE_LUi3MQIQpgm000eQb51Jad-YEWA_2SU=.d8ae1350-0242-481c-a28e-8aa8a2a3b966@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> <41WJPSMg6DE_LUi3MQIQpgm000eQb51Jad-YEWA_2SU=.d8ae1350-0242-481c-a28e-8aa8a2a3b966@github.com> Message-ID: On Thu, 11 Mar 2021 05:47:31 GMT, Ambarish Rapte wrote: >> modules/javafx.web/src/ios/java/javafx/scene/web/JSONDecoder.java line 101: >> >>> 99: long val = Long.parseLong(sNum); >>> 100: if ((val <= Integer.MAX_VALUE) && (Integer.MIN_VALUE <= val)) { >>> 101: return Integer.valueOf(int) val); >> >> Autobox? > > I think, when LHS is of type `Object`, it is good to be explicit on creating Object, it improves readability. > In this case, type of val is `long`, so autobox would create an object of `Long` not `Integer`. RIght, this can lead to bugs if you aren't careful. See the discussion in [JDK-8154213](https://bugs.openjdk.java.net/browse/JDK-8154213). I recommend autoboxing only for those cases where the type is clearly specified. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Thu Mar 11 13:41:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 13:41:14 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v4] In-Reply-To: <3THfjQH4PzSd6g9Z2JlJD13YXDS1GlxOJiRP55-IXGc=.29513dac-da2b-45cf-b310-cd650096453d@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <3THfjQH4PzSd6g9Z2JlJD13YXDS1GlxOJiRP55-IXGc=.29513dac-da2b-45cf-b310-cd650096453d@github.com> Message-ID: <4YQCZNjhQmelQmZuKBL5vH-ehp5Se8TJYuEhG9mYr28=.8277f308-299d-4d5b-b33f-ff46f30316ce@github.com> On Thu, 11 Mar 2021 07:41:23 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > some more autoboxing Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From nlisker at openjdk.java.net Thu Mar 11 15:10:10 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 11 Mar 2021 15:10:10 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 06:01:04 GMT, Ambarish Rapte wrote: >> apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SampleTableModel.java line 54: >> >>> 52: {Double.valueOf(567), Double.valueOf(956), Double.valueOf(1154)}, >>> 53: {Double.valueOf(1292), Double.valueOf(1665), Double.valueOf(1927)}, >>> 54: {Double.valueOf(1292), Double.valueOf(2559), Double.valueOf(2774)} >> >> Autobox? > > The array is of type Object. When LHS is Object then autobox chooses a suitable type by itself. > So here, if we autobox then the values get autoboxed to `Integer`. We do not intend to change the test behavior as part of this fix so let's keep this as `Double.valueOf`. I meant that we could use a double literal: `503d` or `503.0`, but if you think this is more readable then it's fine as is. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From nlisker at openjdk.java.net Thu Mar 11 15:21:09 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 11 Mar 2021 15:21:09 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 07:34:29 GMT, Ambarish Rapte wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/es2/X11GLFactory.java line 171: >> >>> 169: deviceDetails.put("XVisualID", Long.valueOf(nGetVisualID(nativeCtxInfo))); >>> 170: deviceDetails.put("XDisplay", Long.valueOf(nGetDisplay(nativeCtxInfo))); >>> 171: deviceDetails.put("XScreenID", Integer.valueOf(nGetDefaultScreen(nativeCtxInfo))); >> >> Autobox? > > I think the statements look more readable the way they are. > The type of LHS of the expression is Object, so a reader will have to find return type of those methods to understand what type of Object gets created. I think such calls which use a return value from a method should use explicit calls. > But then on other side in case if return type of the method is changed, then we need to also change these explicit calls. > Sounds like a decision to make for other time. What do you think ? The real problem here is not finding out what the return type is, it's that the `deviceDetails` type is a raw `HashMap` so it's not clear what type should be put in the map. If it were `HashMap` then the reader should not care what gets put into the map since it's an `Object`. It's fine as is anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From nlisker at openjdk.java.net Thu Mar 11 15:21:13 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 11 Mar 2021 15:21:13 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 00:31:10 GMT, Nir Lisker wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct Float.valueOf() > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java line 64: > >> 62: @Override >> 63: public ResourceFactory getResourceFactory(Screen screen) { >> 64: Integer index = Integer.valueOf(screen.getAdapterOrdinal()); > > Autobox? > > Same for the other similar places. Do you have a preference here? ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 19:32:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 19:32:10 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: <8fw6le8CdWbYcm0Y4JJHV5vw9yN7BtYd37EYGSfxMp4=.abff2fe2-aa4e-4a62-9296-c8100d3aa350@github.com> On Thu, 11 Mar 2021 15:18:51 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java line 64: >> >>> 62: @Override >>> 63: public ResourceFactory getResourceFactory(Screen screen) { >>> 64: Integer index = Integer.valueOf(screen.getAdapterOrdinal()); >> >> Autobox? >> >> Same for the other similar places. > > Do you have a preference here? I am little more on the side to use explicit calls when using values returned by a method. The method `screen.getAdapterOrdinal()` returns an int. But if it returned short then autoboxing will fail, but `Integer.valueOf()` would still work. I don't think the method would ever change, but I still lean on using explicit call. Being explicit safe guards more and anyway both still create an object. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 19:32:11 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 19:32:11 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v3] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> <2Q338mWZGmUHSaR_C8VGmRelu1oVbyq8Vw46b957y3U=.1eb7ca4e-8959-4614-80dc-c0d9b32967d3@github.com> <2tS1xAXvul0_7cg8oKqWASlsLrdOmemKFxg2Jz5wTc8=.95aa5ceb-3922-4b8a-b794-905bab7ae8fa@github.com> Message-ID: On Thu, 11 Mar 2021 15:07:49 GMT, Nir Lisker wrote: >> The array is of type Object. When LHS is Object then autobox chooses a suitable type by itself. >> So here, if we autobox then the values get autoboxed to `Integer`. We do not intend to change the test behavior as part of this fix so let's keep this as `Double.valueOf`. > > I meant that we could use a double literal: `503d` or `503.0`, but if you think this is more readable then it's fine as is. Thanks, I would like to keep as is. ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Thu Mar 11 19:43:27 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Mar 2021 19:43:27 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v5] In-Reply-To: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: > The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. > > java.lang.Byte > java.lang.Short > java.lang.Integer > java.lang.Long > java.lang.Float > java.lang.Double > java.lang.Character > java.lang.Boolean > > This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. > Calls like the following to create array get autoboxed so it does not require a change. > > `Double dArr[] = new Double[] {10.1, 20.2};` Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: correct autobox missed in previous commit ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/423/files - new: https://git.openjdk.java.net/jfx/pull/423/files/b104b373..c90b0cc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=423&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/423/head:pull/423 PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Thu Mar 11 19:54:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 19:54:10 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] In-Reply-To: References: Message-ID: <2jj6H0Xr_LuoKQpBeAZ5uETx-dKLNaGFWjiq5zka_MU=.544efe75-6ff5-4aa9-a1d8-b154b6c04b16@github.com> On Thu, 11 Mar 2021 06:42:29 GMT, Alexander Matveev wrote: >> - Added support to compile media on arm. >> - libffi is based on 3.3. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] Looks good. I did a sanity build on all three platforms (using the default x86_64 arch for macOS) and that passed. I then did a macOS aarch64 build, and verified that it runs and can play media files. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/412 From kcr at openjdk.java.net Thu Mar 11 19:56:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 19:56:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v5] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: On Thu, 11 Mar 2021 19:43:27 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct autobox missed in previous commit Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From nlisker at openjdk.java.net Thu Mar 11 21:06:08 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 11 Mar 2021 21:06:08 GMT Subject: RFR: 8257512: Remove use of deprecated primitive constructors in JavaFX [v5] In-Reply-To: References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: <7o6sYk2subrww5xSJiz7n_A4dBkIl_xZ_iBeNTOei6k=.1c05f1f2-2409-4039-a9be-1db0856750e1@github.com> On Thu, 11 Mar 2021 19:43:27 GMT, Ambarish Rapte wrote: >> The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. >> >> java.lang.Byte >> java.lang.Short >> java.lang.Integer >> java.lang.Long >> java.lang.Float >> java.lang.Double >> java.lang.Character >> java.lang.Boolean >> >> This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. >> Calls like the following to create array get autoboxed so it does not require a change. >> >> `Double dArr[] = new Double[] {10.1, 20.2};` > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct autobox missed in previous commit Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From kcr at openjdk.java.net Thu Mar 11 22:01:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 22:01:07 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:30:27 GMT, Kevin Rushforth wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Since this touches CSS, it needs a second reviewer. I think others can review this. I do have a couple questions: 1. In general, I don't like the idea of just making everything a weak reference, since it often masks a design issue. Two exceptions are for caches and for back references to a "parent" or controlling object that has a strong reference to "this" object (most of our weak listeners fall into this latter pattern). It sounds like latter case also applies here. Can you confirm that? 2. Have you verified that all the places that use the fields that are now WeakReferences are prepared to deal with `get()` returning a null object? ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Thu Mar 11 23:43:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Mar 2021 23:43:05 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 13:05:24 GMT, Johan Vos wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] > > Marked as reviewed by jvos (Reviewer). @johanvos can you re-review? @sashamatveev since you started with Johan's patch, can you add him as a contributor? ------------- PR: https://git.openjdk.java.net/jfx/pull/412 From arapte at openjdk.java.net Fri Mar 12 04:20:11 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 12 Mar 2021 04:20:11 GMT Subject: Integrated: 8257512: Remove use of deprecated primitive constructors in JavaFX In-Reply-To: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> References: <7KQw1sbTZ7TdnkezSw1Zo24M7XTA7c_Ga7lcLh_Da8U=.aee56dca-8830-4ba4-83c3-8ab2ac61a481@github.com> Message-ID: On Wed, 10 Mar 2021 17:15:50 GMT, Ambarish Rapte wrote: > The following primitive constructors were deprecated in JDK 9 and are deprecated for removal in JDK 16. > > java.lang.Byte > java.lang.Short > java.lang.Integer > java.lang.Long > java.lang.Float > java.lang.Double > java.lang.Character > java.lang.Boolean > > This change removes call to the primitive constructors with the `valueOf()` factory method of respective class. > Calls like the following to create array get autoboxed so it does not require a change. > > `Double dArr[] = new Double[] {10.1, 20.2};` This pull request has now been integrated. Changeset: 92d62322 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/92d62322 Stats: 75 lines in 27 files changed: 0 ins; 0 del; 75 mod 8257512: Remove use of deprecated primitive constructors in JavaFX Reviewed-by: kcr, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/423 From arapte at openjdk.java.net Fri Mar 12 07:59:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 12 Mar 2021 07:59:09 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier wrote: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 106: > 104: }); > 105: } > 106: } In order to make this test similar to existing system tests, I made some relevant changes. Modified test is added below. The modified test fails with this fix, but I expected it to pass. Can you please check this. Changes are 1. `Thread.sleep()` is removed. 2. `root` and `toBeRemoved` button are now class members. 3. Scenegraph is constructed and shown in `TestApp.start()` method. public class StyleMemoryLeakTest { static CountDownLatch startupLatch; static Stage stage; static Button toBeRemoved; static Group root; public static class TestApp extends Application { @Override public void start(Stage primaryStage) throws Exception { stage = primaryStage; toBeRemoved = new Button(); root = new Group(); root.getChildren().add(toBeRemoved); stage.setScene(new Scene(root)); stage.setOnShown(l -> { Platform.runLater(() -> startupLatch.countDown()); }); stage.show(); } } @BeforeClass public static void initFX() throws Exception { startupLatch = new CountDownLatch(1); new Thread(() -> Application.launch(StyleMemoryLeakTest.TestApp.class, (String[])null)).start(); assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); } @Test public void testRootNodeMemoryLeak() throws Exception { Util.runAndWait(() -> { root.getChildren().clear(); stage.hide(); }); JMemoryBuddy.memoryTest((checker) -> { checker.assertCollectable(stage); checker.setAsReferenced(toBeRemoved); stage = null; }); } @AfterClass public static void teardownOnce() { Platform.runLater(() -> { Platform.exit(); }); } } ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From arapte at openjdk.java.net Fri Mar 12 09:05:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 12 Mar 2021 09:05:09 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > updated the javadoc to mention the new case. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. Minor year correction-> `Copyright (c) 2021,` Similar change in other test files. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From primoz.kokol at gmail.com Fri Mar 12 09:06:17 2021 From: primoz.kokol at gmail.com (=?UTF-8?Q?Primo=C5=BE_Kokol?=) Date: Fri, 12 Mar 2021 10:06:17 +0100 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) Message-ID: Hi everyone, I would need some help related to OpenJFX build. I was able to successfully prepare a build following this procedure (from pull/417 request): https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 We wanted to use it in our existing application (Java 11.0.10) to debug an issue where the application would hang/freeze for no obvious reason because of WebKit. In order to use this build we've manually overridden javafx-*.jar files in our application with the ones from the above build. We've also placed all produced DLL files in our application's "bin" folder so they are properly picked up (I've verified and I can confirm that jfxwebkit.dll produced by our debug build is loaded). After using this native debug build, the application will crash instead with: Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: Fatal program exit requested. It looks like it happens when JS code calls Java method. There is the call stack at the time when exception happens: > ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ Symbols loaded. jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. jfxwebkit.dll!JSC::jsDynamicCast(JSC::VM & vm, JSC::InternalFunction * from) Line 182 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 000000c7ef8fae90() Unknown Non-user code 000000c7ef8faf50() Unknown Non-user code 0000028d52eeedbb() Unknown Non-user code cccccccccccccccc() Unknown Non-user code 0000028d52eeedb6() Unknown Non-user code ... and partial output from the output console: .... (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as fi(x)ed, (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, (t)transformed ancestor Dirty (z)-lists, Dirty (n)ormal flow lists Traversal needs: requirements (t)raversal on descendants, (b)acking or hierarchy traversal on descendants, (r)equirements traversal on all descendants, requirements traversal on all (s)ubsequent layers, (h)ierarchy traversal on all descendants, update of paint (o)rder children Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, (c)onfig, layer conne(x)ion, (s)crolling tree Scrolling scope: box contents S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 height=650 RenderView 0x28d4d4d1cd0 S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= no compositing work to do FrameView 0000028D4F2A4CF0 performPostLayoutTasks FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 header height 0 footer height 0 fixed behavior 0 layoutViewport: (0,0) width=460 height=650 visualViewport: (0,0) width=460 height=650 (is override 0) stable origins: min: (0.00,0.00) max: (0.00,0.00) DocumentTimelinesController::updateAnimationsAndSendEvents for time 24.89s DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' EventDispatcher::dispatchEvent transitioncancel on node DIV EventDispatcher::dispatchEvent transitioncancel on node DIV ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) : JSC::JSCastingHelpers::inheritsJSTypeImpl Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: Fatal program exit requested. Note that this crash isn't happening with official JavaFX 15, 16, and 17-ea+2 builds (that are at the time of writing this available on the maven), but unfortunately we can't use these for debugging purposes. Does that indicate any issues with the native debug build or is this some regression that was introduced in the current `master` branch recently (after 17-ea+2)? Thanks for any helpful hints/advice in advance! Best regards, PrimosK From aghaisas at openjdk.java.net Fri Mar 12 10:06:09 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 12 Mar 2021 10:06:09 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger wrote: > Reverting to the old way of showing the context menu but with application > of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct > size measurement of the menu. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From arapte at openjdk.java.net Fri Mar 12 10:08:12 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 12 Mar 2021 10:08:12 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier wrote: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 180: > 178: helper.cacheContainer = new CacheContainer(node, styleMap, depth); > 179: > 180: helper.firstStyleableAncestor = new WeakReference<>(findFirstStyleableAncestor(node)); Can you investigate for an alternative to set `firstStyleableAncestor` to null when the related `node` is removed from scenegraph or may be `null` the reference to `Node.styleHelper` itself when Node is removed from scenegraph. This will result in recreating the `Node.styleHelper` next time when it is added back to scenegraph. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From arapte at openjdk.java.net Fri Mar 12 11:55:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 12 Mar 2021 11:55:09 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > updated the javadoc to mention the new case. Suggested minor changes. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 96: > 94: } catch (Exception e) { > 95: throw e; > 96: } line 91: is non reachable code and second catch block is note required. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 33: > 31: import junit.framework.Assert; > 32: import org.junit.BeforeClass; > 33: import org.junit.Test; unused imports, BeforeClass and Test. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Fri Mar 12 14:02:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 14:02:07 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Fri, 12 Mar 2021 10:03:53 GMT, Ajit Ghaisas wrote: >> Reverting to the old way of showing the context menu but with application >> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct >> size measurement of the menu. > > Marked as reviewed by aghaisas (Reviewer). This fixes the bug in question, although I see a slight regression in behavior on Windows with 125% pixel scaling (it doesn't reproduce with any other scaling value that I tried). With the original test case for [JDK-8228363](https://bugs.openjdk.java.net/browse/JDK-8228363), and `TOP` as the value of `side`, the initial menu is positioned slightly lower (by a few pixels) than it should be. See the attached image. It is correct the second and subsequent times the context menu is opened. Given that this new bug only happens with 125% scaling, it seems likely that it is a preexisting bug, and this fix merely exposes it. Can you take a look at this? If it is preexisting, then we should file a follow-on bug for this. ![ContextMenu-125](https://user-images.githubusercontent.com/34689748/110947924-9991ce00-82f5-11eb-82d2-6959ef24293f.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From fkirmaier at openjdk.java.net Fri Mar 12 14:34:23 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:34:23 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 23:10:06 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> updated the javadoc to mention the new case. > > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 80: > >> 78: System.out.println("Finished launch!"); >> 79: Assert.fail("Error: No Exception was thrown - expected IllegalStateException"); >> 80: } catch (IllegalStateException e) { > > Maybe add a comment that this exception is expected? I've added a comment and a print-statement that this is expected - on both catches for EllegalStateException ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 14:16:28 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:16:28 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v5] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 fixed the copyright headers, based on codereview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/c16b6067..145ae592 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=03-04 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 14:34:21 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:34:21 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 09:01:49 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> updated the javadoc to mention the new case. > > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. > > Minor year correction-> `Copyright (c) 2021,` > Similar change in other test files. Done, so it's the year where changes happened, ok! > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 96: > >> 94: } catch (Exception e) { >> 95: throw e; >> 96: } > > line 91: is non reachable code and second catch block is note required. Line 91 is reachable. Application.launch throws an IllegalStateException, even so, it doesn't declare it. I've Removed the second catch block. > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 33: > >> 31: import junit.framework.Assert; >> 32: import org.junit.BeforeClass; >> 33: import org.junit.Test; > > unused imports, BeforeClass and Test. removed! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 14:49:41 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:49:41 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v7] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 Seperated the unit-tests into seperate files ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/92e0fca6..a73bcf82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=05-06 Stats: 351 lines in 9 files changed: 221 ins; 130 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Fri Mar 12 14:34:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 14:34:22 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 14:18:59 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. >> >> Minor year correction-> `Copyright (c) 2021,` >> Similar change in other test files. > > Done, so it's the year where changes happened, ok! In general, the pattern is: `year_created, year_last_modified,` (with the last modified year omitted if it's the same as the creation year). ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 14:34:20 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:34:20 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v6] In-Reply-To: References: Message-ID: <_IZjxbvCYefNwrJiQQr0eVBe_lJELRAqk70q6Ejqxfc=.eae9e779-f151-4c68-b0cf-f3c16bbb4d3a@github.com> > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: - JDK-8263322 Small changes based on codereview - JDK-8263322 Some small cleanups based on codereview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/145ae592..92e0fca6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=04-05 Stats: 7 lines in 1 file changed: 3 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 16:14:24 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 16:14:24 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 21:58:40 GMT, Kevin Rushforth wrote: >> Since this touches CSS, it needs a second reviewer. > > I think others can review this. I do have a couple questions: > 1. In general, I don't like the idea of just making everything a weak reference, since it often masks a design issue. Two exceptions are for caches and for back references to a "parent" or controlling object that has a strong reference to "this" object (most of our weak listeners fall into this latter pattern). It sounds like latter case also applies here. Can you confirm that? > 2. Have you verified that all the places that use the fields that are now WeakReferences are prepared to deal with `get()` returning a null object? About whether we should use WeakReference here or not. It definitely falls into the exception for referring to the Parrent of a Node. (Or to the Parent in a more abstract sense, I think it can also be the parent of the parent, or even from another SceneGraph.) I don't know the CSS code very well, so I currently don't have the knowledge how to change it. But if we would change this variable, whenever the node is removed from the SceneGraph, my concern would be that it would have an unfavorable complexity. Currently (I hope) the complexity of removing a Node from the SceneGraph is O(1). If we would remove the stylehelper from the node, then the complexity would be O(). The current change assumes that we don't process the CSS, when a node is removed from the SG. This is why it isn't checked for null. I would argue, if this causes an Error, then it just reveals another issue, which would be preferable over a more complicated fix, and also changing the complexity of removing nodes from the SG. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Fri Mar 12 16:32:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 16:32:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v7] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 14:49:41 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > Seperated the unit-tests into seperate files Thanks for splitting up the tests. I ran them with the fix and all pass, I then ran them without the fix and only the one I expected to fail did. Before approving this, can you change the title of the JBS bug and CSR issue to match (after doing that you will also need to update this PR title) as recommended in the CSR? My suggestion is something like: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock Another thing I recommend is to comment out or remove the print statements in the tests. They are useful while debugging, but in production we prefer tests to only print something as a warning or error. I also left a few inline comments. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 35: > 33: public class InitializeJavaFXBase { > 34: > 35: Minor: there is an extra blank line here tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchBase.java line 22: > 20: Application.launch(InitializeApp.class); > 21: }).start(); > 22: appLatch.await(5, TimeUnit.SECONDS); You should `assertTrue` the return value of `await`. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXStartupBase.java line 15: > 13: latch.countDown(); > 14: }); > 15: latch.await(5, TimeUnit.SECONDS); You should `assertTrue` the return value of `await`. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch1Test.java line 41: > 39: > 40: @Test (timeout = 15000) > 41: public void testStartupThenLaunchInFX() throws Exception { Would something like `testLaunchThenLaunchInFX` be a better name? As it is, it uses the same name as the test that really does use `Platform.startup` which I found confusing. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch2Test.java line 41: > 39: > 40: @Test (timeout = 15000) > 41: public void testStartupThenLaunch() throws Exception { Would something like `testLaunchThenLaunch` be a better name? ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 14:55:08 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:55:08 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: <_fmagTVhuTsmyMKNe8wOYgg7riuqKtcMnpG5LvGyMlM=.bf8b2c16-5160-47ac-ba1d-95e815384feb@github.com> On Fri, 12 Mar 2021 11:52:24 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> updated the javadoc to mention the new case. > > Suggested minor changes. I've seperated the tests now in seperated files! Now all the changes requested should be in the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Fri Mar 12 16:32:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 16:32:11 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 14:31:17 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 80: >> >>> 78: System.out.println("Finished launch!"); >>> 79: Assert.fail("Error: No Exception was thrown - expected IllegalStateException"); >>> 80: } catch (IllegalStateException e) { >> >> Maybe add a comment that this exception is expected? > > I've added a comment and a print-statement that this is expected - on both catches for EllegalStateException The comment looks fine. See my global comment about the print statement. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Fri Mar 12 16:14:24 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 16:14:24 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v2] In-Reply-To: References: Message-ID: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8263402 Added new verison of the unit-test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/424/files - new: https://git.openjdk.java.net/jfx/pull/424/files/7f7b4569..b39db419 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=00-01 Stats: 41 lines in 1 file changed: 15 ins; 23 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424 From kevin.rushforth at oracle.com Fri Mar 12 17:54:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Mar 2021 09:54:42 -0800 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: Message-ID: Arun should be able to help you with the crash you are seeing in debug mode. Regarding the hang, do you have a test case that will reproduce it? A few different developers have reported similar hangs. We ended up closing a recently-filed bug, JDK-8260238 [1], because were (and still are) unable to reproduce the hang. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8260238 On 3/12/2021 1:06 AM, Primo? Kokol wrote: > Hi everyone, > > I would need some help related to OpenJFX build. > > I was able to successfully prepare a build following this procedure (from > pull/417 request): > https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 > > We wanted to use it in our existing application (Java 11.0.10) to debug an > issue where the application would hang/freeze for no obvious reason because > of WebKit. > > In order to use this build we've manually overridden javafx-*.jar files in > our application with the ones from the above build. > We've also placed all produced DLL files in our application's "bin" folder > so they are properly picked up (I've verified and I can confirm that > jfxwebkit.dll produced by our debug build is loaded). > > After using this native debug build, the application will crash instead > with: > Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: Fatal > program exit requested. > > It looks like it happens when JS code calls Java method. > > There is the call stack at the time when exception happens: > >> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const > char * __formal, int __formal) Line 672 C++ Symbols loaded. > > jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM > & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ > Symbols loaded. > > jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM > & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. > jfxwebkit.dll!JSC::jsDynamicCast *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line > 182 C++ Symbols loaded. > jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const > WTF::String & name, JSC::InternalFunction::NameAdditionMode > nameAdditionMode) Line 49 C++ Symbols loaded. > jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const > WTF::String & ident) Line 58 C++ Symbols loaded. > jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, > const WTF::String & name) Line 231 C++ Symbols loaded. > jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * > globalObject, const WTF::String & name, JSC::Bindings::Method * method) > Line 212 C++ Symbols loaded. > jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject > * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. > > jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject > * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) > Line 124 C++ Symbols loaded. > jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * > globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. > jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * > globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. > jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, > JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ > Symbols loaded. > jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * > pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, > JSC::JSValue baseValue, const JSC::Identifier & ident, > JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. > jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const > JSC::Instruction * pc) Line 833 C++ Symbols loaded. > jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. > 000000c7ef8fae90() Unknown Non-user code > 000000c7ef8faf50() Unknown Non-user code > 0000028d52eeedbb() Unknown Non-user code > cccccccccccccccc() Unknown Non-user code > 0000028d52eeedb6() Unknown Non-user code > > ... and partial output from the output console: > > .... > (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, > (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates > blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as fi(x)ed, > (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to > (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, (t)transformed > ancestor > Dirty (z)-lists, Dirty (n)ormal flow lists > Traversal needs: requirements (t)raversal on descendants, (b)acking or > hierarchy traversal on descendants, (r)equirements traversal on all > descendants, requirements traversal on all (s)ubsequent layers, (h)ierarchy > traversal on all descendants, update of paint (o)rder children > Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, > (c)onfig, layer conne(x)ion, (s)crolling tree > Scrolling scope: box contents > > S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 > height=650 RenderView 0x28d4d4d1cd0 > S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= no > compositing work to do > FrameView 0000028D4F2A4CF0 performPostLayoutTasks > > FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize > width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 header > height 0 footer height 0 fixed behavior 0 > layoutViewport: (0,0) width=460 height=650 > visualViewport: (0,0) width=460 height=650 (is override 0) > stable origins: min: (0.00,0.00) max: (0.00,0.00) > DocumentTimelinesController::updateAnimationsAndSendEvents for time 24.89s > DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV > 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV > 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV > 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV > 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > EventDispatcher::dispatchEvent transitioncancel on node DIV > EventDispatcher::dispatchEvent transitioncancel on node DIV > ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) > C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) > : JSC::JSCastingHelpers::inheritsJSTypeImpl > Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: Fatal > program exit requested. > > Note that this crash isn't happening with official JavaFX 15, 16, and > 17-ea+2 builds (that are at the time of writing this available on the > maven), but unfortunately we can't use these for debugging purposes. > > Does that indicate any issues with the native debug build or is this some > regression that was introduced in the current `master` branch recently > (after 17-ea+2)? > > Thanks for any helpful hints/advice in advance! > > Best regards, > PrimosK From github.com+12087024+beldenfox at openjdk.java.net Fri Mar 12 16:32:14 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Fri, 12 Mar 2021 16:32:14 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) Message-ID: This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) ------------- Commit messages: - Mac - generate KeyCodes that match user's active keyboard layout. Changes: https://git.openjdk.java.net/jfx/pull/425/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8150709 Stats: 174 lines in 2 files changed: 172 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/425.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/425/head:pull/425 PR: https://git.openjdk.java.net/jfx/pull/425 From primoz.kokol at gmail.com Fri Mar 12 18:17:32 2021 From: primoz.kokol at gmail.com (=?UTF-8?Q?Primo=C5=BE_Kokol?=) Date: Fri, 12 Mar 2021 19:17:32 +0100 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: Message-ID: Hi Kevin, Unfortunately I don't have a test case. We are using various WebViews in our production application hence we don't know where/why exactly the application freezes. We were hoping that we will be able to identify it using the native debug build (& attached debugged) but it is now unfortunately crashing with the above error. Side note: Should I contact Arun directly or is he seeing these messages? -- PrimosK On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth wrote: > Arun should be able to help you with the crash you are seeing in debug > mode. > > Regarding the hang, do you have a test case that will reproduce it? A > few different developers have reported similar hangs. We ended up > closing a recently-filed bug, JDK-8260238 [1], because were (and still > are) unable to reproduce the hang. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8260238 > > > On 3/12/2021 1:06 AM, Primo? Kokol wrote: > > Hi everyone, > > > > I would need some help related to OpenJFX build. > > > > I was able to successfully prepare a build following this procedure (from > > pull/417 request): > > https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 > > > > We wanted to use it in our existing application (Java 11.0.10) to debug > an > > issue where the application would hang/freeze for no obvious reason > because > > of WebKit. > > > > In order to use this build we've manually overridden javafx-*.jar files > in > > our application with the ones from the above build. > > We've also placed all produced DLL files in our application's "bin" > folder > > so they are properly picked up (I've verified and I can confirm that > > jfxwebkit.dll produced by our debug build is loaded). > > > > After using this native debug build, the application will crash instead > > with: > > Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: > Fatal > > program exit requested. > > > > It looks like it happens when JS code calls Java method. > > > > There is the call stack at the time when exception happens: > > > >> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. > > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, > const > > char * __formal, int __formal) Line 672 C++ Symbols loaded. > > > > > jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM > > & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ > > Symbols loaded. > > > > > jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM > > & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. > > jfxwebkit.dll!JSC::jsDynamicCast > *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line > > 182 C++ Symbols loaded. > > jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, > const > > WTF::String & name, JSC::InternalFunction::NameAdditionMode > > nameAdditionMode) Line 49 C++ Symbols loaded. > > jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const > > WTF::String & ident) Line 58 C++ Symbols loaded. > > jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, > > const WTF::String & name) Line 231 C++ Symbols loaded. > > jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * > > globalObject, const WTF::String & name, JSC::Bindings::Method * method) > > Line 212 C++ Symbols loaded. > > > jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject > > * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols > loaded. > > > > > jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject > > * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) > > Line 124 C++ Symbols loaded. > > jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * > > globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. > > jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * > > globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols > loaded. > > jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, > > JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ > > Symbols loaded. > > jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * > > pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, > > JSC::JSValue baseValue, const JSC::Identifier & ident, > > JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. > > jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, > const > > JSC::Instruction * pc) Line 833 C++ Symbols loaded. > > jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. > > 000000c7ef8fae90() Unknown Non-user code > > 000000c7ef8faf50() Unknown Non-user code > > 0000028d52eeedbb() Unknown Non-user code > > cccccccccccccccc() Unknown Non-user code > > 0000028d52eeedb6() Unknown Non-user code > > > > ... and partial output from the output console: > > > > .... > > (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, > > (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates > > blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as > fi(x)ed, > > (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to > > (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, > (t)transformed > > ancestor > > Dirty (z)-lists, Dirty (n)ormal flow lists > > Traversal needs: requirements (t)raversal on descendants, (b)acking or > > hierarchy traversal on descendants, (r)equirements traversal on all > > descendants, requirements traversal on all (s)ubsequent layers, > (h)ierarchy > > traversal on all descendants, update of paint (o)rder children > > Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, > > (c)onfig, layer conne(x)ion, (s)crolling tree > > Scrolling scope: box contents > > > > S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 > > height=650 RenderView 0x28d4d4d1cd0 > > S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= > no > > compositing work to do > > FrameView 0000028D4F2A4CF0 performPostLayoutTasks > > > > FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize > > width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 > header > > height 0 footer height 0 fixed behavior 0 > > layoutViewport: (0,0) width=460 height=650 > > visualViewport: (0,0) width=460 height=650 (is override 0) > > stable origins: min: (0.00,0.00) max: (0.00,0.00) > > DocumentTimelinesController::updateAnimationsAndSendEvents for time > 24.89s > > DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV > > 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > > KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV > > 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > > DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV > > 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > > KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV > > 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > > EventDispatcher::dispatchEvent transitioncancel on node DIV > > EventDispatcher::dispatchEvent transitioncancel on node DIV > > ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) > > > C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) > > : JSC::JSCastingHelpers::inheritsJSTypeImpl > > Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: > Fatal > > program exit requested. > > > > Note that this crash isn't happening with official JavaFX 15, 16, and > > 17-ea+2 builds (that are at the time of writing this available on the > > maven), but unfortunately we can't use these for debugging purposes. > > > > Does that indicate any issues with the native debug build or is this some > > regression that was introduced in the current `master` branch recently > > (after 17-ea+2)? > > > > Thanks for any helpful hints/advice in advance! > > > > Best regards, > > PrimosK > > From fkirmaier at openjdk.java.net Fri Mar 12 16:14:25 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 16:14:25 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v2] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 07:55:54 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263402 >> Added new verison of the unit-test > > tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 106: > >> 104: }); >> 105: } >> 106: } > > In order to make this test similar to existing system tests, I made some relevant changes. Modified test is added below. > The modified test fails with this fix, but I expected it to pass. Can you please check this. > > Changes are > 1. `Thread.sleep()` is removed. > 2. `root` and `toBeRemoved` button are now class members. > 3. Scenegraph is constructed and shown in `TestApp.start()` method. > > > public class StyleMemoryLeakTest { > > static CountDownLatch startupLatch; > static Stage stage; > static Button toBeRemoved; > static Group root; > > public static class TestApp extends Application { > > @Override > public void start(Stage primaryStage) throws Exception { > stage = primaryStage; > toBeRemoved = new Button(); > root = new Group(); > root.getChildren().add(toBeRemoved); > stage.setScene(new Scene(root)); > stage.setOnShown(l -> { > Platform.runLater(() -> startupLatch.countDown()); > }); > stage.show(); > } > } > > @BeforeClass > public static void initFX() throws Exception { > startupLatch = new CountDownLatch(1); > new Thread(() -> Application.launch(StyleMemoryLeakTest.TestApp.class, (String[])null)).start(); > assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); > } > > @Test > public void testRootNodeMemoryLeak() throws Exception { > Util.runAndWait(() -> { > root.getChildren().clear(); > stage.hide(); > }); > JMemoryBuddy.memoryTest((checker) -> { > checker.assertCollectable(stage); > checker.setAsReferenced(toBeRemoved); > stage = null; > }); > } > > @AfterClass > public static void teardownOnce() { > Platform.runLater(() -> { > Platform.exit(); > }); > } > } I've added your verison of the unit-test. You forgot `root = null;` which was why the test failed. If I would rewrite the test, I would put everything into the TestMethod. Because this way it's not necessary to set all the class-variables to null. It also wouldn't reuse the Stage of the Application. The scope of the test would be much smaller, because the actual test and the initialization of JavaFX would be separated. Should I change it that way? ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Fri Mar 12 14:55:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 12 Mar 2021 14:55:11 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 23:02:07 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> updated the javadoc to mention the new case. > > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXStartupTest.java line 46: > >> 44: >> 45: @Test (timeout = 15000) >> 46: public void testStartupThenLaunch() throws Exception { > > It will be more robust for these two test methods to be in separate files. Otherwise they might interfere with each other. If `testStartupThenLaunchInFX` runs first, then an error in that test (e.g., if the fix isn't applied and it times out) will cause the `testStartupThenLaunch` to fail. Conversely, if `testStartupThenLaunch` runs first, then the system is in a state where the Application has already been started by the time `testStartupThenLaunchInFX` runs. It will still pass, but won't be a solid test of the fix, since that case would fail today. They are seperated now! > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java line 46: > >> 44: >> 45: @Test (timeout = 15000) >> 46: public void testStartupThenLaunch() throws Exception { > > It will be more robust for these two test methods to be in separate files. Otherwise they might interfere with each other. They are seperated now! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Fri Mar 12 19:00:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 19:00:09 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: References: Message-ID: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> On Fri, 12 Mar 2021 16:27:27 GMT, Martin Fox wrote: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored. I'll review this PR later (hopefully next week some time), but I have a couple general comments: 1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout. 2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose. @tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From tschindl at openjdk.java.net Fri Mar 12 19:07:07 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 12 Mar 2021 19:07:07 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> Message-ID: On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored. > > I'll review this PR later (hopefully next week some time), but I have a couple general comments: > > 1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout. > 2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose. > > @tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this? Sure I started looking into this last week and found the place this translation is done in swing (there it is done differently but only works for keys a-z but not for other chars like #,...) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Fri Mar 12 16:32:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Mar 2021 16:32:10 GMT Subject: RFR: 8263322: Deadlock when calling Application.launch in the FXThread after Platform.startup [v4] In-Reply-To: References: Message-ID: <3XwTH2sIazzKoNt32fxJ5F2hzMuEIkTmKajOzauXxOw=.381eab18-0548-4ec1-adc4-c08e7042180f@github.com> On Fri, 12 Mar 2021 14:27:44 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 96: >> >>> 94: } catch (Exception e) { >>> 95: throw e; >>> 96: } >> >> line 91: is non reachable code and second catch block is note required. > > Line 91 is reachable. Application.launch throws an IllegalStateException, even so, it doesn't declare it. > I've Removed the second catch block. At the time Ambarish made the comment, line 91 referred to this statement: throw new Exception(); This is indeed not reachable (although the compiler can't tell that), since `Assert.fail` unconditionally throws an `AssertionError` ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From github.com+12087024+beldenfox at openjdk.java.net Fri Mar 12 21:15:07 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Fri, 12 Mar 2021 21:15:07 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> Message-ID: On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored. > > I'll review this PR later (hopefully next week some time), but I have a couple general comments: > > 1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout. > 2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose. > > @tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this? @kevinrushforth I have a manual app that can perform a simple test to verify that when a robot sends KeyCode.A through KeyCode.Z the system receives the characters 'a' to 'z'. On the Mac this sanity test was failing on German and French keyboards prior to these changes. The test is part of a key logger app I created. I chose this bug because it has a straight-forward test attached and some recent comment activity. @tomsontom Could you point me to the relevant code in Swing? I'm looking at the code but am getting lost in the layers. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From tschindl at openjdk.java.net Fri Mar 12 21:31:10 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 12 Mar 2021 21:31:10 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> Message-ID: <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> On Fri, 12 Mar 2021 21:12:41 GMT, Martin Fox wrote: >> I see that the Windows pre-submit test build failed. It's clearly not related to anything in this PR, so it can be ignored. >> >> I'll review this PR later (hopefully next week some time), but I have a couple general comments: >> >> 1. Would it be possible to provide an automated test? Maybe not since it is sensitive to the keyboard layout. >> 2. For the related bugs, we can either close them as duplicates of this bug or use the `/solves` command to list them here. Generally, we would do the former in the case it really is a single fix, as this seems to be. That's what I'll do once this bug is integrated unless there is a good reason not to. Normally we would use the earliest of the bugs, but in this case, I don't think it matters, so I have no problem with your using the one you chose. >> >> @tomsontom Since you were the one who filed [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's currently assigned to you, do you want to be the second reviewer on this? > > @kevinrushforth I have a manual app that can perform a simple test to verify that when a robot sends KeyCode.A through KeyCode.Z the system receives the characters 'a' to 'z'. On the Mac this sanity test was failing on German and French keyboards prior to these changes. The test is part of a key logger app I created. > > I chose this bug because it has a straight-forward test attached and some recent comment activity. > > @tomsontom Could you point me to the relevant code in Swing? I'm looking at the code but am getting lost in the layers. https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From arun.aj.joseph at oracle.com Sat Mar 13 04:41:11 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Sat, 13 Mar 2021 04:41:11 +0000 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: Message-ID: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> I?m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. ? Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primo? Kokol wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> loaded. >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >>> Symbols loaded. >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >>> 000000c7ef8fae90() Unknown Non-user code >>> 000000c7ef8faf50() Unknown Non-user code >>> 0000028d52eeedbb() Unknown Non-user code >>> cccccccccccccccc() Unknown Non-user code >>> 0000028d52eeedb6() Unknown Non-user code >>> >>> ... and partial output from the output console: >>> >>> .... >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >> fi(x)ed, >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >> (t)transformed >>> ancestor >>> Dirty (z)-lists, Dirty (n)ormal flow lists >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or >>> hierarchy traversal on descendants, (r)equirements traversal on all >>> descendants, requirements traversal on all (s)ubsequent layers, >> (h)ierarchy >>> traversal on all descendants, update of paint (o)rder children >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, >>> (c)onfig, layer conne(x)ion, (s)crolling tree >>> Scrolling scope: box contents >>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 >>> height=650 RenderView 0x28d4d4d1cd0 >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= >> no >>> compositing work to do >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >> header >>> height 0 footer height 0 fixed behavior 0 >>> layoutViewport: (0,0) width=460 height=650 >>> visualViewport: (0,0) width=460 height=650 (is override 0) >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >> 24.89s >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) >>> >> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >>> 17-ea+2 builds (that are at the time of writing this available on the >>> maven), but unfortunately we can't use these for debugging purposes. >>> >>> Does that indicate any issues with the native debug build or is this some >>> regression that was introduced in the current `master` branch recently >>> (after 17-ea+2)? >>> >>> Thanks for any helpful hints/advice in advance! >>> >>> Best regards, >>> PrimosK >> >> From jvos at openjdk.java.net Sat Mar 13 14:08:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 13 Mar 2021 14:08:08 GMT Subject: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 06:42:29 GMT, Alexander Matveev wrote: >> - Added support to compile media on arm. >> - libffi is based on 3.3. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/412 From jackyguo579 at gmail.com Sun Mar 14 22:31:37 2021 From: jackyguo579 at gmail.com (superminerJG) Date: Sun, 14 Mar 2021 18:31:37 -0400 Subject: Fwd: Implementing a shader API In-Reply-To: References: Message-ID: Hi everyone. This problem might have been discussed numerous times, and has been held off for quite a while. Although we are starting to see lighting improvements added to JavaFX, I feel that it's necessary for JavaFX to have some kind of custom shader pipeline. However, nobody has gotten around to doing it, so I thought that I could lend a hand. Before I get into things, I would like to know how and what I can contribute. The questions are at the bottom of the email. Thanks! - jgcodes Questions: - Can high school students sign the OCA? (I saw the job title field on the form and wasn't so sure I was legally allowed to sign it) - When I implement the shader API, should it use some kind of GLSL mapping, or should I try to extend JSL to work in 3D? - Should I have sent this email to another mailing list? From mike.ennen at gmail.com Sun Mar 14 23:49:52 2021 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 14 Mar 2021 16:49:52 -0700 Subject: Implementing a shader API In-Reply-To: References: Message-ID: I messed around with adding features to JavaFX's "JSLC" (Java Shader Language Compiler) which currently is only used at compile-time for JavaFX to convert "JSL" shaders to various platform dependent shader languages (GLSL, HLSL, etc.). In my opinion the ideal way to implement a public shader API would be to extend JSLC to be able to be used either at user application compile time, or more ideally, at application run-time to dynamically generate platform dependent shaders depending on what platform JavaFX is running on. Then a JavaFX application developer can write platform independent shaders in JSL. This would be quite a large undertaking and have a high burden of maintenance to keep it current with fast moving shader languages. I was able to convert JSLC grammar to antlr4 (from the previous antlr3 version) in this merged commit (pre-dates the move to Github): https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 I then took advantage of a new feature in antlr4 which allows for extracting embedded actions from the grammar definition file to a visitor class: https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 I then, in a test repository did some work in fleshing out what it would take to implement more features for JSLC which you can find (as messy commits) here: https://github.com/brcolow/jslc That's just my two cents on how a public shader API should best be added to JavaFX, by building on previous work that exists in the source code repository but is only used in a very limited and small way - but there is much potential there and I believe the original author of JSL's intent was to have it be a public API feature to allow JavaFX developers to write platform independent shaders in JSL. On Sun, Mar 14, 2021 at 3:32 PM superminerJG wrote: > Hi everyone. > > This problem might have been discussed numerous times, and has been held > off for quite a while. > > Although we are starting to see lighting improvements added to JavaFX, I > feel that it's necessary for JavaFX to have some kind of custom shader > pipeline. However, nobody has gotten around to doing it, so I thought that > I could lend a hand. Before I get into things, I would like to know how and > what I can contribute. The questions are at the bottom of the email. > > Thanks! > - jgcodes > > Questions: > > - Can high school students sign the OCA? (I saw the job title field on > the form and wasn't so sure I was legally allowed to sign it) > - When I implement the shader API, should it use some kind of GLSL > mapping, or should I try to extend JSL to work in 3D? > - Should I have sent this email to another mailing list? > -- Michael Ennen From nlisker at gmail.com Mon Mar 15 08:51:02 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 15 Mar 2021 10:51:02 +0200 Subject: Implementing a shader API In-Reply-To: References: Message-ID: I've thought about this too for a bit. My question would be how to tell the CPU what data to pass to the shader. Take OpenGL for example: writing an API to pass a shader and compiling it in runtime is not hard, but you need the CPU side to feed the shader its parameters. You would need an API for arbitrary data that the shader has been preconfigured to handle. That's quite an undertaking. And what level of flexibility is this going to give? The shader might require data that the public Java API does not expose, so you are limited in that regard too. When I wrote the enhancements for the shaders, I also had to change the Java side, which you won't be able to do. On the D3D side, the shaders are precompiled, so it's a slightly different story. - Can high school students sign the OCA? (I saw the job title field > on the form and wasn't so sure I was legally allowed to sign it) Maybe ask on adoption-discuss at openjdk.java.net. On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen wrote: > I messed around with adding features to JavaFX's "JSLC" (Java Shader > Language Compiler) which currently is only used > at compile-time for JavaFX to convert "JSL" shaders to various platform > dependent shader languages (GLSL, HLSL, etc.). > > In my opinion the ideal way to implement a public shader API would be to > extend JSLC to be able to be used either > at user application compile time, or more ideally, at application run-time > to dynamically generate platform dependent shaders > depending on what platform JavaFX is running on. Then a JavaFX application > developer can write platform independent > shaders in JSL. This would be quite a large undertaking and have a high > burden of maintenance to keep it current with > fast moving shader languages. > > I was able to convert JSLC grammar to antlr4 (from the previous antlr3 > version) in this merged commit (pre-dates the move > to Github): > > > https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > I then took advantage of a new feature in antlr4 which allows for > extracting embedded actions from the grammar definition file to a visitor > class: > > > https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > I then, in a test repository did some work in fleshing out what it would > take to implement more features for JSLC which you can find (as messy > commits) here: > > https://github.com/brcolow/jslc > > That's just my two cents on how a public shader API should best be added to > JavaFX, by building on previous work that exists in the source code > repository but is only > used in a very limited and small way - but there is much potential there > and I believe the original author of JSL's intent was to have it be a > public API feature to allow > JavaFX developers to write platform independent shaders in JSL. > > > On Sun, Mar 14, 2021 at 3:32 PM superminerJG > wrote: > > > Hi everyone. > > > > This problem might have been discussed numerous times, and has been held > > off for quite a while. > > > > Although we are starting to see lighting improvements added to JavaFX, I > > feel that it's necessary for JavaFX to have some kind of custom shader > > pipeline. However, nobody has gotten around to doing it, so I thought > that > > I could lend a hand. Before I get into things, I would like to know how > and > > what I can contribute. The questions are at the bottom of the email. > > > > Thanks! > > - jgcodes > > > > Questions: > > > > - Can high school students sign the OCA? (I saw the job title field on > > the form and wasn't so sure I was legally allowed to sign it) > > - When I implement the shader API, should it use some kind of GLSL > > mapping, or should I try to extend JSL to work in 3D? > > - Should I have sent this email to another mailing list? > > > > > -- > Michael Ennen > From rlichten at openjdk.java.net Mon Mar 15 09:14:10 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 15 Mar 2021 09:14:10 GMT Subject: RFR: 8261840: Submenus close to screen borders are no longer repositioned In-Reply-To: References: <6dt7TsWGpxSrHgL2uQMidFL-x7wYVW1NmhdwUT7OxoE=.408420e2-d69b-4b78-baba-467ae986a02d@github.com> Message-ID: On Fri, 12 Mar 2021 13:59:07 GMT, Kevin Rushforth wrote: >> Marked as reviewed by aghaisas (Reviewer). > > This fixes the bug in question, although I see a slight regression in behavior on Windows with 125% pixel scaling (it doesn't reproduce with any other scaling value that I tried). With the original test case for [JDK-8228363](https://bugs.openjdk.java.net/browse/JDK-8228363), and `TOP` as the value of `side`, the initial menu is positioned slightly lower (by a few pixels) than it should be. See the attached image. It is correct the second and subsequent times the context menu is opened. > > Given that this new bug only happens with 125% scaling, it seems likely that it is a preexisting bug, and this fix merely exposes it. Can you take a look at this? If it is preexisting, then we should file a follow-on bug for this. > > ![ContextMenu-125](https://user-images.githubusercontent.com/34689748/110947924-9991ce00-82f5-11eb-82d2-6959ef24293f.png) Yes I can try to look into this. On 3/12/21 2:59 PM, Kevin Rushforth wrote: > > This fixes the bug in question, although I see a slight regression in > behavior on Windows with 125% pixel scaling (it doesn't reproduce with > any other scaling value that I tried). With the original test case for > JDK-8228363 , and > |TOP| as the value of |side|, the initial menu is positioned slightly > lower (by a few pixels) than it should be. See the attached image. It > is correct the second and subsequent times the context menu is opened. > > Given that this new bug only happens with 125% scaling, it seems > likely that it is a preexisting bug, and this fix merely exposes it. > Can you take a look at this? If it is preexisting, then we should file > a follow-on bug for this. > > ContextMenu-125 > > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , or > unsubscribe > . > ------------- PR: https://git.openjdk.java.net/jfx/pull/410 From primoz.kokol at gmail.com Mon Mar 15 12:38:16 2021 From: primoz.kokol at gmail.com (=?UTF-8?Q?Primo=C5=BE_Kokol?=) Date: Mon, 15 Mar 2021 13:38:16 +0100 Subject: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> Message-ID: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00000025dabfaf00() Unknown Non-user code 00000025dabfafc0() Unknown Non-user code 00000164ca445b4b() Unknown Non-user code cccccccccccccccc() Unknown Non-user code 00000164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph wrote: > I?m currently looking into why the native debug build is crashing. This > same assert fails while running FileReaderTest using the native debug > build. For the time being, you can try building by removing this particular > assert statement for debugging. > > ? Arun Joseph > > > On 12-Mar-2021, at 11:47 PM, Primo? Kokol > wrote: > > > > Hi Kevin, > > > > Unfortunately I don't have a test case. We are using various WebViews in > > our production application hence we don't know where/why exactly the > > application freezes. > > > > We were hoping that we will be able to identify it using the native debug > > build (& attached debugged) but it is now unfortunately crashing with the > > above error. > > > > Side note: > > Should I contact Arun directly or is he seeing these messages? > > > > -- PrimosK > > > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth < > kevin.rushforth at oracle.com> > > wrote: > > > >> Arun should be able to help you with the crash you are seeing in debug > >> mode. > >> > >> Regarding the hang, do you have a test case that will reproduce it? A > >> few different developers have reported similar hangs. We ended up > >> closing a recently-filed bug, JDK-8260238 [1], because were (and still > >> are) unable to reproduce the hang. > >> > >> -- Kevin > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 > >> > >> > >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: > >>> Hi everyone, > >>> > >>> I would need some help related to OpenJFX build. > >>> > >>> I was able to successfully prepare a build following this procedure > (from > >>> pull/417 request): > >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 > >>> > >>> We wanted to use it in our existing application (Java 11.0.10) to debug > >> an > >>> issue where the application would hang/freeze for no obvious reason > >> because > >>> of WebKit. > >>> > >>> In order to use this build we've manually overridden javafx-*.jar files > >> in > >>> our application with the ones from the above build. > >>> We've also placed all produced DLL files in our application's "bin" > >> folder > >>> so they are properly picked up (I've verified and I can confirm that > >>> jfxwebkit.dll produced by our debug build is loaded). > >>> > >>> After using this native debug build, the application will crash instead > >>> with: > >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: > >> Fatal > >>> program exit requested. > >>> > >>> It looks like it happens when JS code calls Java method. > >>> > >>> There is the call stack at the time when exception happens: > >>> > >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. > >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, > >> const > >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. > >>> > >>> > >> > jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM > >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 > C++ > >>> Symbols loaded. > >>> > >>> > >> > jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM > >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. > >>> jfxwebkit.dll!JSC::jsDynamicCast >>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) > Line > >>> 182 C++ Symbols loaded. > >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, > >> const > >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode > >>> nameAdditionMode) Line 49 C++ Symbols loaded. > >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const > >>> WTF::String & ident) Line 58 C++ Symbols loaded. > >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, > >>> const WTF::String & name) Line 231 C++ Symbols loaded. > >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * > >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) > >>> Line 212 C++ Symbols loaded. > >>> > >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject > >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols > >> loaded. > >>> > >>> > >> > jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject > >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName > propertyName) > >>> Line 124 C++ Symbols loaded. > >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * > >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols > loaded. > >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * > >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols > >> loaded. > >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, > >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ > >>> Symbols loaded. > >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction > * > >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, > >>> JSC::JSValue baseValue, const JSC::Identifier & ident, > >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. > >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, > >> const > >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. > >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. > >>> 000000c7ef8fae90() Unknown Non-user code > >>> 000000c7ef8faf50() Unknown Non-user code > >>> 0000028d52eeedbb() Unknown Non-user code > >>> cccccccccccccccc() Unknown Non-user code > >>> 0000028d52eeedb6() Unknown Non-user code > >>> > >>> ... and partial output from the output console: > >>> > >>> .... > >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, > >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, > (I)solates > >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as > >> fi(x)ed, > >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to > >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, > >> (t)transformed > >>> ancestor > >>> Dirty (z)-lists, Dirty (n)ormal flow lists > >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or > >>> hierarchy traversal on descendants, (r)equirements traversal on all > >>> descendants, requirements traversal on all (s)ubsequent layers, > >> (h)ierarchy > >>> traversal on all descendants, update of paint (o)rder children > >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids > geometry, > >>> (c)onfig, layer conne(x)ion, (s)crolling tree > >>> Scrolling scope: box contents > >>> > >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 > >>> height=650 RenderView 0x28d4d4d1cd0 > >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) > width= > >> no > >>> compositing work to do > >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks > >>> > >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize > >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 > >> header > >>> height 0 footer height 0 fixed behavior 0 > >>> layoutViewport: (0,0) width=460 height=650 > >>> visualViewport: (0,0) width=460 height=650 (is override 0) > >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) > >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time > >> 24.89s > >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV > >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV > >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' > >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV > >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV > >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' > >>> EventDispatcher::dispatchEvent transitioncancel on node DIV > >>> EventDispatcher::dispatchEvent transitioncancel on node DIV > >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) > >>> > >> > C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) > >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl > >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: > >> Fatal > >>> program exit requested. > >>> > >>> Note that this crash isn't happening with official JavaFX 15, 16, and > >>> 17-ea+2 builds (that are at the time of writing this available on the > >>> maven), but unfortunately we can't use these for debugging purposes. > >>> > >>> Does that indicate any issues with the native debug build or is this > some > >>> regression that was introduced in the current `master` branch recently > >>> (after 17-ea+2)? > >>> > >>> Thanks for any helpful hints/advice in advance! > >>> > >>> Best regards, > >>> PrimosK > >> > >> > > From arapte at openjdk.java.net Mon Mar 15 19:02:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Mar 2021 19:02:10 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 15:32:10 GMT, Florian Kirmaier wrote: >> I think others can review this. I do have a couple questions: >> 1. In general, I don't like the idea of just making everything a weak reference, since it often masks a design issue. Two exceptions are for caches and for back references to a "parent" or controlling object that has a strong reference to "this" object (most of our weak listeners fall into this latter pattern). It sounds like latter case also applies here. Can you confirm that? >> 2. Have you verified that all the places that use the fields that are now WeakReferences are prepared to deal with `get()` returning a null object? > > About whether we should use WeakReference here or not. > > It definitely falls into the exception for referring to the Parrent of a Node. (Or to the Parent in a more abstract sense, I think it can also be the parent of the parent, or even from another SceneGraph.) > > I don't know the CSS code very well, so I currently don't have the knowledge how to change it. > But if we would change this variable, whenever the node is removed from the SceneGraph, my concern would be that it would have an unfavorable complexity. Currently (I hope) the complexity of removing a Node from the SceneGraph is O(1). If we would remove the stylehelper from the node, then the complexity would be O(). > > The current change assumes that we don't process the CSS, when a node is removed from the SG. This is why it isn't checked for null. I would argue, if this causes an Error, then it just reveals another issue, which would be preferable over a more complicated fix, and also changing the complexity of removing nodes from the SG. Below is a fix that I tried, It fixes the issue. The system test passed with this change. I was suggesting a solution like this where we can know exactly when to `null` the reference. The change is not extensively tested though. (For example, test what happens if we remove a node and add it back, OR remove a node and add it to a different scenegraph) However, in this case using `WeakReference` approach seems harmless. Using `WeakReference` for Listeners is not clean and may cause issues, but a `WeakReference` to Node should not cause any harm. I would recommend earlier way to explicitly release references/resources when it is possible. That way we get to have the control instead of gc. diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java index fd02c0c1ad..471d0071b5 100644 --- a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java +++ b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java @@ -36,6 +36,7 @@ import java.util.Set; import javafx.beans.property.ObjectProperty; import javafx.beans.property.SimpleObjectProperty; +import javafx.beans.value.ChangeListener; import javafx.beans.value.WritableValue; import com.sun.javafx.css.CascadingStyle; import javafx.css.CssMetaData; @@ -82,6 +83,14 @@ final class CssStyleHelper { this.triggerStates = new PseudoClassState(); } + ChangeListener sceneChangeListener; + + static void dispose(CssStyleHelper styleHelper, Node node) { + styleHelper.resetToInitialValues(node); + styleHelper.firstStyleableAncestor = null; + node.sceneProperty().removeListener(styleHelper.sceneChangeListener); + } + /** * Creates a new StyleHelper. */ @@ -158,7 +167,7 @@ final class CssStyleHelper { // If this node had a style helper, then reset properties to their initial value // since the node won't have a style helper after this call if (node.styleHelper != null) { - node.styleHelper.resetToInitialValues(node); + dispose(node.styleHelper, node); } // @@ -181,8 +190,14 @@ final class CssStyleHelper { // If this node had a style helper, then reset properties to their initial value // since the style map might now be different if (node.styleHelper != null) { - node.styleHelper.resetToInitialValues(node); + dispose(node.styleHelper, node); } + helper.sceneChangeListener = (ov, oldScene, newScene) -> { + if (newScene == null) { + helper.firstStyleableAncestor = null; + } + }; + node.sceneProperty().addListener(helper.sceneChangeListener); return helper; } ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From arapte at openjdk.java.net Mon Mar 15 19:20:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Mar 2021 19:20:09 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v2] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 15:11:42 GMT, Florian Kirmaier wrote: >> tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 106: >> >>> 104: }); >>> 105: } >>> 106: } >> >> In order to make this test similar to existing system tests, I made some relevant changes. Modified test is added below. >> The modified test fails with this fix, but I expected it to pass. Can you please check this. >> >> Changes are >> 1. `Thread.sleep()` is removed. >> 2. `root` and `toBeRemoved` button are now class members. >> 3. Scenegraph is constructed and shown in `TestApp.start()` method. >> >> >> public class StyleMemoryLeakTest { >> >> static CountDownLatch startupLatch; >> static Stage stage; >> static Button toBeRemoved; >> static Group root; >> >> public static class TestApp extends Application { >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> stage = primaryStage; >> toBeRemoved = new Button(); >> root = new Group(); >> root.getChildren().add(toBeRemoved); >> stage.setScene(new Scene(root)); >> stage.setOnShown(l -> { >> Platform.runLater(() -> startupLatch.countDown()); >> }); >> stage.show(); >> } >> } >> >> @BeforeClass >> public static void initFX() throws Exception { >> startupLatch = new CountDownLatch(1); >> new Thread(() -> Application.launch(StyleMemoryLeakTest.TestApp.class, (String[])null)).start(); >> assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); >> } >> >> @Test >> public void testRootNodeMemoryLeak() throws Exception { >> Util.runAndWait(() -> { >> root.getChildren().clear(); >> stage.hide(); >> }); >> JMemoryBuddy.memoryTest((checker) -> { >> checker.assertCollectable(stage); >> checker.setAsReferenced(toBeRemoved); >> stage = null; >> }); >> } >> >> @AfterClass >> public static void teardownOnce() { >> Platform.runLater(() -> { >> Platform.exit(); >> }); >> } >> } > > I've added your verison of the unit-test. You forgot `root = null;` which was why the test failed. > > If I would rewrite the test, I would put everything into the TestMethod. Because this way it's not necessary to set all the class-variables to null. It also wouldn't reuse the Stage of the Application. The scope of the test would be much smaller, because the actual test and the initialization of JavaFX would be separated. > > Should I change it that way? I am fine with that too. In that case my only suggestion would be, use method `Stage.setOnShown()` like in the current version to make sure that `Stage` is shown and not to rely on `Thread.sleep()`. > It also wouldn't reuse the Stage of the Application. In that case, test will not require the `TestApp` class. You can use `Platform.startup()` method to start JavaFX runtime and also **may** need a call to `Platform.setImplicitExit?(false)` to make sure JavaFX runtime does not exit when Stage is hidden. This way we can add multiple tests that create and hide stage in a same test file. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From la.tinca at gmail.com Mon Mar 15 19:25:15 2021 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Mon, 15 Mar 2021 20:25:15 +0100 Subject: user mailing list Message-ID: Hi, I asked something on Stackoverflow I do not think I can formulate better, but it was closed right away. Is there a mailing list for user questions? Thx, Zsolt From almatvee at openjdk.java.net Mon Mar 15 21:01:11 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 15 Mar 2021 21:01:11 GMT Subject: Integrated: 8257895: Allow building of JavaFX media libs for Apple Silicon In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 03:58:17 GMT, Alexander Matveev wrote: > - Added support to compile media on arm. > - libffi is based on 3.3. This pull request has now been integrated. Changeset: 8adbc673 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/8adbc673 Stats: 2860 lines in 19 files changed: 2823 ins; 5 del; 32 mod 8257895: Allow building of JavaFX media libs for Apple Silicon Co-authored-by: Johan Vos Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/412 From github.com+12087024+beldenfox at openjdk.java.net Mon Mar 15 21:44:26 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Mon, 15 Mar 2021 21:44:26 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v2] In-Reply-To: References: Message-ID: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: The code now queries both the shifted and unshifted characters for a key favoring digits and letters over everything else. This ensures we catch the digits on the French layout without interfering with Dvorak. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/425/files - new: https://git.openjdk.java.net/jfx/pull/425/files/b2254109..6238c49c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=00-01 Stats: 51 lines in 1 file changed: 24 ins; 17 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/425.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/425/head:pull/425 PR: https://git.openjdk.java.net/jfx/pull/425 From github.com+12087024+beldenfox at openjdk.java.net Mon Mar 15 21:44:26 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Mon, 15 Mar 2021 21:44:26 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> Message-ID: On Fri, 12 Mar 2021 21:28:38 GMT, Tom Schindl wrote: >> @kevinrushforth I have a manual app that can perform a simple test to verify that when a robot sends KeyCode.A through KeyCode.Z the system receives the characters 'a' to 'z'. On the Mac this sanity test was failing on German and French keyboards prior to these changes. The test is part of a key logger app I created. >> >> I chose this bug because it has a straight-forward test attached and some recent comment activity. >> >> @tomsontom Could you point me to the relevant code in Swing? I'm looking at the code but am getting lost in the layers. > > https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 On the French keyboard the digits are shifted but I assumed we would still want those keys to map to KeyCode.0-9 as they do on Windows. My solution was to hard-code those key positions to be digits but this interferes with Dvorak layouts. I'm tweaking the implementation to fix this. The new approach will be to query both the shifted and unshifted characters on a key and favor digits and letters over everything else (and something over nothing). (I've been writing Mac code to enumerate all the OS keyboard layouts and generate lists showing which Java key codes will change from the historic implementation. It also does some sanity checking.) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From jackyguo579 at gmail.com Tue Mar 16 02:12:54 2021 From: jackyguo579 at gmail.com (Jacky Guo) Date: Mon, 15 Mar 2021 22:12:54 -0400 Subject: Implementing a shader API In-Reply-To: References: Message-ID: Regarding uniform parameters (i.e. variables set from Java and called on the shader): Since OpenGL's data passing uses locations, you could simply store a map of uniform parameters (or whatever their JSL equivalent is) to their locations, and call the required methods and perform the necessary type-safety checks. For D3D, you would still use the parameter map, but only for type safety. This is assuming I understand how the APIs work and I am not overlooking something crucial. On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker wrote: > I've thought about this too for a bit. My question would be how to tell > the CPU what data to pass to the shader. Take OpenGL for example: writing > an API to pass a shader and compiling it in runtime is not hard, but you > need the CPU side to feed the shader its parameters. You would need an API > for arbitrary data that the shader has been preconfigured to handle. That's > quite an undertaking. > And what level of flexibility is this going to give? The shader might > require data that the public Java API does not expose, so you are limited > in that regard too. When I wrote the enhancements for the shaders, I also > had to change the Java side, which you won't be able to do. > On the D3D side, the shaders are precompiled, so it's a slightly different > story. > > - Can high school students sign the OCA? (I saw the job title field >> on the form and wasn't so sure I was legally allowed to sign it) > > > Maybe ask on adoption-discuss at openjdk.java.net. > > On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen > wrote: > >> I messed around with adding features to JavaFX's "JSLC" (Java Shader >> Language Compiler) which currently is only used >> at compile-time for JavaFX to convert "JSL" shaders to various platform >> dependent shader languages (GLSL, HLSL, etc.). >> >> In my opinion the ideal way to implement a public shader API would be to >> extend JSLC to be able to be used either >> at user application compile time, or more ideally, at application run-time >> to dynamically generate platform dependent shaders >> depending on what platform JavaFX is running on. Then a JavaFX application >> developer can write platform independent >> shaders in JSL. This would be quite a large undertaking and have a high >> burden of maintenance to keep it current with >> fast moving shader languages. >> >> I was able to convert JSLC grammar to antlr4 (from the previous antlr3 >> version) in this merged commit (pre-dates the move >> to Github): >> >> >> https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 >> >> I then took advantage of a new feature in antlr4 which allows for >> extracting embedded actions from the grammar definition file to a visitor >> class: >> >> >> https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 >> >> I then, in a test repository did some work in fleshing out what it would >> take to implement more features for JSLC which you can find (as messy >> commits) here: >> >> https://github.com/brcolow/jslc >> >> That's just my two cents on how a public shader API should best be added >> to >> JavaFX, by building on previous work that exists in the source code >> repository but is only >> used in a very limited and small way - but there is much potential there >> and I believe the original author of JSL's intent was to have it be a >> public API feature to allow >> JavaFX developers to write platform independent shaders in JSL. >> >> >> On Sun, Mar 14, 2021 at 3:32 PM superminerJG >> wrote: >> >> > Hi everyone. >> > >> > This problem might have been discussed numerous times, and has been held >> > off for quite a while. >> > >> > Although we are starting to see lighting improvements added to JavaFX, I >> > feel that it's necessary for JavaFX to have some kind of custom shader >> > pipeline. However, nobody has gotten around to doing it, so I thought >> that >> > I could lend a hand. Before I get into things, I would like to know how >> and >> > what I can contribute. The questions are at the bottom of the email. >> > >> > Thanks! >> > - jgcodes >> > >> > Questions: >> > >> > - Can high school students sign the OCA? (I saw the job title field >> on >> > the form and wasn't so sure I was legally allowed to sign it) >> > - When I implement the shader API, should it use some kind of GLSL >> > mapping, or should I try to extend JSL to work in 3D? >> > - Should I have sent this email to another mailing list? >> > >> >> >> -- >> Michael Ennen >> > From tschindl at openjdk.java.net Tue Mar 16 11:16:13 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Tue, 16 Mar 2021 11:16:13 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> Message-ID: <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> On Mon, 15 Mar 2021 21:40:55 GMT, Martin Fox wrote: >> https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 > > On the French keyboard the digits are shifted but I assumed we would still want those keys to map to KeyCode.0-9 as they do on Windows. My solution was to hard-code those key positions to be digits but this interferes with Dvorak layouts. I'm tweaking the implementation to fix this. The new approach will be to query both the shifted and unshifted characters on a key and favor digits and letters over everything else (and something over nothing). > > (I've been writing Mac code to enumerate all the OS keyboard layouts and generate lists showing which Java key codes will change from the historic implementation. It also does some sanity checking.) Maybe this is a very dumb idea but why are we not using the char to map back to the keycode? At least for everything in the ASCII-Range this would be ok not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) first. So once we checked and the text is of length 1 we could do the mapping from the char. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From dubaut at gmail.com Tue Mar 16 11:50:34 2021 From: dubaut at gmail.com (Hannes H.) Date: Tue, 16 Mar 2021 12:50:34 +0100 Subject: ToggleGroup does not manage its toggles Message-ID: Hello, while discussing a question on StackOverflow, I learned that a ToggleGroup actually does not manage its toggles, but the toggles are responsible to ensure that only one of them is selected at a time. This topic came up because I want to apply exactly the same behavior of RadioMenuItems in a ToggleGroup to a group of TitledPanes, which cannot be placed in the same parent and therefore cannot reside in an Accordion (as far as I understand it.) To solve my problem I implemented an Adapter that basically maps the corresponding properties of the TitledPane to the one required by the Toggle interface - and this did not work as expected. Now, being a curious person, I would like to understand, why it is that the ToggleGroup actually does not handle manage the selected state of its toggles. Does anyone know the background story behind this or is it something very obvious I just don't see yet? Have a great day, Hannes [1] https://stackoverflow.com/questions/66644845/toggle-adapter-for-titledpane/66647505 From arun.aj.joseph at oracle.com Tue Mar 16 12:30:22 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Tue, 16 Mar 2021 12:30:22 +0000 Subject: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> Message-ID: <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. ? Arun Joseph On 15-Mar-2021, at 6:08 PM, Primo? Kokol > wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00000025dabfaf00() Unknown Non-user code 00000025dabfafc0() Unknown Non-user code 00000164ca445b4b() Unknown Non-user code cccccccccccccccc() Unknown Non-user code 00000164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph > wrote: I?m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. ? Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primo? Kokol > wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> loaded. >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >>> Symbols loaded. >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >>> 000000c7ef8fae90() Unknown Non-user code >>> 000000c7ef8faf50() Unknown Non-user code >>> 0000028d52eeedbb() Unknown Non-user code >>> cccccccccccccccc() Unknown Non-user code >>> 0000028d52eeedb6() Unknown Non-user code >>> >>> ... and partial output from the output console: >>> >>> .... >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >> fi(x)ed, >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >> (t)transformed >>> ancestor >>> Dirty (z)-lists, Dirty (n)ormal flow lists >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or >>> hierarchy traversal on descendants, (r)equirements traversal on all >>> descendants, requirements traversal on all (s)ubsequent layers, >> (h)ierarchy >>> traversal on all descendants, update of paint (o)rder children >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, >>> (c)onfig, layer conne(x)ion, (s)crolling tree >>> Scrolling scope: box contents >>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 >>> height=650 RenderView 0x28d4d4d1cd0 >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= >> no >>> compositing work to do >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >> header >>> height 0 footer height 0 fixed behavior 0 >>> layoutViewport: (0,0) width=460 height=650 >>> visualViewport: (0,0) width=460 height=650 (is override 0) >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >> 24.89s >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) >>> >> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >>> 17-ea+2 builds (that are at the time of writing this available on the >>> maven), but unfortunately we can't use these for debugging purposes. >>> >>> Does that indicate any issues with the native debug build or is this some >>> regression that was introduced in the current `master` branch recently >>> (after 17-ea+2)? >>> >>> Thanks for any helpful hints/advice in advance! >>> >>> Best regards, >>> PrimosK >> >> From jvos at openjdk.java.net Tue Mar 16 14:28:22 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 16 Mar 2021 14:28:22 GMT Subject: RFR: 8092439: [Monocle] Refactor monocle SPI to allow support for multiple screens Message-ID: Fix for JDK-8092439 and JDK-8092064 Monocle currently hard-codes a single Screen, and the `staticScreen_getScreens()` method will never return more than 1 Screen. This PR introduces the possibility to deal with multiple screens, which is not uncommon on embedded systems. By default, the `staticScreen_getScreens()` method will still return a single screen, but the sub-platforms can now return multiple screens. The EGL subplatform will now query the low-level drivers, and if they detect multiple displays, multiple `Screen` instances will be configured. The low-level native implementation for getting the number of physical screens and there characteristics is deferred to the real low-level libraries (for example, an X11 based approach can do it in a different way then a DRM based approach). ------------- Commit messages: - Allow Monocle implementations to provide multiple screens. Changes: https://git.openjdk.java.net/jfx/pull/426/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8092439 Stats: 298 lines in 7 files changed: 275 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/426.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/426/head:pull/426 PR: https://git.openjdk.java.net/jfx/pull/426 From kcr at openjdk.java.net Tue Mar 16 16:35:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Mar 2021 16:35:19 GMT Subject: RFR: 8255713: JavaFX build should discover Visual Studio compiler on system Message-ID: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> We currently hard-code the default version of Visual Studio in both `win.gradle` and `.github/workflows/submit.yml`. This hard-coding of the specific version of MSVC is fragile, particularly for GitHub action builds. The last time Microsoft changed the environment, our Windows builds started failing (because we hard-coded it). I temporarily bumped it to the then-current version as a fix for [JDK-8256686](https://bugs.openjdk.java.net/browse/JDK-8256686), and filed this bug -- [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) -- as a followup. It's failing again because of another update to the GitHub actions environment, so it's time to fix it to discover the latest version rather than hardcode it. NOTE to reviewers: This will need to be tested with local and CI builds as well as GitHub actions, since there are changes in the `win.gradle` script (and associated `genVSproperties.bat` script). ------------- Commit messages: - 8255713: JavaFX build should discover Visual Studio compiler on system Changes: https://git.openjdk.java.net/jfx/pull/427/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255713 Stats: 25 lines in 3 files changed: 17 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/427.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/427/head:pull/427 PR: https://git.openjdk.java.net/jfx/pull/427 From jvos at openjdk.java.net Tue Mar 16 19:34:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 16 Mar 2021 19:34:06 GMT Subject: RFR: 8255713: JavaFX build should discover Visual Studio compiler on system In-Reply-To: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> References: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> Message-ID: On Tue, 16 Mar 2021 16:30:51 GMT, Kevin Rushforth wrote: > We currently hard-code the default version of Visual Studio in both `win.gradle` and `.github/workflows/submit.yml`. This hard-coding of the specific version of MSVC is fragile, particularly for GitHub action builds. The last time Microsoft changed the environment, our Windows builds started failing (because we hard-coded it). I temporarily bumped it to the then-current version as a fix for [JDK-8256686](https://bugs.openjdk.java.net/browse/JDK-8256686), and filed this bug -- [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) -- as a followup. It's failing again because of another update to the GitHub actions environment, so it's time to fix it to discover the latest version rather than hardcode it. > > NOTE to reviewers: This will need to be tested with local and CI builds as well as GitHub actions, since there are changes in the `win.gradle` script (and associated `genVSproperties.bat` script). CI build passes ------------- PR: https://git.openjdk.java.net/jfx/pull/427 From github.com+12087024+beldenfox at openjdk.java.net Tue Mar 16 19:52:13 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Tue, 16 Mar 2021 19:52:13 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> Message-ID: <4DMGohjcVKz0vg0kZq0Qs7e5X1mQfkahhQGd1WerBS0=.b7e4fb1a-8984-4ed2-bde9-5a4070501086@github.com> On Tue, 16 Mar 2021 11:13:39 GMT, Tom Schindl wrote: >> On the French keyboard the digits are shifted but I assumed we would still want those keys to map to KeyCode.0-9 as they do on Windows. My solution was to hard-code those key positions to be digits but this interferes with Dvorak layouts. I'm tweaking the implementation to fix this. The new approach will be to query both the shifted and unshifted characters on a key and favor digits and letters over everything else (and something over nothing). >> >> (I've been writing Mac code to enumerate all the OS keyboard layouts and generate lists showing which Java key codes will change from the historic implementation. It also does some sanity checking.) > > Maybe this is a very dumb idea but why are we not using the char to map back to the keycode? At least for everything in the ASCII-Range this would be ok not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) first. So once we checked and the text is of length 1 we could do the mapping from the char. The Function/arrow/number pad keys are handled using a hard-coded table since they don?t vary based on keyboard layout. Beyond that you?re asking exactly the right question. JavaFX KeyCodes seem to be modeled on similar systems present in Windows and X11. On these platforms the system assigns a key code to each key which remains stable regardless of the modifier state. The system tries to ensure that codes for A-Z and 0-9 are assigned to keys even on keyboards that don?t generate Latin characters. My implementation is conservative in that it?s trying to emulate the behavior of Windows and X11 and associate each key with a stable code including A-Z and 0-9. On the Mac that has no real utility when it comes to accelerator matching, we could use the character information in the event to generate the JavaFX key code and still match user?s expectations. But that would break other JavaFX assumptions, like that the key code is stable. Take the =/+ key on the US keyboard as an example. If Cmd is not held down it will generate = or + depending on the shift state and so vary between KeyCode.EQUALS and KeyCode.PLUS. And key events for non-Latin characters would have an UNDEFINED KeyCode until Cmd was held down and we got a useable ASCII character. I have no idea if these deviations from the original design would be an issue. At this point I?m pretty sure that any problems would lie outside accelerator processing e.g. with the Robot. P.S. What I would not do is what Swing is trying, namely to emulate Windows (stable codes, A-Z present, etc.) using just the NSEvent character information and heuristics. That?s generating all sorts of oddness under the hood. Better to generate UNDEFINED KeyCodes than bad guesses. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From arapte at openjdk.java.net Wed Mar 17 16:55:48 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 17 Mar 2021 16:55:48 GMT Subject: RFR: 8255713: JavaFX build should discover Visual Studio compiler on system In-Reply-To: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> References: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> Message-ID: <0TDNVG58GlsVRc3xC9eCLLyYB-CjYGGVQowsESBixjQ=.99146bdf-a77f-4a88-830e-70494e4e4c28@github.com> On Tue, 16 Mar 2021 16:30:51 GMT, Kevin Rushforth wrote: > We currently hard-code the default version of Visual Studio in both `win.gradle` and `.github/workflows/submit.yml`. This hard-coding of the specific version of MSVC is fragile, particularly for GitHub action builds. The last time Microsoft changed the environment, our Windows builds started failing (because we hard-coded it). I temporarily bumped it to the then-current version as a fix for [JDK-8256686](https://bugs.openjdk.java.net/browse/JDK-8256686), and filed this bug -- [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) -- as a followup. It's failing again because of another update to the GitHub actions environment, so it's time to fix it to discover the latest version rather than hardcode it. > > NOTE to reviewers: This will need to be tested with local and CI builds as well as GitHub actions, since there are changes in the `win.gradle` script (and associated `genVSproperties.bat` script). lgtm, local build on my machine completes successfully and GitHub actions build also completed on this PR. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/427 From arapte at openjdk.java.net Wed Mar 17 17:40:02 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 17 Mar 2021 17:40:02 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport Message-ID: The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). Fix is to remove the listener when MenuItem is removed. Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. With fix, the count is always same as number of MenuItems in scenegraph. Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. Added a comment explaining this behavior in place of the TODO. ------------- Commit messages: - remove listener added to MenuItem from ControlAcceleratorSupport Changes: https://git.openjdk.java.net/jfx/pull/429/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8208088 Stats: 46 lines in 1 file changed: 34 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From kcr at openjdk.java.net Wed Mar 17 18:26:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:26:04 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Message-ID: This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. ## Evaluation The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. * Snapshot needs to allow for the platform image to be null if the device has been disposed. ## Notes to Reviewers I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. ------------- Commit messages: - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop - Ressource already freed from pool - Recreate if adapterCount is zero - Fix whitespace error - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Changes: https://git.openjdk.java.net/jfx/pull/430/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239589 Stats: 850 lines in 47 files changed: 728 ins; 36 del; 86 mod Patch: https://git.openjdk.java.net/jfx/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/430/head:pull/430 PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Wed Mar 17 18:26:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:26:04 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 18:17:48 GMT, Kevin Rushforth wrote: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. NOTE: the Windows GitHub actions build is failing due to [JDK-8259639](https://bugs.openjdk.java.net/browse/JDK-8259639). I'll merge that fix in from master once it is integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Wed Mar 17 18:28:53 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:28:53 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: <9wHn5ETuz3xCDDn8097ykOtE0g7jUon2d6FQi9eWwAc=.c384aa85-4026-4194-afc8-73e2cbaa20f7@github.com> References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> <22tfdEO1ILt4VorRR14lxyBICTzCMSuY6BkrPtu16ms=.d3afb490-c51d-4ef0-b50a-59c1a2565d77@github.com> <9wHn5ETuz3xCDDn8097ykOtE0g7jUon2d6FQi9eWwAc=.c384aa85-4026-4194-afc8-73e2cbaa20f7@github.com> Message-ID: On Tue, 16 Feb 2021 15:42:51 GMT, Kevin Rushforth wrote: >> This is a good starting point, but it will need additional work, possibly in the native D3D code as well as on the Java side, to fully cleanup and recreate all of the resources after the device is recreated. As discussed offline, I'll take a stab at this using your PR as a starting point. >> >> I ran some tests this afternoon. It does detect that the devide was removed, and the disposes and recreates the device, but then it has problem drawing anything with a texture; it throws an exception and there are rendering artifacts: >> >> KCR: create resource factor for screen 0 >> D3DContext::testCooperativeLevel >> D3DContext::testCooperativeLevel >> D3DContext::testCooperativeLevel >> D3DContext::testCooperativeLevel >> D3DContext::testCooperativeLevel >> KCR: D3DERR_DEVICEREMOVED >> KCR: dispose graphics pipeline >> KCR: instance is null: reinitialize D3DPipeline >> Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.sun.prism.GraphicsPipeline.is3DSupported()" because the return value of "com.sun.prism.GraphicsPipeline.getPipeline()" is null >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.isSupported(QuantumToolkit.java:1209) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupportedImpl(PlatformImpl.java:979) >> at javafx.graphics/com.sun.javafx.application.PlatformImpl.isSupported(PlatformImpl.java:646) >> at javafx.graphics/javafx.application.Platform.isSupported(Platform.java:262) >> at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.processOffer(PickResultChooser.java:182) >> at javafx.graphics/com.sun.javafx.scene.input.PickResultChooser.offer(PickResultChooser.java:143) >> at javafx.graphics/javafx.scene.Node.intersects(Node.java:5229) >> at javafx.graphics/javafx.scene.Node$1.intersects(Node.java:553) >> at javafx.graphics/com.sun.javafx.scene.NodeHelper.intersects(NodeHelper.java:258) >> at javafx.graphics/javafx.scene.layout.Region.doPickNodeLocal(Region.java:3227) >> ... >> at javafx.graphics/javafx.scene.Scene.pick(Scene.java:2031) >> at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3810) >> at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1851) >> at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2584) >> at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:409) >> at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:299) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:447) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:413) >> at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:446) >> at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:556) >> at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:942) >> at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) >> at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >> at java.base/java.lang.Thread.run(Thread.java:832) >> ... >> KCR: create resource factor for screen 0 >> D3DContext::testCooperativeLevel >> D3DContext::testCooperativeLevel >> KCR: dispose graphics pipeline >> ![HelloFontSize](https://user-images.githubusercontent.com/34689748/107589656-568bf000-6bbb-11eb-9c0d-bea50b190d4d.png) > > I created PR #403 using this as a starting point, so I am moving this PR back to draft (and it probably can be closed). I just created the final PR #430 to fix this bug. As a result, I'm closing this PR ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From kcr at openjdk.java.net Wed Mar 17 18:28:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:28:54 GMT Subject: Withdrawn: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 16:07:08 GMT, Oliver Schmidtmer wrote: > When connecting via Remote Desktop to a Windows 10 machine ans starting a JavaFX application, the D3D pipeline is used successfully. > After closing the the Remote Desktop session and reconnecting, the D3D requests fail with an D3DERR_DEVICEREMOVED HResult, and the application contents are not rendered anymore. > Reinitializing the whole pipeline fixes that. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From kcr at openjdk.java.net Wed Mar 17 18:30:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:30:49 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: <9BfuGSnqscPr30DUL4ePj0POUfoYI0cNsTfthJiAcDA=.d9b09121-3ba0-496d-9c50-b7eb22488a2f@github.com> On Wed, 17 Mar 2021 18:23:07 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > NOTE: the Windows GitHub actions build is failing due to [JDK-8259639](https://bugs.openjdk.java.net/browse/JDK-8259639). I'll merge that fix in from master once it is integrated. @Schmidor if you are able to review or test this, it would be appreciated. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Wed Mar 17 18:31:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 18:31:48 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 17:35:34 GMT, Ambarish Rapte wrote: > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Is there a unit test that can validate this fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From jvos at openjdk.java.net Wed Mar 17 19:16:49 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 17 Mar 2021 19:16:49 GMT Subject: RFR: 8255713: JavaFX build should discover Visual Studio compiler on system In-Reply-To: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> References: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> Message-ID: On Tue, 16 Mar 2021 16:30:51 GMT, Kevin Rushforth wrote: > We currently hard-code the default version of Visual Studio in both `win.gradle` and `.github/workflows/submit.yml`. This hard-coding of the specific version of MSVC is fragile, particularly for GitHub action builds. The last time Microsoft changed the environment, our Windows builds started failing (because we hard-coded it). I temporarily bumped it to the then-current version as a fix for [JDK-8256686](https://bugs.openjdk.java.net/browse/JDK-8256686), and filed this bug -- [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) -- as a followup. It's failing again because of another update to the GitHub actions environment, so it's time to fix it to discover the latest version rather than hardcode it. > > NOTE to reviewers: This will need to be tested with local and CI builds as well as GitHub actions, since there are changes in the `win.gradle` script (and associated `genVSproperties.bat` script). Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/427 From kcr at openjdk.java.net Wed Mar 17 20:33:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 20:33:46 GMT Subject: Integrated: 8255713: JavaFX build should discover Visual Studio compiler on system In-Reply-To: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> References: <5SiYfygDuit_Hq6rbMZ_-6Ka0wAZcgaU117V44c0_9I=.c62faf2b-f9ef-49a7-87e4-4b763bdb0bb6@github.com> Message-ID: On Tue, 16 Mar 2021 16:30:51 GMT, Kevin Rushforth wrote: > We currently hard-code the default version of Visual Studio in both `win.gradle` and `.github/workflows/submit.yml`. This hard-coding of the specific version of MSVC is fragile, particularly for GitHub action builds. The last time Microsoft changed the environment, our Windows builds started failing (because we hard-coded it). I temporarily bumped it to the then-current version as a fix for [JDK-8256686](https://bugs.openjdk.java.net/browse/JDK-8256686), and filed this bug -- [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) -- as a followup. It's failing again because of another update to the GitHub actions environment, so it's time to fix it to discover the latest version rather than hardcode it. > > NOTE to reviewers: This will need to be tested with local and CI builds as well as GitHub actions, since there are changes in the `win.gradle` script (and associated `genVSproperties.bat` script). This pull request has now been integrated. Changeset: 71a7d43c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/71a7d43c Stats: 25 lines in 3 files changed: 17 ins; 2 del; 6 mod 8255713: JavaFX build should discover Visual Studio compiler on system Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/427 From kcr at openjdk.java.net Wed Mar 17 20:47:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 20:47:09 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v2] In-Reply-To: References: Message-ID: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8239589-rdp-reconnect - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop - Ressource already freed from pool - Recreate if adapterCount is zero - Fix whitespace error - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/430/files - new: https://git.openjdk.java.net/jfx/pull/430/files/9989dc3f..0448f803 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=00-01 Stats: 25 lines in 3 files changed: 17 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/430/head:pull/430 PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Wed Mar 17 23:30:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Mar 2021 23:30:47 GMT Subject: RFR: 8092439: [Monocle] Refactor monocle SPI to allow support for multiple screens In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 14:24:19 GMT, Johan Vos wrote: > Fix for JDK-8092439 and JDK-8092064 > Monocle currently hard-codes a single Screen, and the `staticScreen_getScreens()` method will never return more than 1 Screen. > > This PR introduces the possibility to deal with multiple screens, which is not uncommon on embedded systems. By default, the `staticScreen_getScreens()` method will still return a single screen, but the sub-platforms can now return multiple screens. > > The EGL subplatform will now query the low-level drivers, and if they detect multiple displays, multiple `Screen` instances will be configured. > The low-level native implementation for getting the number of physical screens and there characteristics is deferred to the real low-level libraries (for example, an X11 based approach can do it in a different way then a DRM based approach). Looks good. I left one comment that you might want to look at (probably for a follow-up issue, since it doesn't seem to be causing problems). modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c line 92: > 90: > 91: JNIEXPORT jlong JNICALL Java_com_sun_glass_ui_monocle_EGLScreen_nGetHandle > 92: (JNIEnv *env, jclass clazz, jint idx) { Since the JNI parameters are unused, it may not matter, but since this is an instance method, the second argument is a `jobject` not a `jclass`. The same issue applies to the rest. I see that you just copied a preexisting issue, so you might or might not want to fix it, or maybe just file a follow-on cleanup issue if you like. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/426 From jackyguo579 at gmail.com Thu Mar 18 00:09:13 2021 From: jackyguo579 at gmail.com (Jacky Guo) Date: Wed, 17 Mar 2021 20:09:13 -0400 Subject: Fwd: Implementing a shader API In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Jacky Guo Date: Wed, Mar 17, 2021 at 8:08 PM Subject: Re: Implementing a shader API To: Johan Vos I've cobbled together a prototype API. This is of course non-functional, but I'd like feedback on it. I'm going to work backwards to figure out what I need to add. ShadedMaterial Shader On Tue, Mar 16, 2021 at 4:40 AM Johan Vos wrote: > > > On Sat, Mar 13, 2021 at 3:58 AM superminerJG > wrote: > >> Hi everyone. >> > [...] > >> Questions: >> >> - Can high school students sign the OCA? (I saw the job title field on >> the form and wasn't so sure I was legally allowed to sign it) >> > > If the answer to this was "NO", it would mean we're doing something > terribly wrong that we need to fix. I have no immediate knowledge on how to > do this, hence Nir's suggestion about asking on adoption-discuss would be > good. > > >> - When I implement the shader API, should it use some kind of GLSL >> mapping, or should I try to extend JSL to work in 3D? >> > > The latter sounds the least intrusive approach. > Michael and Nir have interesting comments in their replies. It's not a > simple thing. > > >> - Should I have sent this email to the openjfx-dev mailing list and not >> this one? >> > > At this moment, I think openjfx-discuss is the best mailing list. There > are a number of conceptual things that need to be sorted first, and it > would be good to keep the discussion alive on this list. Once there is > something tangible, e.g. a prototype, we can move the discussion to > openjfx-dev. > > Thanks for the ideas! > > - Johan > From jvos at openjdk.java.net Thu Mar 18 07:34:48 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 18 Mar 2021 07:34:48 GMT Subject: RFR: 8092439: [Monocle] Refactor monocle SPI to allow support for multiple screens In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 23:05:27 GMT, Kevin Rushforth wrote: >> Fix for JDK-8092439 and JDK-8092064 >> Monocle currently hard-codes a single Screen, and the `staticScreen_getScreens()` method will never return more than 1 Screen. >> >> This PR introduces the possibility to deal with multiple screens, which is not uncommon on embedded systems. By default, the `staticScreen_getScreens()` method will still return a single screen, but the sub-platforms can now return multiple screens. >> >> The EGL subplatform will now query the low-level drivers, and if they detect multiple displays, multiple `Screen` instances will be configured. >> The low-level native implementation for getting the number of physical screens and there characteristics is deferred to the real low-level libraries (for example, an X11 based approach can do it in a different way then a DRM based approach). > > modules/javafx.graphics/src/main/native-glass/monocle/egl/eglBridge.c line 92: > >> 90: >> 91: JNIEXPORT jlong JNICALL Java_com_sun_glass_ui_monocle_EGLScreen_nGetHandle >> 92: (JNIEnv *env, jclass clazz, jint idx) { > > Since the JNI parameters are unused, it may not matter, but since this is an instance method, the second argument is a `jobject` not a `jclass`. The same issue applies to the rest. I see that you just copied a preexisting issue, so you might or might not want to fix it, or maybe just file a follow-on cleanup issue if you like. I filed JDK-8263778 to track this. I will check the other methods as well as part of this issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/426 From jvos at openjdk.java.net Thu Mar 18 07:34:49 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 18 Mar 2021 07:34:49 GMT Subject: Integrated: 8092439: [Monocle] Refactor monocle SPI to allow support for multiple screens In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 14:24:19 GMT, Johan Vos wrote: > Fix for JDK-8092439 and JDK-8092064 > Monocle currently hard-codes a single Screen, and the `staticScreen_getScreens()` method will never return more than 1 Screen. > > This PR introduces the possibility to deal with multiple screens, which is not uncommon on embedded systems. By default, the `staticScreen_getScreens()` method will still return a single screen, but the sub-platforms can now return multiple screens. > > The EGL subplatform will now query the low-level drivers, and if they detect multiple displays, multiple `Screen` instances will be configured. > The low-level native implementation for getting the number of physical screens and there characteristics is deferred to the real low-level libraries (for example, an X11 based approach can do it in a different way then a DRM based approach). This pull request has now been integrated. Changeset: a8a80b8c Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/a8a80b8c Stats: 298 lines in 7 files changed: 275 ins; 0 del; 23 mod 8092439: [Monocle] Refactor monocle SPI to allow support for multiple screens Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/426 From primoz.kokol at gmail.com Thu Mar 18 10:09:38 2021 From: primoz.kokol at gmail.com (=?UTF-8?Q?Primo=C5=BE_Kokol?=) Date: Thu, 18 Mar 2021 11:09:38 +0100 Subject: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> Message-ID: Thanks for pointing us in the right direction. I wasn't aware that jfxwebkit.pdb will be generated also in the case of a production build. So after generating a production build we were able to produce a thread dump (using jfxwebkit.pdb symbols) at the time when the application freezes. The complete bug report including thread dump is there: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788 Could you please just scan through it and let us know whether there is enough information to pursue this further or whether any additional information is needed? ? PrimosK On Tue, 16 Mar 2021 at 13:30, Arun Joseph wrote: > The app is now crashing at InternalFunction which calls jsDynamicCast in > JSCast.h, which lead to the initial crash. This assert failure occurs > because the type value is ObjectType instead of InternalFunctionType > or NullSetterFunctionType. I need to check why this is happens. > > NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, > for creating a build without asserts, you can either use the release build > PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal > debug build. > > ? Arun Joseph > > On 15-Mar-2021, at 6:08 PM, Primo? Kokol wrote: > > I've tried to remove this particular assert statement at "JSCast.h:143": > // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, > Target::info())); > > ... and now application crashes at different assert statement: > > > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, > const char * __formal, int __formal) Line 672 C++ Symbols loaded. > jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const > WTF::String & name, JSC::InternalFunction::NameAdditionMode > nameAdditionMode) Line 49 C++ Symbols loaded. > jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const > WTF::String & ident) Line 58 C++ Symbols loaded. > jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, > const WTF::String & name) Line 231 C++ Symbols loaded. > jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * > globalObject, const WTF::String & name, JSC::Bindings::Method * method) > Line 212 C++ Symbols loaded. > jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject > * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. > > jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject > * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) > Line 124 C++ Symbols loaded. > jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * > globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. > jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * > globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. > jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, > JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ > Symbols loaded. > jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * > pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, > JSC::JSValue baseValue, const JSC::Identifier & ident, > JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. > jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, > const JSC::Instruction * pc) Line 833 C++ Symbols loaded. > jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. > 00000025dabfaf00() Unknown Non-user code > 00000025dabfafc0() Unknown Non-user code > 00000164ca445b4b() Unknown Non-user code > cccccccccccccccc() Unknown Non-user code > 00000164ca445b46() Unknown Non-user code > > Is there any way we could turn off assertions in general when producing > debug build? > > On Sat, 13 Mar 2021 at 05:41, Arun Joseph > wrote: > >> I?m currently looking into why the native debug build is crashing. This >> same assert fails while running FileReaderTest using the native debug >> build. For the time being, you can try building by removing this particular >> assert statement for debugging. >> >> ? Arun Joseph >> >> > On 12-Mar-2021, at 11:47 PM, Primo? Kokol >> wrote: >> > >> > Hi Kevin, >> > >> > Unfortunately I don't have a test case. We are using various WebViews in >> > our production application hence we don't know where/why exactly the >> > application freezes. >> > >> > We were hoping that we will be able to identify it using the native >> debug >> > build (& attached debugged) but it is now unfortunately crashing with >> the >> > above error. >> > >> > Side note: >> > Should I contact Arun directly or is he seeing these messages? >> > >> > -- PrimosK >> > >> > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth < >> kevin.rushforth at oracle.com> >> > wrote: >> > >> >> Arun should be able to help you with the crash you are seeing in debug >> >> mode. >> >> >> >> Regarding the hang, do you have a test case that will reproduce it? A >> >> few different developers have reported similar hangs. We ended up >> >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> >> are) unable to reproduce the hang. >> >> >> >> -- Kevin >> >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> >> >> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >> >>> Hi everyone, >> >>> >> >>> I would need some help related to OpenJFX build. >> >>> >> >>> I was able to successfully prepare a build following this procedure >> (from >> >>> pull/417 request): >> >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >> >> >>> >> >>> We wanted to use it in our existing application (Java 11.0.10) to >> debug >> >> an >> >>> issue where the application would hang/freeze for no obvious reason >> >> because >> >>> of WebKit. >> >>> >> >>> In order to use this build we've manually overridden javafx-*.jar >> files >> >> in >> >>> our application with the ones from the above build. >> >>> We've also placed all produced DLL files in our application's "bin" >> >> folder >> >>> so they are properly picked up (I've verified and I can confirm that >> >>> jfxwebkit.dll produced by our debug build is loaded). >> >>> >> >>> After using this native debug build, the application will crash >> instead >> >>> with: >> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> >> Fatal >> >>> program exit requested. >> >>> >> >>> It looks like it happens when JS code calls Java method. >> >>> >> >>> There is the call stack at the time when exception happens: >> >>> >> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >> >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> >> const >> >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >> >>> >> >>> >> >> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >> >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 >> C++ >> >>> Symbols loaded. >> >>> >> >>> >> >> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >> >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >> >>> jfxwebkit.dll!JSC::jsDynamicCast> >>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) >> Line >> >>> 182 C++ Symbols loaded. >> >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> >> const >> >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >> >>> nameAdditionMode) Line 49 C++ Symbols loaded. >> >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >> >>> WTF::String & ident) Line 58 C++ Symbols loaded. >> >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & >> globalData, >> >>> const WTF::String & name) Line 231 C++ Symbols loaded. >> >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >> >>> globalObject, const WTF::String & name, JSC::Bindings::Method * >> method) >> >>> Line 212 C++ Symbols loaded. >> >>> >> >> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >> >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> >> loaded. >> >>> >> >>> >> >> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >> >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName >> propertyName) >> >>> Line 124 C++ Symbols loaded. >> >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >> >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols >> loaded. >> >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >> >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> >> loaded. >> >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >> >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >> >>> Symbols loaded. >> >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const >> JSC::Instruction * >> >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >> >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >> >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >> >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> >> const >> >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >> >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >> >>> 000000c7ef8fae90() Unknown Non-user code >> >>> 000000c7ef8faf50() Unknown Non-user code >> >>> 0000028d52eeedbb() Unknown Non-user code >> >>> cccccccccccccccc() Unknown Non-user code >> >>> 0000028d52eeedb6() Unknown Non-user code >> >>> >> >>> ... and partial output from the output console: >> >>> >> >>> .... >> >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, >> >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, >> (I)solates >> >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >> >> fi(x)ed, >> >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >> >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >> >> (t)transformed >> >>> ancestor >> >>> Dirty (z)-lists, Dirty (n)ormal flow lists >> >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or >> >>> hierarchy traversal on descendants, (r)equirements traversal on all >> >>> descendants, requirements traversal on all (s)ubsequent layers, >> >> (h)ierarchy >> >>> traversal on all descendants, update of paint (o)rder children >> >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids >> geometry, >> >>> (c)onfig, layer conne(x)ion, (s)crolling tree >> >>> Scrolling scope: box contents >> >>> >> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) >> width=460 >> >>> height=650 RenderView 0x28d4d4d1cd0 >> >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) >> width= >> >> no >> >>> compositing work to do >> >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >> >>> >> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >> >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >> >> header >> >>> height 0 footer height 0 fixed behavior 0 >> >>> layoutViewport: (0,0) width=460 height=650 >> >>> visualViewport: (0,0) width=460 height=650 (is override 0) >> >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >> >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >> >> 24.89s >> >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >> >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >> >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >> >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >> >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >> >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >> >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >> >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, >> Target::info()) >> >>> >> >> >> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >> >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >> >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> >> Fatal >> >>> program exit requested. >> >>> >> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >> >>> 17-ea+2 builds (that are at the time of writing this available on the >> >>> maven), but unfortunately we can't use these for debugging purposes. >> >>> >> >>> Does that indicate any issues with the native debug build or is this >> some >> >>> regression that was introduced in the current `master` branch recently >> >>> (after 17-ea+2)? >> >>> >> >>> Thanks for any helpful hints/advice in advance! >> >>> >> >>> Best regards, >> >>> PrimosK >> >> >> >> >> >> > From daniel.peintner at gmail.com Thu Mar 18 11:07:56 2021 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Thu, 18 Mar 2021 12:07:56 +0100 Subject: Dialog contentText does not wrap correctly always Message-ID: Hello, Thank you all for your work. I believe JavaFX is getting better and better. Some recent updates like [1] fixed some issues I was having with certain scaling levels. Today I stumbled over one issue that still exists with JavaFX version 16. It relates to dialog where the contentText usually nicels wraps to the next line if it does not fit. See below a simple code snippet and find on [2] screenshots that show the problem. (the problem is that it shows "..." and does *not* wrap to the next line) Are you aware of that problem? Thanks, -- Daniel [1] https://github.com/openjdk/jfx/pull/351 [2] https://github.com/danielpeintner/Java11Test/issues/5 import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.ButtonType; import javafx.scene.control.Label; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; import java.util.Optional; public class TestDialog extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { primaryStage.setTitle("HelloTest!"); Button btn = new Button(); btn.setText("Show Dialog"); btn.setOnAction(event -> { System.out.println("Hello World!"); Optional result = DialogUtil.showYesNoCancelDialog( "MyTitle", "MyHeader", "myContent 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30"); }); BorderPane bp = new BorderPane(); bp.setCenter(btn); primaryStage.setScene(new Scene(bp, 300, 250)); primaryStage.show(); } } From kcr at openjdk.java.net Thu Mar 18 12:22:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Mar 2021 12:22:46 GMT Subject: RFR: 8263759: Update boot JDK to 15.0.2 Message-ID: Simple fix to updated the boot JDK version to 15.0.2. Tested locally, and with the GitHub Actions build, both of which passed. ------------- Commit messages: - 8263759: Update boot JDK to 15.0.2 Changes: https://git.openjdk.java.net/jfx/pull/431/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=431&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263759 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/431.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/431/head:pull/431 PR: https://git.openjdk.java.net/jfx/pull/431 From arapte at openjdk.java.net Thu Mar 18 12:35:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 18 Mar 2021 12:35:58 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v2] In-Reply-To: References: Message-ID: <7Y6XVz9jU9GYCAGt6yCSzhuPDicfXlFzT7YIRES9kmw=.22251347-8625-42a3-a77c-510fd2052b31@github.com> > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: unit test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/429/files - new: https://git.openjdk.java.net/jfx/pull/429/files/93ccb9f7..4ed3f72f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=00-01 Stats: 120 lines in 3 files changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From arapte at openjdk.java.net Thu Mar 18 12:35:58 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 18 Mar 2021 12:35:58 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 18:28:44 GMT, Kevin Rushforth wrote: > Is there a unit test that can validate this fix? I have added a unit test using a new shim class. Test verifies size of the map that is added as part of this fix. So the test won't compile without this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From jvos at openjdk.java.net Thu Mar 18 13:12:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 18 Mar 2021 13:12:40 GMT Subject: RFR: 8263759: Update boot JDK to 15.0.2 In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 12:17:58 GMT, Kevin Rushforth wrote: > Simple fix to updated the boot JDK version to 15.0.2. Tested locally, and with the GitHub Actions build, both of which passed. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/431 From jackyguo579 at gmail.com Thu Mar 18 14:11:45 2021 From: jackyguo579 at gmail.com (Jacky Guo) Date: Thu, 18 Mar 2021 10:11:45 -0400 Subject: Building OpenJFX locally Message-ID: Hi there, I've cloned OpenJFX locally, but I can't build it, because I need to define the environment variable WINSDK_DIR. What do I need to set this to and what do I need to put in that folder Thanks! - Jacky Guo P.S. I only have Windows on a laptop, so I don't know how I can test for Linux and/or MacOS. From github.com+66004280+maran23 at openjdk.java.net Thu Mar 18 14:46:54 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Thu, 18 Mar 2021 14:46:54 GMT Subject: RFR: 8263807: Button types of a DialogPane are set twice, returns a wrong button Message-ID: <-16M4cl0aBE1Vtp_MOwO8wjRlIzTyAYQTPqMdHAjkuY=.dc3bc243-1e19-4072-9071-462fa8fc4091@github.com> When DialogPane#getButtonTypes().setAll() is called twice with the same argument(s), DialogPane#lookupButton does not return the node which is shown inside the button bar. This is due DialogPane adding two list change listeners to 'buttons' (#getButtonTypes). They have the wrong order, which will result in the button bar not changing at all, but the 'buttonNodes' list will recreate the dialog button, which is not shown. Finally, this will make DialogPane#lookupButton returning the 'wrong' button, which is in fact not used inside the dialog button bar. ------------- Commit messages: - Fix lookupButton does return wrong Node Changes: https://git.openjdk.java.net/jfx/pull/432/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263807 Stats: 53 lines in 2 files changed: 45 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/432.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/432/head:pull/432 PR: https://git.openjdk.java.net/jfx/pull/432 From kcr at openjdk.java.net Thu Mar 18 15:07:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Mar 2021 15:07:42 GMT Subject: Integrated: 8263759: Update boot JDK to 15.0.2 In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 12:17:58 GMT, Kevin Rushforth wrote: > Simple fix to updated the boot JDK version to 15.0.2. Tested locally, and with the GitHub Actions build, both of which passed. This pull request has now been integrated. Changeset: e23a2feb Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e23a2feb Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8263759: Update boot JDK to 15.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/431 From kcr at openjdk.java.net Thu Mar 18 15:32:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Mar 2021 15:32:41 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v2] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 20:47:09 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8239589-rdp-reconnect > - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop > - Ressource already freed from pool > - Recreate if adapterCount is zero > - Fix whitespace error > - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop I did a pass over the review and left a few inline comments pointing out minor changes that I plan to make (in print statements and comments). modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DContext.java line 158: > 156: int hr = D3DResourceFactory.nTestCooperativeLevel(pContext); > 157: > 158: if (PrismSettings.verbose && hr != D3D_OK) { This makes `prism.verbose` too noisy, since it will sometimes continually print non-failing return codes such as `S_PRESENT_MODE_CHANGED` or `S_PRESENT_OCCLUDED`. Separately, I might file an RFE to handle `S_PRESENT_MODE_CHANGED` which can happen in many cases (not related to this bug) such as changing the resolution of of the screen or plugging / unplugging a monitor. I'll change this to: `PrismSettings.verbose && FAILED(hr)` modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DPipeline.java line 186: > 184: void reinitialize() { > 185: if (PrismSettings.verbose) { > 186: System.err.println("D3DPipeline: reinitialize after device lost"); This probably should say "...device removed" modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java line 161: > 159: > 160: // gradientCacheTexture is left permanent and locked, although we still > 161: // must check for isSurfaceLost() is the case the device is disposed. Typo: "is the case..." --> "in case..." modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java line 174: > 172: > 173: // gtexCacheTexture is left permanent and locked, although we still > 174: // must check for isSurfaceLost() is the case the device is disposed. Typo: "is the case..." --> "in case..." ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Thu Mar 18 21:13:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Mar 2021 21:13:55 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v3] In-Reply-To: References: Message-ID: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Minor typos + make verbose print less verbose ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/430/files - new: https://git.openjdk.java.net/jfx/pull/430/files/0448f803..d4d0f7d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=01-02 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/430/head:pull/430 PR: https://git.openjdk.java.net/jfx/pull/430 From github.com+10960818+schmidor at openjdk.java.net Thu Mar 18 22:11:44 2021 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Thu, 18 Mar 2021 22:11:44 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v2] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 15:30:13 GMT, Kevin Rushforth wrote: >> Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8239589-rdp-reconnect >> - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop >> - Ressource already freed from pool >> - Recreate if adapterCount is zero >> - Fix whitespace error >> - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop > > I did a pass over the review and left a few inline comments pointing out minor changes that I plan to make (in print statements and comments). I can confirm the reinitialization after RDP reconnect works for me, standalone as JFX application and embedded in Swing. Even either the multiple reinit retries of earlier fix versions aren't necessary anymore or it is not showing in debug output. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Thu Mar 18 23:02:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Mar 2021 23:02:38 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v2] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 22:08:29 GMT, Oliver Schmidtmer wrote: >> I did a pass over the review and left a few inline comments pointing out minor changes that I plan to make (in print statements and comments). > > I can confirm the reinitialization after RDP reconnect works for me, standalone as JFX application and embedded in Swing. > Even either the multiple reinit retries of earlier fix versions aren't necessary anymore or it is not showing in debug output. Thanks for confirming. I got rid of all debugging code, so it wouldn't show in the output. If you want to see whether or not multiple re-inits are happening, you can run with the following env variable set: export NWT_TRACE_LEVEL=2 If you are getting a failure on first time init, it will say something like `Zero adapters found`. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From arapte at openjdk.java.net Fri Mar 19 08:24:43 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 19 Mar 2021 08:24:43 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v3] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 21:13:55 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor typos + make verbose print less verbose The fix and Sanity testing looks all good. I shall need some more time to do a detailed review. Added minor comments, please address whenever you update next commit. modules/javafx.graphics/src/main/java/com/sun/prism/ResourceFactory.java line 38: > 36: * If this resource factory has been disposed, it is no longer valid and > 37: * will need to be recreated before any new resources can be created. > 38: * Any attempt to create a resource will be ignored will return null. Minor: ignored will return null. -> ignored `and `will return null. modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DPipeline.java line 245: > 243: D3DPipeline.getInstance().reinitialize(); > 244: > 245: // If reinitializion failed, return a null resource factory; we will Minor: reinitializion -> reinitialization modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/RTImage.java line 52: > 50: private RTTexture txt; > 51: private final int width, height; > 52: private WeakReference listenerAdded = null; may be rename the variable to `resourceFactoryRef` ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Fri Mar 19 12:08:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Mar 2021 12:08:04 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v4] In-Reply-To: References: Message-ID: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review comments to fix typos, naming ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/430/files - new: https://git.openjdk.java.net/jfx/pull/430/files/d4d0f7d7..11e609c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=02-03 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/430/head:pull/430 PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Fri Mar 19 12:08:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Mar 2021 12:08:05 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v3] In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 08:17:56 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor typos + make verbose print less verbose > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/RTImage.java line 52: > >> 50: private RTTexture txt; >> 51: private final int width, height; >> 52: private WeakReference listenerAdded = null; > > may be rename the variable to `resourceFactoryRef` I renamed it here, and in `WCPageBackBufferImpl`, to `registeredWithFactory` which is the same name as is used in `PrismMediaFrameHandler`. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From ajoseph at openjdk.java.net Fri Mar 19 12:48:43 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Fri, 19 Mar 2021 12:48:43 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v4] In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 12:08:04 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments to fix typos, naming modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCPageBackBufferImpl.java line 126: > 124: firstValidate = false; > 125: } else { > 126: // texture must have been nullified in factoryReset() or factoryReleased. Minor: factoryReleased -> factoryReleased() ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From clementlevallois at protonmail.com Fri Mar 19 13:29:52 2021 From: clementlevallois at protonmail.com (Clement Levallois) Date: Fri, 19 Mar 2021 13:29:52 +0000 Subject: Not really a nice comment but a real issue? Message-ID: Hi all, I just came across this blog post which complains about a badly implemented stream reader in JavaFX. The general tone is not nice, but I figured this could be useful to the developers maintaining this area: https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ Best regards, Clement PS: I landed on this blog post because I was searching for some pointers on a coding problem I have with JavaFX Service / Task, which might or might not involve inputStreams. I share it here: https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered -- Cl?ment Levallois Associate Professor emlyon business school Twitter and Skype: @seinecle mobile: +33(0)6 59 08 33 92 Sent with [ProtonMail](https://protonmail.com) Secure Email. From tbee at tbee.org Fri Mar 19 13:42:40 2021 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 19 Mar 2021 14:42:40 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: <055b02c8-97a6-d922-cf3e-25e5d4a2db54@tbee.org> The blog does make some valid points. On 19-3-2021 14:29, Clement Levallois wrote: > Hi all, > > I just came across this blog post which complains about a badly implemented stream reader in JavaFX. The general tone is not nice, but I figured this could be useful to the developers maintaining this area: > > https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ > > Best regards, > > Clement > PS: I landed on this blog post because I was searching for some pointers on a coding problem I have with JavaFX Service / Task, which might or might not involve inputStreams. I share it here: https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered > -- > Cl?ment Levallois > Associate Professor > emlyon business school > Twitter and Skype: @seinecle > mobile: +33(0)6 59 08 33 92 > > Sent with [ProtonMail](https://protonmail.com) Secure Email. From pedro.duquevieira at gmail.com Fri Mar 19 14:32:02 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 19 Mar 2021 14:32:02 +0000 Subject: Not really a nice comment but a real issue? Message-ID: Hi I actually totally disagree with his conclusion. In fact, I'd say, that's one of the hidden gems of JavaFX! Check out CSSFX and this video https://www.youtube.com/watch?v=RELKg32xEWU to understand the advantages of this feature (ScenicView has also integrated CSSFX to take advantage of this). Think about the productivity boost of tweaking your UI at runtime and not having to go through the cycle: tweak UI -> compile -> run -> (No that's not it) -> close app -> tweak UI again -> compile again -> run again -> (No that's not it again) -> [repeat till infinity] Also think about the potential for adding tools that build on top of this feature. Tools like firebug or features from Chrome developer tools, etc, that they use on the web to debug / tweak UIs during runtime. Cheers, > On 19-3-2021 14:29, Clement Levallois wrote: > > Hi all, > > > > I just came across this blog post which complains about a badly > implemented stream reader in JavaFX. The general tone is not nice, but I > figured this could be useful to the developers maintaining this area: > > > > https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ > > > > Best regards, > > > > Clement > > PS: I landed on this blog post because I was searching for some pointers > on a coding problem I have with JavaFX Service / Task, which might or might > not involve inputStreams. I share it here: > https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered > > -- > > Cl?ment Levallois > > Associate Professor > > emlyon business school > > Twitter and Skype: @seinecle > > mobile: +33(0)6 59 08 33 92 > > > > Sent with [ProtonMail](https://protonmail.com) Secure Email. -- Pedro Duque Vieira - https://www.pixelduke.com From tbee at tbee.org Fri Mar 19 14:50:45 2021 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 19 Mar 2021 15:50:45 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: <5781fe5d-f230-3071-5fb6-be38bd7df311@tbee.org> A good feature during development is not necessarily a good feature during production, especially if it (apparently) has a significant performance impact. But I see your point. On 19-3-2021 15:32, Pedro Duque Vieira wrote: > Hi > > I actually totally disagree with his conclusion. > > In fact, I'd say, that's one of the hidden gems of JavaFX! > Check out CSSFX and this video https://www.youtube.com/watch?v=RELKg32xEWU > to understand the advantages of this feature (ScenicView has also > integrated CSSFX to take advantage of this). > > Think about the productivity boost of tweaking your UI at runtime and not > having to go through the cycle: tweak UI -> compile -> run -> (No that's > not it) -> close app -> tweak UI again -> compile again -> run again -> (No > that's not it again) -> [repeat till infinity] > > Also think about the potential for adding tools that build on top of this > feature. Tools like firebug or features from Chrome developer tools, etc, > that they use on the web to debug / tweak UIs during runtime. > > Cheers, > > >> On 19-3-2021 14:29, Clement Levallois wrote: >>> Hi all, >>> >>> I just came across this blog post which complains about a badly >> implemented stream reader in JavaFX. The general tone is not nice, but I >> figured this could be useful to the developers maintaining this area: >>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>> >>> Best regards, >>> >>> Clement >>> PS: I landed on this blog post because I was searching for some pointers >> on a coding problem I have with JavaFX Service / Task, which might or might >> not involve inputStreams. I share it here: >> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>> -- >>> Cl?ment Levallois >>> Associate Professor >>> emlyon business school >>> Twitter and Skype: @seinecle >>> mobile: +33(0)6 59 08 33 92 >>> >>> Sent with [ProtonMail](https://protonmail.com) Secure Email. > From kevin.rushforth at oracle.com Fri Mar 19 15:03:19 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 08:03:19 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: This isn't something we'd change anyway without a lot of discussion; almost certainly we would leave the current behavior as the default, and provide an "opt out" for applications that prefer to do so. As for the performance problem, ignoring the tone of the blog and the fact that the point is blown out of proportion, the lack of buffering in this case is clearly a bug, which I just filed as JDK-8263875 [1]. Clement: regarding the issue about using and InputStream with JavaFX Service / Task: it sounds like it might be a bug, so if you have a complete test program, can you file a bug at https://bugreport.java.com/ ? -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8263875 On 3/19/2021 7:32 AM, Pedro Duque Vieira wrote: > Hi > > I actually totally disagree with his conclusion. > > In fact, I'd say, that's one of the hidden gems of JavaFX! > Check out CSSFX and this video https://www.youtube.com/watch?v=RELKg32xEWU > to understand the advantages of this feature (ScenicView has also > integrated CSSFX to take advantage of this). > > Think about the productivity boost of tweaking your UI at runtime and not > having to go through the cycle: tweak UI -> compile -> run -> (No that's > not it) -> close app -> tweak UI again -> compile again -> run again -> (No > that's not it again) -> [repeat till infinity] > > Also think about the potential for adding tools that build on top of this > feature. Tools like firebug or features from Chrome developer tools, etc, > that they use on the web to debug / tweak UIs during runtime. > > Cheers, > > >> On 19-3-2021 14:29, Clement Levallois wrote: >>> Hi all, >>> >>> I just came across this blog post which complains about a badly >> implemented stream reader in JavaFX. The general tone is not nice, but I >> figured this could be useful to the developers maintaining this area: >>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>> >>> Best regards, >>> >>> Clement >>> PS: I landed on this blog post because I was searching for some pointers >> on a coding problem I have with JavaFX Service / Task, which might or might >> not involve inputStreams. I share it here: >> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>> -- >>> Cl?ment Levallois >>> Associate Professor >>> emlyon business school >>> Twitter and Skype: @seinecle >>> mobile: +33(0)6 59 08 33 92 >>> >>> Sent with [ProtonMail](https://protonmail.com) Secure Email. > From nlisker at gmail.com Fri Mar 19 15:11:13 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 19 Mar 2021 17:11:13 +0200 Subject: Building OpenJFX locally In-Reply-To: References: Message-ID: Did you go through https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX? Where what error do you get at which step? On Thu, Mar 18, 2021 at 4:12 PM Jacky Guo wrote: > Hi there, > I've cloned OpenJFX locally, but I can't build it, because I need to define > the environment variable WINSDK_DIR. What do I need to set this to and what > do I need to put in that folder > > Thanks! > - Jacky Guo > > P.S. I only have Windows on a laptop, so I don't know how I can test for > Linux and/or MacOS. > From nlisker at gmail.com Fri Mar 19 15:16:02 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 19 Mar 2021 17:16:02 +0200 Subject: user mailing list In-Reply-To: References: Message-ID: The mailing lists are only for development and discussion purposes. If you think there's a bug or a missing feature you can ask here, but if you need help then there is no formal mailing list for that. If SO didn't help, you can try r/JavaFX on Reddit or search for a JavaFX discord server. On Mon, Mar 15, 2021 at 9:25 PM Zsolt K?ti wrote: > Hi, > > I asked something on Stackoverflow I do not think I can formulate better, > but it was closed right away. Is there a mailing list for user questions? > > Thx, > Zsolt > From pedro.duquevieira at gmail.com Fri Mar 19 15:34:16 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 19 Mar 2021 15:34:16 +0000 Subject: Not really a nice comment but a real issue? Message-ID: In the blog post he makes it sounds like it isn't good for anything to have that. That it is just a bug, something that wasn't well thought through and reviewed or a pointless feature. Which I totally disagree with. I think it can be very interesting to take advantage of that. I think the performance problem he measured was more about the buffering issue than about dynamically reloading the stylesheet whenever there's a change. But yeah, this might have a performance impact. If there is indeed a considerable impact, perhaps we could have a flag to opt out of this feature. That way we can have the best of both worlds and not have this feature impact the apps performance in production. Cheers, A good feature during development is not necessarily a good feature during > production, especially if it (apparently) has a significant performance > impact. > But I see your point. > > On 19-3-2021 15:32, Pedro Duque Vieira wrote: > > Hi > > > > I actually totally disagree with his conclusion. > > > > In fact, I'd say, that's one of the hidden gems of JavaFX! > > Check out CSSFX and this video > https://www.youtube.com/watch?v=RELKg32xEWU > > to understand the advantages of this feature (ScenicView has also > > integrated CSSFX to take advantage of this). > > > > Think about the productivity boost of tweaking your UI at runtime and not > > having to go through the cycle: tweak UI -> compile -> run -> (No that's > > not it) -> close app -> tweak UI again -> compile again -> run again -> > (No > > that's not it again) -> [repeat till infinity] > > > > Also think about the potential for adding tools that build on top of this > > feature. Tools like firebug or features from Chrome developer tools, etc, > > that they use on the web to debug / tweak UIs during runtime. > > > > Cheers, > > > > > >> On 19-3-2021 14:29, Clement Levallois wrote: > >>> Hi all, > >>> > >>> I just came across this blog post which complains about a badly > >> implemented stream reader in JavaFX. The general tone is not nice, but I > >> figured this could be useful to the developers maintaining this area: > >>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ > >>> > >>> Best regards, > >>> > >>> Clement > >>> PS: I landed on this blog post because I was searching for some > pointers > >> on a coding problem I have with JavaFX Service / Task, which might or > might > >> not involve inputStreams. I share it here: > >> > https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered > >>> -- > >>> Cl?ment Levallois > >>> Associate Professor > >>> emlyon business school > >>> Twitter and Skype: @seinecle > >>> mobile: +33(0)6 59 08 33 92 > >>> > >>> Sent with [ProtonMail](https://protonmail.com) Secure Email. > > -- Pedro Duque Vieira - https://www.pixelduke.com From richard.bair at oracle.com Fri Mar 19 16:08:04 2021 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 19 Mar 2021 16:08:04 +0000 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> Hey everybody! These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid. Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn?t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. Cheers Richard > On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira wrote: > > In the blog post he makes it sounds like it isn't good for anything to have > that. That it is just a bug, something that wasn't well thought through and > reviewed or a pointless feature. Which I totally disagree with. I think it > can be very interesting to take advantage of that. > > I think the performance problem he measured was more about the buffering > issue than about dynamically reloading the stylesheet whenever there's a > change. But yeah, this might have a performance impact. If there is indeed > a considerable impact, perhaps we could have a flag to opt out of this > feature. That way we can have the best of both worlds and not have this > feature impact the apps performance in production. > > Cheers, > > > A good feature during development is not necessarily a good feature during >> production, especially if it (apparently) has a significant performance >> impact. >> But I see your point. >> >> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>> Hi >>> >>> I actually totally disagree with his conclusion. >>> >>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>> Check out CSSFX and this video >> https://www.youtube.com/watch?v=RELKg32xEWU >>> to understand the advantages of this feature (ScenicView has also >>> integrated CSSFX to take advantage of this). >>> >>> Think about the productivity boost of tweaking your UI at runtime and not >>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>> not it) -> close app -> tweak UI again -> compile again -> run again -> >> (No >>> that's not it again) -> [repeat till infinity] >>> >>> Also think about the potential for adding tools that build on top of this >>> feature. Tools like firebug or features from Chrome developer tools, etc, >>> that they use on the web to debug / tweak UIs during runtime. >>> >>> Cheers, >>> >>> >>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>> Hi all, >>>>> >>>>> I just came across this blog post which complains about a badly >>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>> figured this could be useful to the developers maintaining this area: >>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>> >>>>> Best regards, >>>>> >>>>> Clement >>>>> PS: I landed on this blog post because I was searching for some >> pointers >>>> on a coding problem I have with JavaFX Service / Task, which might or >> might >>>> not involve inputStreams. I share it here: >>>> >> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>>> -- >>>>> Cl?ment Levallois >>>>> Associate Professor >>>>> emlyon business school >>>>> Twitter and Skype: @seinecle >>>>> mobile: +33(0)6 59 08 33 92 >>>>> >>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>> > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Fri Mar 19 16:17:03 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 09:17:03 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> Message-ID: <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> That's an interesting idea about looking at the HTTP response headers and checking to see whether the file has changed. If it could be done in such a way that it minimizes overhead, it might be the best of both worlds. I'll file an RFE to look into that...not sure we'll get time to do it, though, so if someone from the community wants to take it, that would help. Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to completion). The main question I can think of that would need to be answered is: what should be the granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be of setting it from "false" back to the (default) "true". -- Kevin On 3/19/2021 9:08 AM, Richard Bair wrote: > Hey everybody! > > These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid. > > Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn?t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. > > Cheers > Richard > >> On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira wrote: >> >> In the blog post he makes it sounds like it isn't good for anything to have >> that. That it is just a bug, something that wasn't well thought through and >> reviewed or a pointless feature. Which I totally disagree with. I think it >> can be very interesting to take advantage of that. >> >> I think the performance problem he measured was more about the buffering >> issue than about dynamically reloading the stylesheet whenever there's a >> change. But yeah, this might have a performance impact. If there is indeed >> a considerable impact, perhaps we could have a flag to opt out of this >> feature. That way we can have the best of both worlds and not have this >> feature impact the apps performance in production. >> >> Cheers, >> >> >> A good feature during development is not necessarily a good feature during >>> production, especially if it (apparently) has a significant performance >>> impact. >>> But I see your point. >>> >>> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>>> Hi >>>> >>>> I actually totally disagree with his conclusion. >>>> >>>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>>> Check out CSSFX and this video >>> https://www.youtube.com/watch?v=RELKg32xEWU >>>> to understand the advantages of this feature (ScenicView has also >>>> integrated CSSFX to take advantage of this). >>>> >>>> Think about the productivity boost of tweaking your UI at runtime and not >>>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>>> not it) -> close app -> tweak UI again -> compile again -> run again -> >>> (No >>>> that's not it again) -> [repeat till infinity] >>>> >>>> Also think about the potential for adding tools that build on top of this >>>> feature. Tools like firebug or features from Chrome developer tools, etc, >>>> that they use on the web to debug / tweak UIs during runtime. >>>> >>>> Cheers, >>>> >>>> >>>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>>> Hi all, >>>>>> >>>>>> I just came across this blog post which complains about a badly >>>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>>> figured this could be useful to the developers maintaining this area: >>>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Clement >>>>>> PS: I landed on this blog post because I was searching for some >>> pointers >>>>> on a coding problem I have with JavaFX Service / Task, which might or >>> might >>>>> not involve inputStreams. I share it here: >>>>> >>> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>>>> -- >>>>>> Cl?ment Levallois >>>>>> Associate Professor >>>>>> emlyon business school >>>>>> Twitter and Skype: @seinecle >>>>>> mobile: +33(0)6 59 08 33 92 >>>>>> >>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com From kevin.rushforth at oracle.com Fri Mar 19 16:29:08 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 09:29:08 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8263886 On 3/19/2021 9:17 AM, Kevin Rushforth wrote: > That's an interesting idea about looking at the HTTP response headers > and checking to see whether the file has changed. If it could be done > in such a way that it minimizes overhead, it might be the best of both > worlds. I'll file an RFE to look into that...not sure we'll get time > to do it, though, so if someone from the community wants to take it, > that would help. > > Regarding an "opt out" mechanism, If someone wants to propose an API > to do that, we'd be happy to consider it (as with the above, it will > be more likely to get done if someone volunteers to drive it to > completion). The main question I can think of that would need to be > answered is: what should be the granularity of the new boolean > attribute? Global (probably on Platform then)? Per Scene? Per Region > (which would also need to be on the Scene with Region overriding it)? > Another is around what the behavior should be of setting it from > "false" back to the (default) "true". > > -- Kevin > > > On 3/19/2021 9:08 AM, Richard Bair wrote: >> Hey everybody! >> >> These all sound like really good points. I agree with Pedro that the >> ability to auto-reload (especially during development) is a really >> great thing, but I agree with the blog post and Clemens that in >> production this can be problematic depending on the location of the >> source CSS file, and in any event does introduce some performance >> overhead that would be nice to avoid. >> >> Could JavaFX look at response headers when loading CSS over HTTP/S to >> determine whether the CSS file can be cached and then maintain a >> local cache for such CSS files? That would resolve one particular >> issue where CSS is loaded remotely. Could JavaFX use a different >> mechanism for watching the CSS files when loaded from disk so that it >> isn?t re-read every time but only when a change had been detected? I >> think both of those enhancements could probably be done while >> remaining consistent with the existing semantics. Add the Bug fix in >> that Kevin mentioned and I think most of the practical problems >> raised by the blog post would be fixed. >> >> Cheers >> Richard >> >>> On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira >>> wrote: >>> >>> In the blog post he makes it sounds like it isn't good for anything >>> to have >>> that. That it is just a bug, something that wasn't well thought >>> through and >>> reviewed or a pointless feature. Which I totally disagree with. I >>> think it >>> can be very interesting to take advantage of that. >>> >>> I think the performance problem he measured was more about the >>> buffering >>> issue than about dynamically reloading the stylesheet whenever >>> there's a >>> change. But yeah, this might have a performance impact. If there is >>> indeed >>> a considerable impact, perhaps we could have a flag to opt out of this >>> feature. That way we can have the best of both worlds and not have this >>> feature impact the apps performance in production. >>> >>> Cheers, >>> >>> >>> A good feature during development is not necessarily a good feature >>> during >>>> production, especially if it (apparently) has a significant >>>> performance >>>> impact. >>>> But I see your point. >>>> >>>> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>>>> Hi >>>>> >>>>> I actually totally disagree with his conclusion. >>>>> >>>>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>>>> Check out CSSFX and this video >>>> https://www.youtube.com/watch?v=RELKg32xEWU >>>>> to understand the advantages of this feature (ScenicView has also >>>>> integrated CSSFX to take advantage of this). >>>>> >>>>> Think about the productivity boost of tweaking your UI at runtime >>>>> and not >>>>> having to go through the cycle: tweak UI -> compile -> run -> (No >>>>> that's >>>>> not it) -> close app -> tweak UI again -> compile again -> run >>>>> again -> >>>> (No >>>>> that's not it again) -> [repeat till infinity] >>>>> >>>>> Also think about the potential for adding tools that build on top >>>>> of this >>>>> feature. Tools like firebug or features from Chrome developer >>>>> tools, etc, >>>>> that they use on the web to debug / tweak UIs during runtime. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I just came across this blog post which complains about a badly >>>>>> implemented stream reader in JavaFX. The general tone is not >>>>>> nice, but I >>>>>> figured this could be useful to the developers maintaining this >>>>>> area: >>>>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Clement >>>>>>> PS: I landed on this blog post because I was searching for some >>>> pointers >>>>>> on a coding problem I have with JavaFX Service / Task, which >>>>>> might or >>>> might >>>>>> not involve inputStreams. I share it here: >>>>>> >>>> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>> >>>>>>> -- >>>>>>> Cl?ment Levallois >>>>>>> Associate Professor >>>>>>> emlyon business school >>>>>>> Twitter and Skype: @seinecle >>>>>>> mobile: +33(0)6 59 08 33 92 >>>>>>> >>>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com > From dlemmermann at gmail.com Fri Mar 19 16:34:09 2021 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 19 Mar 2021 17:34:09 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> Message-ID: I took the liberty of informing the author of the blog. It was hard not to comment on the tone he used ?.. but we all know that never leads to anything. Let the facts speak for themselves and they tell him that he was heard and his findings resulted in tickets and hopefully fixes soon. Dirk > On Mar 19, 2021, at 5:29 PM, Kevin Rushforth wrote: > > https://bugs.openjdk.java.net/browse/JDK-8263886 > > On 3/19/2021 9:17 AM, Kevin Rushforth wrote: >> That's an interesting idea about looking at the HTTP response headers and checking to see whether the file has changed. If it could be done in such a way that it minimizes overhead, it might be the best of both worlds. I'll file an RFE to look into that...not sure we'll get time to do it, though, so if someone from the community wants to take it, that would help. >> >> Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to completion). The main question I can think of that would need to be answered is: what should be the granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be of setting it from "false" back to the (default) "true". >> >> -- Kevin >> >> >> On 3/19/2021 9:08 AM, Richard Bair wrote: >>> Hey everybody! >>> >>> These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid. >>> >>> Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn?t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. >>> >>> Cheers >>> Richard >>> >>>> On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira wrote: >>>> >>>> In the blog post he makes it sounds like it isn't good for anything to have >>>> that. That it is just a bug, something that wasn't well thought through and >>>> reviewed or a pointless feature. Which I totally disagree with. I think it >>>> can be very interesting to take advantage of that. >>>> >>>> I think the performance problem he measured was more about the buffering >>>> issue than about dynamically reloading the stylesheet whenever there's a >>>> change. But yeah, this might have a performance impact. If there is indeed >>>> a considerable impact, perhaps we could have a flag to opt out of this >>>> feature. That way we can have the best of both worlds and not have this >>>> feature impact the apps performance in production. >>>> >>>> Cheers, >>>> >>>> >>>> A good feature during development is not necessarily a good feature during >>>>> production, especially if it (apparently) has a significant performance >>>>> impact. >>>>> But I see your point. >>>>> >>>>> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>>>>> Hi >>>>>> >>>>>> I actually totally disagree with his conclusion. >>>>>> >>>>>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>>>>> Check out CSSFX and this video >>>>> https://www.youtube.com/watch?v=RELKg32xEWU >>>>>> to understand the advantages of this feature (ScenicView has also >>>>>> integrated CSSFX to take advantage of this). >>>>>> >>>>>> Think about the productivity boost of tweaking your UI at runtime and not >>>>>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>>>>> not it) -> close app -> tweak UI again -> compile again -> run again -> >>>>> (No >>>>>> that's not it again) -> [repeat till infinity] >>>>>> >>>>>> Also think about the potential for adding tools that build on top of this >>>>>> feature. Tools like firebug or features from Chrome developer tools, etc, >>>>>> that they use on the web to debug / tweak UIs during runtime. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I just came across this blog post which complains about a badly >>>>>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>>>>> figured this could be useful to the developers maintaining this area: >>>>>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Clement >>>>>>>> PS: I landed on this blog post because I was searching for some >>>>> pointers >>>>>>> on a coding problem I have with JavaFX Service / Task, which might or >>>>> might >>>>>>> not involve inputStreams. I share it here: >>>>>>> >>>>> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>>>>>> -- >>>>>>>> Cl?ment Levallois >>>>>>>> Associate Professor >>>>>>>> emlyon business school >>>>>>>> Twitter and Skype: @seinecle >>>>>>>> mobile: +33(0)6 59 08 33 92 >>>>>>>> >>>>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>>> >>>> -- >>>> Pedro Duque Vieira - https://www.pixelduke.com >> > From kevin.rushforth at oracle.com Fri Mar 19 16:46:49 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 09:46:49 -0700 Subject: [External] : Re: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> Message-ID: <8e2ea74f-b583-7037-af5d-120252f60c67@oracle.com> Thank you, Dirk. I'll make sure that the obvious bug of reading from an unbuffered stream is fixed for FX 17. No promises on the enhancements, of course. -- Kevin On 3/19/2021 9:34 AM, Dirk Lemmermann wrote: > I took the liberty of informing the author of the blog. It was hard not to comment on the tone he used ?.. but we all know that never leads to anything. Let the facts speak for themselves and they tell him that he was heard and his findings resulted in tickets and hopefully fixes soon. > > Dirk > >> On Mar 19, 2021, at 5:29 PM, Kevin Rushforth wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8263886 >> >> On 3/19/2021 9:17 AM, Kevin Rushforth wrote: >>> That's an interesting idea about looking at the HTTP response headers and checking to see whether the file has changed. If it could be done in such a way that it minimizes overhead, it might be the best of both worlds. I'll file an RFE to look into that...not sure we'll get time to do it, though, so if someone from the community wants to take it, that would help. >>> >>> Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to completion). The main question I can think of that would need to be answered is: what should be the granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be of setting it from "false" back to the (default) "true". >>> >>> -- Kevin >>> >>> >>> On 3/19/2021 9:08 AM, Richard Bair wrote: >>>> Hey everybody! >>>> >>>> These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid. >>>> >>>> Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn?t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. >>>> >>>> Cheers >>>> Richard >>>> >>>>> On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira wrote: >>>>> >>>>> In the blog post he makes it sounds like it isn't good for anything to have >>>>> that. That it is just a bug, something that wasn't well thought through and >>>>> reviewed or a pointless feature. Which I totally disagree with. I think it >>>>> can be very interesting to take advantage of that. >>>>> >>>>> I think the performance problem he measured was more about the buffering >>>>> issue than about dynamically reloading the stylesheet whenever there's a >>>>> change. But yeah, this might have a performance impact. If there is indeed >>>>> a considerable impact, perhaps we could have a flag to opt out of this >>>>> feature. That way we can have the best of both worlds and not have this >>>>> feature impact the apps performance in production. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> A good feature during development is not necessarily a good feature during >>>>>> production, especially if it (apparently) has a significant performance >>>>>> impact. >>>>>> But I see your point. >>>>>> >>>>>> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>>>>>> Hi >>>>>>> >>>>>>> I actually totally disagree with his conclusion. >>>>>>> >>>>>>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>>>>>> Check out CSSFX and this video >>>>>> https://urldefense.com/v3/__https://www.youtube.com/watch?v=RELKg32xEWU__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vTw53GCg$ >>>>>>> to understand the advantages of this feature (ScenicView has also >>>>>>> integrated CSSFX to take advantage of this). >>>>>>> >>>>>>> Think about the productivity boost of tweaking your UI at runtime and not >>>>>>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>>>>>> not it) -> close app -> tweak UI again -> compile again -> run again -> >>>>>> (No >>>>>>> that's not it again) -> [repeat till infinity] >>>>>>> >>>>>>> Also think about the potential for adding tools that build on top of this >>>>>>> feature. Tools like firebug or features from Chrome developer tools, etc, >>>>>>> that they use on the web to debug / tweak UIs during runtime. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I just came across this blog post which complains about a badly >>>>>>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>>>>>> figured this could be useful to the developers maintaining this area: >>>>>>>>> https://urldefense.com/v3/__https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vdMXtREi$ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Clement >>>>>>>>> PS: I landed on this blog post because I was searching for some >>>>>> pointers >>>>>>>> on a coding problem I have with JavaFX Service / Task, which might or >>>>>> might >>>>>>>> not involve inputStreams. I share it here: >>>>>>>> >>>>>> https://urldefense.com/v3/__https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vVAiFenV$ >>>>>>>>> -- >>>>>>>>> Cl?ment Levallois >>>>>>>>> Associate Professor >>>>>>>>> emlyon business school >>>>>>>>> Twitter and Skype: @seinecle >>>>>>>>> mobile: +33(0)6 59 08 33 92 >>>>>>>>> >>>>>>>>> Sent with [ProtonMail](https://urldefense.com/v3/__https://protonmail.com__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vZM09C8y$ ) Secure Email. >>>>> -- >>>>> Pedro Duque Vieira - https://urldefense.com/v3/__https://www.pixelduke.com__;!!GqivPVa7Brio!NJO99z_N5n7xqK7eVAb7Cos85ifse0TZqJLTFOtCK3bplKqr9YzW9I_V9Pg7vcWTLKUu$ From philip.race at oracle.com Fri Mar 19 18:05:34 2021 From: philip.race at oracle.com (Philip Race) Date: Fri, 19 Mar 2021 11:05:34 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> Message-ID: Sadly it has taken > 1 year for his blog post to reach the right audience. If this was important to him I don't understand why just a blog post and not a bug report .. The buffering at least seems like a quick fix. -phil. On 3/19/21 9:34 AM, Dirk Lemmermann wrote: > I took the liberty of informing the author of the blog. It was hard not to comment on the tone he used ?.. but we all know that never leads to anything. Let the facts speak for themselves and they tell him that he was heard and his findings resulted in tickets and hopefully fixes soon. > > Dirk > >> On Mar 19, 2021, at 5:29 PM, Kevin Rushforth wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8263886 >> >> On 3/19/2021 9:17 AM, Kevin Rushforth wrote: >>> That's an interesting idea about looking at the HTTP response headers and checking to see whether the file has changed. If it could be done in such a way that it minimizes overhead, it might be the best of both worlds. I'll file an RFE to look into that...not sure we'll get time to do it, though, so if someone from the community wants to take it, that would help. >>> >>> Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to completion). The main question I can think of that would need to be answered is: what should be the granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be of setting it from "false" back to the (default) "true". >>> >>> -- Kevin >>> >>> >>> On 3/19/2021 9:08 AM, Richard Bair wrote: >>>> Hey everybody! >>>> >>>> These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid. >>>> >>>> Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn?t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed. >>>> >>>> Cheers >>>> Richard >>>> >>>>> On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira wrote: >>>>> >>>>> In the blog post he makes it sounds like it isn't good for anything to have >>>>> that. That it is just a bug, something that wasn't well thought through and >>>>> reviewed or a pointless feature. Which I totally disagree with. I think it >>>>> can be very interesting to take advantage of that. >>>>> >>>>> I think the performance problem he measured was more about the buffering >>>>> issue than about dynamically reloading the stylesheet whenever there's a >>>>> change. But yeah, this might have a performance impact. If there is indeed >>>>> a considerable impact, perhaps we could have a flag to opt out of this >>>>> feature. That way we can have the best of both worlds and not have this >>>>> feature impact the apps performance in production. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> A good feature during development is not necessarily a good feature during >>>>>> production, especially if it (apparently) has a significant performance >>>>>> impact. >>>>>> But I see your point. >>>>>> >>>>>> On 19-3-2021 15:32, Pedro Duque Vieira wrote: >>>>>>> Hi >>>>>>> >>>>>>> I actually totally disagree with his conclusion. >>>>>>> >>>>>>> In fact, I'd say, that's one of the hidden gems of JavaFX! >>>>>>> Check out CSSFX and this video >>>>>> https://www.youtube.com/watch?v=RELKg32xEWU >>>>>>> to understand the advantages of this feature (ScenicView has also >>>>>>> integrated CSSFX to take advantage of this). >>>>>>> >>>>>>> Think about the productivity boost of tweaking your UI at runtime and not >>>>>>> having to go through the cycle: tweak UI -> compile -> run -> (No that's >>>>>>> not it) -> close app -> tweak UI again -> compile again -> run again -> >>>>>> (No >>>>>>> that's not it again) -> [repeat till infinity] >>>>>>> >>>>>>> Also think about the potential for adding tools that build on top of this >>>>>>> feature. Tools like firebug or features from Chrome developer tools, etc, >>>>>>> that they use on the web to debug / tweak UIs during runtime. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>>>> On 19-3-2021 14:29, Clement Levallois wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I just came across this blog post which complains about a badly >>>>>>>> implemented stream reader in JavaFX. The general tone is not nice, but I >>>>>>>> figured this could be useful to the developers maintaining this area: >>>>>>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Clement >>>>>>>>> PS: I landed on this blog post because I was searching for some >>>>>> pointers >>>>>>>> on a coding problem I have with JavaFX Service / Task, which might or >>>>>> might >>>>>>>> not involve inputStreams. I share it here: >>>>>>>> >>>>>> https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered >>>>>>>>> -- >>>>>>>>> Cl?ment Levallois >>>>>>>>> Associate Professor >>>>>>>>> emlyon business school >>>>>>>>> Twitter and Skype: @seinecle >>>>>>>>> mobile: +33(0)6 59 08 33 92 >>>>>>>>> >>>>>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>>>> -- >>>>> Pedro Duque Vieira - https://www.pixelduke.com From john at status6.com Fri Mar 19 19:23:54 2021 From: john at status6.com (John Neffenger) Date: Fri, 19 Mar 2021 12:23:54 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> Message-ID: <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> On 3/19/21 11:05 AM, Philip Race wrote: > If this was important to him I don't understand why just a blog post and > not a bug report .. If I had to guess, it might be because, in the age of GitHub, this is not what people expect when they try to report a bug: Report a Bug or Request a Feature https://bugreport.java.com/bugreport/ There are two main problems: 1. You can't attach images. 2. You don't get credit. I speak from experience. I spent five years frustrated with a JavaFX font bug, but it was only when I could properly format a report and include images that I bothered to open this issue: Reduce color fringes in FreeType subpixel rendering https://github.com/javafxports/openjdk-jfx/issues/229 Formatting and images shouldn't matter, but two other people tried to report that bug using the Oracle Web form, and both were closed as "Not an Issue." You can send images later by e-mail, eventually, but that's not explained anywhere. There was a brief window when the OpenJFX project accepted bug reports on GitHub, but now it's back to the Oracle Web form. That brief window is the reason I'm a contributor to the project now. I understand the need for gate-keeping. We just shouldn't be too surprised when people decide that the gate's too high. I think Oracle could fix the two problems and keep the Web form, and we might get more quality bug reports instead of frustrated blog posts. I also think that it would help a lot to enable the JIRA markup[1] in the Java Bug System as Apache NetBeans has done. As an example, I can't imagine trying to report a bug like the following without formatting or in-line images: Attaching JavaFX Javadoc and Sources https://issues.apache.org/jira/browse/NETBEANS-3296 John [1] https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all From philip.race at oracle.com Fri Mar 19 19:37:04 2021 From: philip.race at oracle.com (Philip Race) Date: Fri, 19 Mar 2021 12:37:04 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> Message-ID: Interesting that there's no way to add an attachment (image or otherwise). I'll ask why that can't be made possible. I'm surprised credit is considered important but I think that the current way of doing things is more focused on protecting privacy of bug reporters and that they might instead want their email addresses advertised will quickly run into problems getting past that. There's even an assurance on the bug submission form that your personal info won't be shared. But FX never used the github bug tracker. It should never have been possible to submit bugs there. -phil. On 3/19/21 12:23 PM, John Neffenger wrote: > On 3/19/21 11:05 AM, Philip Race wrote: >> If this was important to him I don't understand why just a blog post >> and not a bug report .. > > If I had to guess, it might be because, in the age of GitHub, this is > not what people expect when they try to report a bug: > > Report a Bug or Request a Feature > https://bugreport.java.com/bugreport/ > > There are two main problems: > > 1. You can't attach images. > > 2. You don't get credit. > > I speak from experience. I spent five years frustrated with a JavaFX > font bug, but it was only when I could properly format a report and > include images that I bothered to open this issue: > > Reduce color fringes in FreeType subpixel rendering > https://github.com/javafxports/openjdk-jfx/issues/229 > > Formatting and images shouldn't matter, but two other people tried to > report that bug using the Oracle Web form, and both were closed as > "Not an Issue." You can send images later by e-mail, eventually, but > that's not explained anywhere. > > There was a brief window when the OpenJFX project accepted bug reports > on GitHub, but now it's back to the Oracle Web form. That brief window > is the reason I'm a contributor to the project now. I understand the > need for gate-keeping. We just shouldn't be too surprised when people > decide that the gate's too high. > > I think Oracle could fix the two problems and keep the Web form, and > we might get more quality bug reports instead of frustrated blog > posts. I also think that it would help a lot to enable the JIRA > markup[1] in the Java Bug System as Apache NetBeans has done. As an > example, I can't imagine trying to report a bug like the following > without formatting or in-line images: > > Attaching JavaFX Javadoc and Sources > https://issues.apache.org/jira/browse/NETBEANS-3296 > > John > > [1] > https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all From john at status6.com Fri Mar 19 19:47:32 2021 From: john at status6.com (John Neffenger) Date: Fri, 19 Mar 2021 12:47:32 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> Message-ID: On 3/19/21 12:37 PM, Philip Race wrote: > I'm surprised credit is considered important It took me weeks to figure out some bugs and create a good report, all done as a volunteer in my spare time. Credit is my only compensation. I went as far as sneaking my name into the source code comments just to have it show up somewhere in the report where it wouldn't be removed. > But FX never used the github bug tracker. It should never have been > possible to submit bugs there. Oh, but it did! https://github.com/javafxports/openjdk-jfx/issues John From kevin.rushforth at oracle.com Fri Mar 19 20:12:54 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 13:12:54 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> Message-ID: <80f556a6-74d6-85d0-26e9-c7016116bc5d@oracle.com> When we were using the GitHub sandbox, we would periodically look at the GitHub issue tracker there, although it was made clear that the bug still needed to be submitted to bugreport.java.com before it was actionable. It really is too bad, though that the bugs submission is effectively a "write one" communication channel, other than when the folks who manage that ask for more information, or it comes up on the openjfx-dev list. This isn't specific to JavaFX, and I think they are looking to improve the submission process, but I don't know what form that will take. -- Kevin On 3/19/2021 12:37 PM, Philip Race wrote: > Interesting that there's no way to add an attachment (image or > otherwise). > I'll ask why that can't be made possible. > > I'm surprised credit is considered important but I think that the > current way of doing things is > more focused on protecting privacy of bug reporters and that they > might instead want their email addresses advertised > will quickly run into problems getting past that. > There's even an assurance on the bug submission form that your > personal info won't be shared. > > But FX never used the github bug tracker. It should never have been > possible to submit bugs there. > > > -phil. > > On 3/19/21 12:23 PM, John Neffenger wrote: >> On 3/19/21 11:05 AM, Philip Race wrote: >>> If this was important to him I don't understand why just a blog post >>> and not a bug report .. >> >> If I had to guess, it might be because, in the age of GitHub, this is >> not what people expect when they try to report a bug: >> >> Report a Bug or Request a Feature >> https://bugreport.java.com/bugreport/ >> >> There are two main problems: >> >> 1. You can't attach images. >> >> 2. You don't get credit. >> >> I speak from experience. I spent five years frustrated with a JavaFX >> font bug, but it was only when I could properly format a report and >> include images that I bothered to open this issue: >> >> Reduce color fringes in FreeType subpixel rendering >> https://github.com/javafxports/openjdk-jfx/issues/229 >> >> Formatting and images shouldn't matter, but two other people tried to >> report that bug using the Oracle Web form, and both were closed as >> "Not an Issue." You can send images later by e-mail, eventually, but >> that's not explained anywhere. >> >> There was a brief window when the OpenJFX project accepted bug >> reports on GitHub, but now it's back to the Oracle Web form. That >> brief window is the reason I'm a contributor to the project now. I >> understand the need for gate-keeping. We just shouldn't be too >> surprised when people decide that the gate's too high. >> >> I think Oracle could fix the two problems and keep the Web form, and >> we might get more quality bug reports instead of frustrated blog >> posts. I also think that it would help a lot to enable the JIRA >> markup[1] in the Java Bug System as Apache NetBeans has done. As an >> example, I can't imagine trying to report a bug like the following >> without formatting or in-line images: >> >> Attaching JavaFX Javadoc and Sources >> https://issues.apache.org/jira/browse/NETBEANS-3296 >> >> John >> >> [1] >> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all > From kcr at openjdk.java.net Fri Mar 19 21:04:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Mar 2021 21:04:42 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: Message-ID: On Mon, 8 Feb 2021 07:04:05 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with three additional commits since the last revision: > > - Merge remote-tracking branch > - Speculative fix for Mac > - Fixed shader field name Finally getting back to this. There is an outstanding API question regarding the direction vector: Should the transforms of the SpotLight node to scene coordinates affect the direction vector (e.g., such that a rotation would rotate the direction the spotlight is pointing)? If so, do we even need the direction vector or could we define the direction as `(0,0,1)` in the local coordinates of the SpotLight, and tell applications to apply the appropriate rotation to define the direction. I think for consistency, the answer is "Yes" to the first question (that's how the position works and it would be odd for the transform to affect the position and not the direction). I'm less certain about the answer to the second question. Without utility functions like `lookAt` to help compute the appropriate transform, it seems important to be able to specify the direction as an explicit parameter. And even if we had utility functions, an app might want the control (although you might argue it would be unneeded). My instinct is to keep it as defined. If we go with this, the only change that is needed is a note that the transforms applied to the SpotLight node affect it's direction as well as its position. Implementation: Can you add a system test similar to what you did for attenuation to verify the basic functionality? I tested this a bit on Windows using D3D and it behaves as I would expect, although I didn't do exhaustive testing. On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. The falloff happens too fast (at 1 you can't see the light at all). For the inner/outer angles, something looks backwards. See the attached image SpotLight-macOS I left a few inline comments, although I haven't reviewed the shader files in detail yet. modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 514: > 512: /* > 513: * Class: com_sun_prism_d3d_D3DContext > 514: * Method: nSetSpotLight Typo: `nSetSpotLight` --> `nSetLight` modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 523: > 521: jfloat dirX, jfloat dirY, jfloat dirZ, jfloat innerAngle, jfloat outerAngle, jfloat falloff) > 522: { > 523: TraceLn(NWT_TRACE_INFO, "D3DContext_nSetSpotLight"); Typo: `D3DContext_nSetSpotLight` `D3DContext_nSetLight` modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.h line 47: > 45: float r, float g, float b, float w, > 46: float ca, float la, float qa, float maxRange, > 47: float dirX, float dirY, float firZ, Typo: `firZ` --> `dirZ` tests/performance/3DLighting/attenuation/Environment.java line 26: > 24: */ > 25: > 26: package attenTest; Revert this (else it won't compile) tests/performance/3DLighting/attenuation/FPSCounter.java line 26: > 24: */ > 25: > 26: package attenTest; Revert this (else it won't compile) tests/performance/3DLighting/attenuation/LightingSample.java line 26: > 24: */ > 25: > 26: package attenTest; Revert this (else it won't compile) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From michaelstrau2 at gmail.com Fri Mar 19 22:02:57 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 19 Mar 2021 23:02:57 +0100 Subject: Consistent baseline layout algorithm Message-ID: Trying to use baseline alignment in JavaFX can be pretty hard to get right. For example: put some shape and a label into a layout container, and the container's baseline might not reflect what you would intuitively assume (which is the text baseline). In fact, most layout containers just take the first child that reports a baseline other than the special constant BASELINE_OFFSET_SAME_AS_HEIGHT and use that as the baseline for the entire container. Since there is no meaningful baseline if the first child is not a text node, the layout container won't neatly align with other kinds of text or text composites. Another issue is that the baseline offset of a resizable node depends on the height of the node, but the height of the node also depends on the baseline offset. This circular dependency is currently unaccounted for in controls such as Labeled (that's the reason for bugs like JDK-809261). I've prepared a PR that makes working with baseline alignments easier and more consistent, and also solves the circular dependency problem by introducing a multi-pass layout algorithm. The PR includes before-and-after images that help visualize the problem and the proposed solution. Here's the PR: https://github.com/openjdk/jfx/pull/433 From kevin.rushforth at oracle.com Fri Mar 19 22:25:42 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Mar 2021 15:25:42 -0700 Subject: Consistent baseline layout algorithm In-Reply-To: References: Message-ID: <7de4d41d-e341-0b6d-2e54-15c5b905c383@oracle.com> I'd be interested to hear from app developers on this list. Here are a few quick thoughts I have. As you note, this is a long-standing problem with layout in FX. You mention in the performance considerations that for most cases this will iterate quickly. It would be interesting to know what some of the corner cases are, so we can see how bad the pathological case will be. I see that you propose to iterate up to 100 times. Maybe a lower threshold would be better? We already run layout passes 3 times in many cases. So also running 3 (or maybe 4 or 5) times seems reasonable, especially when your testing shows that most of the time it converges in <= 2 passes. So a smaller threshold than 100 would seem to make sense. If a control doesn't converge, you might consider logging it (in case an app developer wants to debug it) perhaps at a "fine" level so it isn't shown by default. How do you propose to document this behavioral change -- not so much the fact that it will (usually) get the right answer now instead of the wrong one, but more about the multi-pass nature of it, and the fact that nodes with text will be "preferred". Related to that, how necessary is a new public API on Node? -- Kevin On 3/19/2021 3:02 PM, Michael Strau? wrote: > Trying to use baseline alignment in JavaFX can be pretty hard to get > right. For example: put some shape and a label into a layout > container, and the container's baseline might not reflect what you > would intuitively assume (which is the text baseline). In fact, most > layout containers just take the first child that reports a baseline > other than the special constant BASELINE_OFFSET_SAME_AS_HEIGHT and use > that as the baseline for the entire container. > > Since there is no meaningful baseline if the first child is not a text > node, the layout container won't neatly align with other kinds of text > or text composites. > > Another issue is that the baseline offset of a resizable node depends > on the height of the node, but the height of the node also depends on > the baseline offset. This circular dependency is currently unaccounted > for in controls such as Labeled (that's the reason for bugs like > JDK-809261). > > I've prepared a PR that makes working with baseline alignments easier > and more consistent, and also solves the circular dependency problem > by introducing a multi-pass layout algorithm. The PR includes > before-and-after images that help visualize the problem and the > proposed solution. > > Here's the PR: https://github.com/openjdk/jfx/pull/433 From jvos at openjdk.java.net Sat Mar 20 11:58:51 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 20 Mar 2021 11:58:51 GMT Subject: RFR: 8263778: Fix monocle JNI signatures for instance methods Message-ID: <48ITQ0FBcZJU9DRXhCCYCeMRakoBAGD_I1vNIXRpIPk=.e609e911-38d6-424d-9455-157c218816f8@github.com> Fix signatures (jclass/jobject), add UNUSED when unused Fix for JDK-8263778 The monocle/egl native code now includes the javac generated header file UNUSED() directives are used when a parameter is not used jobject/jclass are used when expected. ------------- Commit messages: - Fix signatures (jclass/jobject), add UNUSED when unused Changes: https://git.openjdk.java.net/jfx/pull/435/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=435&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263778 Stats: 22 lines in 1 file changed: 2 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/435.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/435/head:pull/435 PR: https://git.openjdk.java.net/jfx/pull/435 From kcr at openjdk.java.net Sat Mar 20 12:52:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Mar 2021 12:52:40 GMT Subject: RFR: 8263778: Fix monocle JNI signatures for instance methods In-Reply-To: <48ITQ0FBcZJU9DRXhCCYCeMRakoBAGD_I1vNIXRpIPk=.e609e911-38d6-424d-9455-157c218816f8@github.com> References: <48ITQ0FBcZJU9DRXhCCYCeMRakoBAGD_I1vNIXRpIPk=.e609e911-38d6-424d-9455-157c218816f8@github.com> Message-ID: On Sat, 20 Mar 2021 11:53:21 GMT, Johan Vos wrote: > Fix signatures (jclass/jobject), add UNUSED when unused > Fix for JDK-8263778 > > The monocle/egl native code now includes the javac generated header file > UNUSED() directives are used when a parameter is not used > jobject/jclass are used when expected. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/435 From kcr at openjdk.java.net Sat Mar 20 13:14:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Mar 2021 13:14:40 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v3] In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 08:22:06 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor typos + make verbose print less verbose > > The fix and Sanity testing looks all good. > I shall need some more time to do a detailed review. > Added minor comments, please address whenever you update next commit. Deleted comment meant for another PR... ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Sat Mar 20 13:14:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Mar 2021 13:14:39 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport In-Reply-To: References: Message-ID: <4ne2j1FAVj78R61qHlfdYrj8pyxCU1933iU4oUOKV8Y=.7852666e-9997-43bf-b66d-58cbec9c9d21@github.com> On Thu, 18 Mar 2021 12:32:50 GMT, Ambarish Rapte wrote: >> Is there a unit test that can validate this fix? > >> Is there a unit test that can validate this fix? > > I have added a unit test using a new shim class. Test verifies size of the map that is added as part of this fix. > So the test won't compile without this PR. The new unit test fails on all platforms, as you can see from the GitHub actions log: 2021-03-18T12:45:36.7904530Z test.javafx.scene.control.ControlAcceleratorSupportTest > sanityTestListenerMapShouldBeEmpty FAILED 2021-03-18T12:45:36.8007000Z java.lang.AssertionError: expected:<0> but was:<22> 2021-03-18T12:45:36.8099570Z at org.junit.Assert.fail(Assert.java:91) 2021-03-18T12:45:36.8201200Z at org.junit.Assert.failNotEquals(Assert.java:645) 2021-03-18T12:45:36.8264450Z at org.junit.Assert.assertEquals(Assert.java:126) 2021-03-18T12:45:36.8366120Z at org.junit.Assert.assertEquals(Assert.java:470) 2021-03-18T12:45:36.8455230Z at org.junit.Assert.assertEquals(Assert.java:454) 2021-03-18T12:45:36.8559230Z at test.javafx.scene.control.ControlAcceleratorSupportTest.sanityTestListenerMapShouldBeEmpty(ControlAcceleratorSupportTest.java:43) 2021-03-18T12:45:36.8886110Z 2021-03-18T12:45:36.8989430Z test.javafx.scene.control.ControlAcceleratorSupportTest > testNumberOfListenersByRemovingAndAddingMenuItems FAILED 2021-03-18T12:45:36.9092540Z java.lang.AssertionError: expected:<4> but was:<26> 2021-03-18T12:45:36.9194300Z at org.junit.Assert.fail(Assert.java:91) 2021-03-18T12:45:36.9296390Z at org.junit.Assert.failNotEquals(Assert.java:645) 2021-03-18T12:45:36.9393550Z at org.junit.Assert.assertEquals(Assert.java:126) 2021-03-18T12:45:36.9495860Z at org.junit.Assert.assertEquals(Assert.java:470) 2021-03-18T12:45:36.9596430Z at org.junit.Assert.assertEquals(Assert.java:454) 2021-03-18T12:45:36.9700420Z at test.javafx.scene.control.ControlAcceleratorSupportTest.testNumberOfListenersByRemovingAndAddingMenuItems(ControlAcceleratorSupportTest.java:65) ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From nlisker at openjdk.java.net Sat Mar 20 13:31:00 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 20 Mar 2021 13:31:00 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v10] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'nlisker/8234920_Add_SpotLight_to_the_selection_of_3D_light_types' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types - Addressed review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/d1bc9af5..39dc40cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=08-09 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From kevin.rushforth at oracle.com Sat Mar 20 13:31:58 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 20 Mar 2021 06:31:58 -0700 Subject: Building OpenJFX locally In-Reply-To: References: Message-ID: <68d724fb-bc05-0fb1-435f-ec0af362c1b5@oracle.com> This reminds me that after the fix for JDK-8255713 [1] it is no longer necessary (or recommended) to set the MSVC_VER env variable. I updated the Wiki to reflect that, and also to reflect that we now build using Visual Studio 2019 (although it will still work with VS 2017). -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8255713 On 3/19/2021 8:11 AM, Nir Lisker wrote: > Did you go through > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX? Where what > error do you get at which step? > > On Thu, Mar 18, 2021 at 4:12 PM Jacky Guo wrote: > >> Hi there, >> I've cloned OpenJFX locally, but I can't build it, because I need to define >> the environment variable WINSDK_DIR. What do I need to set this to and what >> do I need to put in that folder >> >> Thanks! >> - Jacky Guo >> >> P.S. I only have Windows on a laptop, so I don't know how I can test for >> Linux and/or MacOS. >> From kcr at openjdk.java.net Sat Mar 20 13:40:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Mar 2021 13:40:51 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: References: Message-ID: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review comments to fix typo in comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/430/files - new: https://git.openjdk.java.net/jfx/pull/430/files/11e609c6..7d3a09ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=430&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/430/head:pull/430 PR: https://git.openjdk.java.net/jfx/pull/430 From michaelstrau2 at gmail.com Sat Mar 20 13:42:50 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 20 Mar 2021 14:42:50 +0100 Subject: Consistent baseline layout algorithm In-Reply-To: <7de4d41d-e341-0b6d-2e54-15c5b905c383@oracle.com> References: <7de4d41d-e341-0b6d-2e54-15c5b905c383@oracle.com> Message-ID: 1) Pathological cases: So far, I haven't been able to produce pathological cases that exceed 3 layout passes by using standard layout containers and controls. If we need to have a threshold substantially higher than that depends on whether or not there are indeed legitimate cases where some kind of layout requires more passes to converge. Maybe we could log at a very fine level when a control takes more than 3 passes to converge, but still continue processing up to a substantially higher number of passes. This would allow developers to debug and optimize their custom controls, but still produce a valid solution if a particular control is generally stable, but just very poorly optimized. 2) I believe that the multi-pass layout algorithm shouldn't need additional documentation since it could be considered an implementation detail. There is no 1:1 correspondence between pulses and layout passes currently, and there won't be with the new algorithm. Also, any layout pass with the current algorithm can potentially trigger another layout pass, so that's not fundamentally different either. For control authors, we might need to document that it is generally okay to rely on circular dependencies between size hints, baseline offset and child nodes, as long as those dependencies allow the layout to settle. The fact that text nodes are preferred with respect to baseline computation is documented in Parent.getBaselineOffset(), maybe Node.getBaselineOffset() should also mention this. We might also add a section on baseline computation to the javafx.scene.layout package documentation, where I think it is most relevant (and currently entirely undocumented). 3) New API on Node: in order for this idea to work, there needs to be an abstract concept of "text node". Since the "baseline" concept is introduced on Node, I thought this would also be the appropriate place to introduce the "text node" concept; however, it could also be introduced on Parent instead. Note that the "text node" concept is introduced at a lower level than actual text controls like Labeled, because layout containers (which are not controls) need this information. Also, the definition of what constitutes "text" is left to control authors. In a very contrived example, a control might display an image, but declare itself to be "text". Am Fr., 19. M?rz 2021 um 23:26 Uhr schrieb Kevin Rushforth : > > I'd be interested to hear from app developers on this list. > > Here are a few quick thoughts I have. > > As you note, this is a long-standing problem with layout in FX. You > mention in the performance considerations that for most cases this will > iterate quickly. It would be interesting to know what some of the corner > cases are, so we can see how bad the pathological case will be. I see > that you propose to iterate up to 100 times. Maybe a lower threshold > would be better? We already run layout passes 3 times in many cases. So > also running 3 (or maybe 4 or 5) times seems reasonable, especially when > your testing shows that most of the time it converges in <= 2 passes. So > a smaller threshold than 100 would seem to make sense. If a control > doesn't converge, you might consider logging it (in case an app > developer wants to debug it) perhaps at a "fine" level so it isn't shown > by default. > > How do you propose to document this behavioral change -- not so much the > fact that it will (usually) get the right answer now instead of the > wrong one, but more about the multi-pass nature of it, and the fact that > nodes with text will be "preferred". Related to that, how necessary is a > new public API on Node? > > -- Kevin > From ebresie at gmail.com Sat Mar 20 14:20:18 2021 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 20 Mar 2021 09:20:18 -0500 Subject: Not really a nice comment but a real issue? In-Reply-To: fbcc0a01-c42d-e0d3-af83-49cc804c3a4f@status6.com References: CAAEud6ZOKpz+k2-=msvBv9rBCTvE-ezYp_JV+YU6B-6NwUHf6w@mail.gmail.com 7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM 97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com d19bd126-269f-7186-eb50-3a1e56106e5b@oracle.com FBC10E06-53CF-4D12-A1B8-0FB65E1D6E6C@gmail.com a72f4816-7e0d-3d8d-afdf-6aa90e8ef993@oracle.com 92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com a1086ddf-071d-930d-3c43-011e700a92d7@oracle.com a1086ddf-071d-930d-3c43-011e700a92d7@oracle.com Message-ID: <69290378-0fed-4135-858c-50a2adf2a378@Erics-iPhone-12-Pro-Max> Just scanning the javafx ports/openjfx GitHub repository listed below, there appears to have been over 650 GitHub issues raised (and still growing). Some I see labeled as ?bugs? but what about all the others? It looks that the port project has basically indicated moved to the official https://github.com/openjdk/jfx which no longer allows issues to be raised there like the port version. But that said what about all those issues on the port repository? Does raising issue on that need to be disable maybe? Or would allowing issues on the official repository be good in some way? Is it possible to ?mirror? the ticket on GitHub to create an official one in the official Java bug tracking? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On March 19, 2021 at 2:47:32 PM CDT, John Neffenger wrote: > On 3/19/21 12:37 PM, Philip Race wrote: > > I'm surprised credit is considered important > > It took me weeks to figure out some bugs and create a good report, all > done as a volunteer in my spare time. Credit is my only compensation. > > I went as far as sneaking my name into the source code comments just to > have it show up somewhere in the report where it wouldn't be removed. > > > But FX never used the github bug tracker. It should never have been > > possible to submit bugs there. > > Oh, but it did! > > https://github.com/javafxports/openjdk-jfx/issues > > John From pedro.duquevieira at gmail.com Sat Mar 20 14:37:09 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 20 Mar 2021 14:37:09 +0000 Subject: Not really a nice comment but a real issue? Message-ID: Back to the discussion on why did the blog poster not raise an issue for the problems he mentioned... Just FYI (in case you didn't see his recents comments), it appears he did. He says he did it in a recent comment on his blog post (yesterday): https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 . He says he filed an issue in 2014. Cheers, -- Pedro Duque Vieira - https://www.pixelduke.com From guy.abossolo.foh at scientificware.com Sat Mar 20 15:16:31 2021 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 20 Mar 2021 16:16:31 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> Message-ID: <130beff3c06682f5cfe31473b6e9cb89@scientificware.com> > I'm surprised credit is considered important ... . You're right, but for some of your external contributors it's a business model useful to communicate with their employers or patrons. I tried to explain it in a Twitter post but without success :) GitHub is like a vitrine where one can see the community working. To be credited in the reprository is personnal satisfaction but it's also like receiving "java-coins", a win-win strategy without additional work from the owner since a gauge shows each contributor activity. > But FX never used the github bug tracker. ... https://github.com/javafxports/openjdk-jfx, did. A really amazing experience ! The new repository closed this first open window :( Guy. ------------------------------------------------------------------------------ Le 2021-03-19 20:37, Philip Race a ?crit?: > Interesting that there's no way to add an attachment (image or > otherwise). > I'll ask why that can't be made possible. > > I'm surprised credit is considered important but I think that the > current way of doing things is > more focused on protecting privacy of bug reporters and that they > might instead want their email addresses advertised > will quickly run into problems getting past that. > There's even an assurance on the bug submission form that your > personal info won't be shared. > > But FX never used the github bug tracker. It should never have been > possible to submit bugs there. > > > -phil. > > On 3/19/21 12:23 PM, John Neffenger wrote: >> On 3/19/21 11:05 AM, Philip Race wrote: >>> If this was important to him I don't understand why just a blog post >>> and not a bug report .. >> >> If I had to guess, it might be because, in the age of GitHub, this is >> not what people expect when they try to report a bug: >> >> Report a Bug or Request a Feature >> https://bugreport.java.com/bugreport/ >> >> There are two main problems: >> >> 1. You can't attach images. >> >> 2. You don't get credit. >> >> I speak from experience. I spent five years frustrated with a JavaFX >> font bug, but it was only when I could properly format a report and >> include images that I bothered to open this issue: >> >> Reduce color fringes in FreeType subpixel rendering >> https://github.com/javafxports/openjdk-jfx/issues/229 >> >> Formatting and images shouldn't matter, but two other people tried to >> report that bug using the Oracle Web form, and both were closed as >> "Not an Issue." You can send images later by e-mail, eventually, but >> that's not explained anywhere. >> >> There was a brief window when the OpenJFX project accepted bug reports >> on GitHub, but now it's back to the Oracle Web form. That brief window >> is the reason I'm a contributor to the project now. I understand the >> need for gate-keeping. We just shouldn't be too surprised when people >> decide that the gate's too high. >> >> I think Oracle could fix the two problems and keep the Web form, and >> we might get more quality bug reports instead of frustrated blog >> posts. I also think that it would help a lot to enable the JIRA >> markup[1] in the Java Bug System as Apache NetBeans has done. As an >> example, I can't imagine trying to report a bug like the following >> without formatting or in-line images: >> >> Attaching JavaFX Javadoc and Sources >> https://issues.apache.org/jira/browse/NETBEANS-3296 >> >> John >> >> [1] >> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all From jvos at openjdk.java.net Sat Mar 20 16:39:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 20 Mar 2021 16:39:43 GMT Subject: Integrated: 8263778: Fix monocle JNI signatures for instance methods In-Reply-To: <48ITQ0FBcZJU9DRXhCCYCeMRakoBAGD_I1vNIXRpIPk=.e609e911-38d6-424d-9455-157c218816f8@github.com> References: <48ITQ0FBcZJU9DRXhCCYCeMRakoBAGD_I1vNIXRpIPk=.e609e911-38d6-424d-9455-157c218816f8@github.com> Message-ID: <6d2PZGYwEZ6D4ul_nYsp1RbPgT66Rs6oaCehpleC8Tw=.8acc2719-6f53-4ddd-b2e4-7631af8ea4e6@github.com> On Sat, 20 Mar 2021 11:53:21 GMT, Johan Vos wrote: > Fix signatures (jclass/jobject), add UNUSED when unused > Fix for JDK-8263778 > > The monocle/egl native code now includes the javac generated header file > UNUSED() directives are used when a parameter is not used > jobject/jclass are used when expected. This pull request has now been integrated. Changeset: d4d57fb1 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/d4d57fb1 Stats: 22 lines in 1 file changed: 2 ins; 0 del; 20 mod 8263778: Fix monocle JNI signatures for instance methods Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/435 From philip.race at oracle.com Sat Mar 20 17:12:07 2021 From: philip.race at oracle.com (Philip Race) Date: Sat, 20 Mar 2021 10:12:07 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: Actually the way I read it, Scott Palmer added a comment with a link to the 2014 change that *introduced* the problem. No one is saying they reported this performance issue in 2014. -phil. On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: > Back to the discussion on why did the blog poster not raise an issue > for the problems he mentioned... > > Just FYI (in case you didn't see his recents comments), it appears he > did. He says he did it in a recent?comment on his blog post > (yesterday): > https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 > . > He says he filed an issue in 2014. > > Cheers, > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From philip.race at oracle.com Sat Mar 20 17:13:32 2021 From: philip.race at oracle.com (Philip Race) Date: Sat, 20 Mar 2021 10:13:32 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: <130beff3c06682f5cfe31473b6e9cb89@scientificware.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <130beff3c06682f5cfe31473b6e9cb89@scientificware.com> Message-ID: <0a7a82f0-43b0-c20f-3358-8f889ff60c38@oracle.com> Oracle has a very different mind set about privacy than Google or Facebook. It might be very hard to convince the powers that be to add a "please sell my personal information" checkbox .. -phil. On 3/20/21 8:16 AM, Abossolo Foh Guy wrote: >> I'm surprised credit is considered important ... . > > You're right, but for some of your external contributors it's a > business model useful to communicate with their employers or patrons. > I tried to explain it in a Twitter post but without success :) GitHub > is like a vitrine where one can see the community working. To be > credited in the reprository is personnal satisfaction but it's also > like receiving "java-coins", a win-win strategy without additional > work from the owner since a gauge shows each contributor activity. > >> But FX never used the github bug tracker. ... > https://github.com/javafxports/openjdk-jfx, did. A really amazing > experience ! The new repository closed this first open window :( > > Guy. > > ------------------------------------------------------------------------------ > > > Le 2021-03-19 20:37, Philip Race a ?crit?: >> Interesting that there's no way to add an attachment (image or >> otherwise). >> I'll ask why that can't be made possible. >> >> I'm surprised credit is considered important but I think that the >> current way of doing things is >> more focused on protecting privacy of bug reporters and that they >> might instead want their email addresses advertised >> will quickly run into problems getting past that. >> There's even an assurance on the bug submission form that your >> personal info won't be shared. >> >> But FX never used the github bug tracker. It should never have been >> possible to submit bugs there. >> >> >> -phil. >> >> On 3/19/21 12:23 PM, John Neffenger wrote: >>> On 3/19/21 11:05 AM, Philip Race wrote: >>>> If this was important to him I don't understand why just a blog >>>> post and not a bug report .. >>> >>> If I had to guess, it might be because, in the age of GitHub, this >>> is not what people expect when they try to report a bug: >>> >>> Report a Bug or Request a Feature >>> https://bugreport.java.com/bugreport/ >>> >>> There are two main problems: >>> >>> 1. You can't attach images. >>> >>> 2. You don't get credit. >>> >>> I speak from experience. I spent five years frustrated with a JavaFX >>> font bug, but it was only when I could properly format a report and >>> include images that I bothered to open this issue: >>> >>> Reduce color fringes in FreeType subpixel rendering >>> https://github.com/javafxports/openjdk-jfx/issues/229 >>> >>> Formatting and images shouldn't matter, but two other people tried >>> to report that bug using the Oracle Web form, and both were closed >>> as "Not an Issue." You can send images later by e-mail, eventually, >>> but that's not explained anywhere. >>> >>> There was a brief window when the OpenJFX project accepted bug >>> reports on GitHub, but now it's back to the Oracle Web form. That >>> brief window is the reason I'm a contributor to the project now. I >>> understand the need for gate-keeping. We just shouldn't be too >>> surprised when people decide that the gate's too high. >>> >>> I think Oracle could fix the two problems and keep the Web form, and >>> we might get more quality bug reports instead of frustrated blog >>> posts. I also think that it would help a lot to enable the JIRA >>> markup[1] in the Java Bug System as Apache NetBeans has done. As an >>> example, I can't imagine trying to report a bug like the following >>> without formatting or in-line images: >>> >>> Attaching JavaFX Javadoc and Sources >>> https://issues.apache.org/jira/browse/NETBEANS-3296 >>> >>> John >>> >>> [1] >>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all From pedro.duquevieira at gmail.com Sat Mar 20 17:36:53 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 20 Mar 2021 17:36:53 +0000 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: Hi Philip, Gary Bentley is the blog owner and author of the post. Scott Palmer is commenting on Gary Bentley's blog post. I was talking about Gary Bentley's comment to Scott Palmer's asking why he didn't file an issue. *Scott Palme*r: "*It?s Open Source? submit an issue and a pull request to at least fix the performance."* And Gary Bentley the author of the blog replied: *Gary Bentley*:"...*I did raise this issue at the time, I raised a bug.*" *. "...There is a rendering issue with WebView in 13+ versions that I also need to raise."* Cheers, On Sat, Mar 20, 2021 at 5:12 PM Philip Race wrote: > Actually the way I read it, Scott Palmer added a comment with a link to > the 2014 change that *introduced* the problem. > No one is saying they reported this performance issue in 2014. > > -phil. > > On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: > > Back to the discussion on why did the blog poster not raise an issue for > the problems he mentioned... > > Just FYI (in case you didn't see his recents comments), it appears he did. > He says he did it in a recent comment on his blog post (yesterday): > https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 > . > He says he filed an issue in 2014. > > Cheers, > > > -- > Pedro Duque Vieira - https://www.pixelduke.com > > > -- Pedro Duque Vieira - https://www.pixelduke.com From michaelstrau2 at gmail.com Sat Mar 20 17:41:33 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 20 Mar 2021 18:41:33 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: <0a7a82f0-43b0-c20f-3358-8f889ff60c38@oracle.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <130beff3c06682f5cfe31473b6e9cb89@scientificware.com> <0a7a82f0-43b0-c20f-3358-8f889ff60c38@oracle.com> Message-ID: OpenJFX just doesn't feel like a community-driven project, in a large part because of how contributors are told to "report" an issue to Oracle. That's what you do as a customer, not as a contributor. Contributors want to discuss issues and share their findings, and a mailing list really is no substitute for an openly accessible issue tracker like GitHub. At this point in time and with the severely understaffed situation of the OpenJFX project, I think fully embracing GitHub and moving issue tracking and discussions over there would benefit the project tremendously. Am Sa., 20. M?rz 2021 um 18:13 Uhr schrieb Philip Race : > > Oracle has a very different mind set about privacy than Google or Facebook. > It might be very hard to convince the powers that be to add a "please > sell my personal information" checkbox .. > > -phil. > > On 3/20/21 8:16 AM, Abossolo Foh Guy wrote: > >> I'm surprised credit is considered important ... . > > > > You're right, but for some of your external contributors it's a > > business model useful to communicate with their employers or patrons. > > I tried to explain it in a Twitter post but without success :) GitHub > > is like a vitrine where one can see the community working. To be > > credited in the reprository is personnal satisfaction but it's also > > like receiving "java-coins", a win-win strategy without additional > > work from the owner since a gauge shows each contributor activity. > > > >> But FX never used the github bug tracker. ... > > https://github.com/javafxports/openjdk-jfx, did. A really amazing > > experience ! The new repository closed this first open window :( > > > > Guy. > > > > ------------------------------------------------------------------------------ > > > > > > Le 2021-03-19 20:37, Philip Race a ?crit : > >> Interesting that there's no way to add an attachment (image or > >> otherwise). > >> I'll ask why that can't be made possible. > >> > >> I'm surprised credit is considered important but I think that the > >> current way of doing things is > >> more focused on protecting privacy of bug reporters and that they > >> might instead want their email addresses advertised > >> will quickly run into problems getting past that. > >> There's even an assurance on the bug submission form that your > >> personal info won't be shared. > >> > >> But FX never used the github bug tracker. It should never have been > >> possible to submit bugs there. > >> > >> > >> -phil. > >> > >> On 3/19/21 12:23 PM, John Neffenger wrote: > >>> On 3/19/21 11:05 AM, Philip Race wrote: > >>>> If this was important to him I don't understand why just a blog > >>>> post and not a bug report .. > >>> > >>> If I had to guess, it might be because, in the age of GitHub, this > >>> is not what people expect when they try to report a bug: > >>> > >>> Report a Bug or Request a Feature > >>> https://bugreport.java.com/bugreport/ > >>> > >>> There are two main problems: > >>> > >>> 1. You can't attach images. > >>> > >>> 2. You don't get credit. > >>> > >>> I speak from experience. I spent five years frustrated with a JavaFX > >>> font bug, but it was only when I could properly format a report and > >>> include images that I bothered to open this issue: > >>> > >>> Reduce color fringes in FreeType subpixel rendering > >>> https://github.com/javafxports/openjdk-jfx/issues/229 > >>> > >>> Formatting and images shouldn't matter, but two other people tried > >>> to report that bug using the Oracle Web form, and both were closed > >>> as "Not an Issue." You can send images later by e-mail, eventually, > >>> but that's not explained anywhere. > >>> > >>> There was a brief window when the OpenJFX project accepted bug > >>> reports on GitHub, but now it's back to the Oracle Web form. That > >>> brief window is the reason I'm a contributor to the project now. I > >>> understand the need for gate-keeping. We just shouldn't be too > >>> surprised when people decide that the gate's too high. > >>> > >>> I think Oracle could fix the two problems and keep the Web form, and > >>> we might get more quality bug reports instead of frustrated blog > >>> posts. I also think that it would help a lot to enable the JIRA > >>> markup[1] in the Java Bug System as Apache NetBeans has done. As an > >>> example, I can't imagine trying to report a bug like the following > >>> without formatting or in-line images: > >>> > >>> Attaching JavaFX Javadoc and Sources > >>> https://issues.apache.org/jira/browse/NETBEANS-3296 > >>> > >>> John > >>> > >>> [1] > >>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=all > From philip.race at oracle.com Sat Mar 20 18:54:42 2021 From: philip.race at oracle.com (Philip Race) Date: Sat, 20 Mar 2021 11:54:42 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: Ah, I missed that. And with that, I've now found Gary's bug : https://bugs.openjdk.java.net/browse/JDK-8239138 -phil. On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: > Hi Philip, > > Gary?Bentley is the blog owner and author of the post. Scott Palmer is > commenting on Gary Bentley's blog post. > I was talking about Gary Bentley's comment to Scott Palmer's asking > why he didn't file an issue. > > *Scott Palme*r: "/It?s Open Source? submit an issue and a pull request > to at least fix the performance."/ > And Gary Bentley the author of the blog replied: > *Gary Bentley*:".../I did raise this issue at the time, I raised a > bug./"/. > ? ? ? ? ? ? ? ? ? ? ? "...There is a rendering issue with WebView in > 13+ versions that I also need to raise."/ > > > Cheers, > > On Sat, Mar 20, 2021 at 5:12 PM Philip Race > wrote: > > Actually the way I read it, Scott Palmer added a comment with a > link to the 2014 change that *introduced* the problem. > No one is saying they reported this performance issue in 2014. > > -phil. > > On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >> Back to the discussion on why did the blog poster not raise an >> issue for the problems he mentioned... >> >> Just FYI (in case you didn't see his recents comments), it >> appears he did. He says he did it in a recent?comment on his blog >> post (yesterday): >> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >> . >> He says he filed an issue in 2014. >> >> Cheers, >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From philip.race at oracle.com Sat Mar 20 18:57:40 2021 From: philip.race at oracle.com (Philip Race) Date: Sat, 20 Mar 2021 11:57:40 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> It was a P4 enhancement. I've made it a bug .. this or the new one should be closed as a dup. Normally I'd close the new one but not so clear here. I'll leave it to Kevin to choose. -phil. On 3/20/21 11:54 AM, Philip Race wrote: > > Ah, I missed that. And with that, I've now found Gary's bug : > https://bugs.openjdk.java.net/browse/JDK-8239138 > > -phil. > > On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: >> Hi Philip, >> >> Gary?Bentley is the blog owner and author of the post. Scott Palmer >> is commenting on Gary Bentley's blog post. >> I was talking about Gary Bentley's comment to Scott Palmer's asking >> why he didn't file an issue. >> >> *Scott Palme*r: "/It?s Open Source? submit an issue and a pull >> request to at least fix the performance."/ >> And Gary Bentley the author of the blog replied: >> *Gary Bentley*:".../I did raise this issue at the time, I raised a >> bug./"/. >> ? ? ? ? ? ? ? ? ? ? ? "...There is a rendering issue with WebView in >> 13+ versions that I also need to raise."/ >> >> >> Cheers, >> >> On Sat, Mar 20, 2021 at 5:12 PM Philip Race > > wrote: >> >> Actually the way I read it, Scott Palmer added a comment with a >> link to the 2014 change that *introduced* the problem. >> No one is saying they reported this performance issue in 2014. >> >> -phil. >> >> On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >>> Back to the discussion on why did the blog poster not raise an >>> issue for the problems he mentioned... >>> >>> Just FYI (in case you didn't see his recents comments), it >>> appears he did. He says he did it in a recent?comment on his >>> blog post (yesterday): >>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >>> . >>> He says he filed an issue in 2014. >>> >>> Cheers, >>> >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com >>> >> >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> > From tbee at tbee.org Sat Mar 20 19:10:19 2021 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 20 Mar 2021 20:10:19 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> References: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> Message-ID: I could not refrain from commenting on the tone of the blog, in line with what Johan often complains about. Apparently you guys are stronger than me. But I was polite and kept it to myself. On 20-3-2021 19:57, Philip Race wrote: > It was a P4 enhancement. I've made it a bug .. this or the new one should be closed as a dup. > Normally I'd close the new one but not so clear here. I'll leave it to Kevin to choose. > > -phil. > > On 3/20/21 11:54 AM, Philip Race wrote: >> >> Ah, I missed that. And with that, I've now found Gary's bug : https://bugs.openjdk.java.net/browse/JDK-8239138 >> >> -phil. >> >> On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: >>> Hi Philip, >>> >>> Gary?Bentley is the blog owner and author of the post. Scott Palmer is commenting on Gary Bentley's blog post. >>> I was talking about Gary Bentley's comment to Scott Palmer's asking why he didn't file an issue. >>> >>> *Scott Palme*r: "/It?s Open Source? submit an issue and a pull request to at least fix the performance."/ >>> And Gary Bentley the author of the blog replied: >>> *Gary Bentley*:".../I did raise this issue at the time, I raised a bug./"/. >>> ? ? ? ? ? ? ? ? ? ? ? "...There is a rendering issue with WebView in 13+ versions that I also need to raise."/ >>> >>> >>> Cheers, >>> >>> On Sat, Mar 20, 2021 at 5:12 PM Philip Race > wrote: >>> >>> ??? Actually the way I read it, Scott Palmer added a comment with a >>> ??? link to the 2014 change that *introduced* the problem. >>> ??? No one is saying they reported this performance issue in 2014. >>> >>> ??? -phil. >>> >>> ??? On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >>>> ??? Back to the discussion on why did the blog poster not raise an >>>> ??? issue for the problems he mentioned... >>>> >>>> ??? Just FYI (in case you didn't see his recents comments), it >>>> ??? appears he did. He says he did it in a recent?comment on his >>>> ??? blog post (yesterday): >>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >>>> . >>>> ??? He says he filed an issue in 2014. >>>> >>>> ??? Cheers, >>>> >>>> >>>> ??? -- ??? Pedro Duque Vieira - https://www.pixelduke.com >>>> ??? >>> >>> >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com >> > From pedro.duquevieira at gmail.com Sat Mar 20 19:42:43 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 20 Mar 2021 19:42:43 +0000 Subject: Not really a nice comment but a real issue? In-Reply-To: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> References: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> Message-ID: Cool. Thanks Philip! On Sat, Mar 20, 2021 at 6:57 PM Philip Race wrote: > It was a P4 enhancement. I've made it a bug .. this or the new one should > be closed as a dup. > Normally I'd close the new one but not so clear here. I'll leave it to > Kevin to choose. > > -phil. > > On 3/20/21 11:54 AM, Philip Race wrote: > > > Ah, I missed that. And with that, I've now found Gary's bug : > https://bugs.openjdk.java.net/browse/JDK-8239138 > > -phil. > > On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: > > Hi Philip, > > Gary Bentley is the blog owner and author of the post. Scott Palmer is > commenting on Gary Bentley's blog post. > I was talking about Gary Bentley's comment to Scott Palmer's asking why he > didn't file an issue. > > *Scott Palme*r: "*It?s Open Source? submit an issue and a pull request to > at least fix the performance."* > And Gary Bentley the author of the blog replied: > *Gary Bentley*:"...*I did raise this issue at the time, I raised a bug.*" > *. "...There is a rendering issue with WebView in > 13+ versions that I also need to raise."* > > > Cheers, > > On Sat, Mar 20, 2021 at 5:12 PM Philip Race > wrote: > >> Actually the way I read it, Scott Palmer added a comment with a link to >> the 2014 change that *introduced* the problem. >> No one is saying they reported this performance issue in 2014. >> >> -phil. >> >> On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >> >> Back to the discussion on why did the blog poster not raise an issue for >> the problems he mentioned... >> >> Just FYI (in case you didn't see his recents comments), it appears he >> did. He says he did it in a recent comment on his blog post (yesterday): >> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >> . >> He says he filed an issue in 2014. >> >> Cheers, >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> >> >> > > -- > Pedro Duque Vieira - https://www.pixelduke.com > > > > -- Pedro Duque Vieira - https://www.pixelduke.com From tbee at tbee.org Sat Mar 20 22:06:02 2021 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 20 Mar 2021 23:06:02 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <120a4835-0f7d-8b14-f93c-ee412de7c385@oracle.com> Message-ID: <6e83f23b-8291-76c1-f2f1-f97717996174@tbee.org> And the reaction is interesting. I'll better leave it at that one comment. On 20-3-2021 20:10, Tom Eugelink wrote: > I could not refrain from commenting on the tone of the blog, in line with what Johan often complains about. Apparently you guys are stronger than me. But I was polite and kept it to myself. > > > > On 20-3-2021 19:57, Philip Race wrote: >> It was a P4 enhancement. I've made it a bug .. this or the new one should be closed as a dup. >> Normally I'd close the new one but not so clear here. I'll leave it to Kevin to choose. >> >> -phil. >> >> On 3/20/21 11:54 AM, Philip Race wrote: >>> >>> Ah, I missed that. And with that, I've now found Gary's bug : https://bugs.openjdk.java.net/browse/JDK-8239138 >>> >>> -phil. >>> >>> On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: >>>> Hi Philip, >>>> >>>> Gary?Bentley is the blog owner and author of the post. Scott Palmer is commenting on Gary Bentley's blog post. >>>> I was talking about Gary Bentley's comment to Scott Palmer's asking why he didn't file an issue. >>>> >>>> *Scott Palme*r: "/It?s Open Source? submit an issue and a pull request to at least fix the performance."/ >>>> And Gary Bentley the author of the blog replied: >>>> *Gary Bentley*:".../I did raise this issue at the time, I raised a bug./"/. >>>> ? ? ? ? ? ? ? ? ? ? ? "...There is a rendering issue with WebView in 13+ versions that I also need to raise."/ >>>> >>>> >>>> Cheers, >>>> >>>> On Sat, Mar 20, 2021 at 5:12 PM Philip Race > wrote: >>>> >>>> ??? Actually the way I read it, Scott Palmer added a comment with a >>>> ??? link to the 2014 change that *introduced* the problem. >>>> ??? No one is saying they reported this performance issue in 2014. >>>> >>>> ??? -phil. >>>> >>>> ??? On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >>>>> ??? Back to the discussion on why did the blog poster not raise an >>>>> ??? issue for the problems he mentioned... >>>>> >>>>> ??? Just FYI (in case you didn't see his recents comments), it >>>>> ??? appears he did. He says he did it in a recent?comment on his >>>>> ??? blog post (yesterday): >>>>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >>>>> . >>>>> ??? He says he filed an issue in 2014. >>>>> >>>>> ??? Cheers, >>>>> >>>>> >>>>> ??? -- ??? Pedro Duque Vieira - https://www.pixelduke.com >>>>> ??? >>>> >>>> >>>> >>>> -- >>>> Pedro Duque Vieira - https://www.pixelduke.com >>> >> > From tsayao at openjdk.java.net Sun Mar 21 00:34:38 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 21 Mar 2021 00:34:38 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Sat, 6 Mar 2021 23:53:06 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP while we run some more tests to make sure latest changes are ok. >> I'm fixing some residual "extra resize" issues (these issues exists on the current versions, so this makes it better, hopefully). > > Looks good now. Testing: **master** ![master](https://user-images.githubusercontent.com/30704286/111889893-6e793f80-89c3-11eb-8f38-640e8123794c.png) **tsayao:glass_gtk_new_position_and_size** ![branch](https://user-images.githubusercontent.com/30704286/111889897-733df380-89c3-11eb-9929-2ed55471638e.png) `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From nlisker at openjdk.java.net Sun Mar 21 17:50:49 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 21 Mar 2021 17:50:49 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: Message-ID: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> On Fri, 19 Mar 2021 21:01:58 GMT, Kevin Rushforth wrote: > There is an outstanding API question regarding the direction vector: Should the transforms of the SpotLight node to scene coordinates affect the direction vector (e.g., such that a rotation would rotate the direction the spotlight is pointing)? If so, do we even need the direction vector or could we define the direction as `(0,0,1)` in the local coordinates of the SpotLight, and tell applications to apply the appropriate rotation to define the direction. > > I think for consistency, the answer is "Yes" to the first question (that's how the position works and it would be odd for the transform to affect the position and not the direction). I'm less certain about the answer to the second question. Without utility functions like `lookAt` to help compute the appropriate transform, it seems important to be able to specify the direction as an explicit parameter. And even if we had utility functions, an app might want the control (although you might argue it would be unneeded). My instinct is to keep it as defined. If we go with this, the only change that is needed is a note that the transforms applied to the SpotLight node affect it's direction as well as its position. I would like to allow a developer to achieve a functionality like is shown in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are intuitive there. If we allow both rotation transforms and a direction, wouldn't that cause the direction to be unintuitive? Or do you mean that the direction is always the look-at regardless of rotation transforms and if it's `null` then the rotations take over? > On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. I don't see this on Linux and I don't have a Mac. Can you try on Linux and see what you get? If Linux works, I'm afraid I would not be able to debug the Mac. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From fkirmaier at openjdk.java.net Sun Mar 21 22:26:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 21 Mar 2021 22:26:12 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v8] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 Various changes based on code-review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/a73bcf82..2b275f55 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=06-07 Stats: 21 lines in 7 files changed: 2 ins; 17 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Sun Mar 21 22:26:13 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 21 Mar 2021 22:26:13 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v7] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 16:11:17 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> Seperated the unit-tests into seperate files > > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java line 35: > >> 33: public class InitializeJavaFXBase { >> 34: >> 35: > > Minor: there is an extra blank line here removed ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Sun Mar 21 22:30:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 21 Mar 2021 22:30:11 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: > Fixing deadlock when calling Application.launch in the FXThread after Platform.startup Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8263322 fixed the names of some tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/421/files - new: https://git.openjdk.java.net/jfx/pull/421/files/2b275f55..f0622da9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=421&range=07-08 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/421.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/421/head:pull/421 PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Sun Mar 21 22:43:40 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 21 Mar 2021 22:43:40 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v7] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 16:29:35 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> Seperated the unit-tests into seperate files > > Thanks for splitting up the tests. I ran them with the fix and all pass, I then ran them without the fix and only the one I expected to fail did. > > Before approving this, can you change the title of the JBS bug and CSR issue to match (after doing that you will also need to update this PR title) as recommended in the CSR? My suggestion is something like: > > Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock > > Another thing I recommend is to comment out or remove the print statements in the tests. They are useful while debugging, but in production we prefer tests to only print something as a warning or error. > > I also left a few inline comments. I've made all the changes in the comments, and also changed the names of the tickets and the PR. For some reason, I can't interact with the two unclosed comments. I've removed the unreachable code, and the print-statements are also removed. > tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch1Test.java line 41: > >> 39: >> 40: @Test (timeout = 15000) >> 41: public void testStartupThenLaunchInFX() throws Exception { > > Would something like `testLaunchThenLaunchInFX` be a better name? As it is, it uses the same name as the test that really does use `Platform.startup` which I found confusing. Yes, I've fixed the method names! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From la.tinca at gmail.com Mon Mar 22 10:15:40 2021 From: la.tinca at gmail.com (=?UTF-8?Q?Zsolt_K=C3=BAti?=) Date: Mon, 22 Mar 2021 11:15:40 +0100 Subject: user mailing list In-Reply-To: References: Message-ID: Thanks! On Fri, Mar 19, 2021 at 4:16 PM Nir Lisker wrote: > The mailing lists are only for development and discussion purposes. If you > think there's a bug or a missing feature you can ask here, but if you need > help then there is no formal mailing list for that. > If SO didn't help, you can try r/JavaFX on Reddit or search for a > JavaFX discord server. > > On Mon, Mar 15, 2021 at 9:25 PM Zsolt K?ti wrote: > >> Hi, >> >> I asked something on Stackoverflow I do not think I can formulate better, >> but it was closed right away. Is there a mailing list for user questions? >> >> Thx, >> Zsolt >> > From kevin.rushforth at oracle.com Mon Mar 22 12:15:36 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Mar 2021 05:15:36 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: Message-ID: <714eee0a-fc2b-4d6a-ca20-1eb25e8cd6ea@oracle.com> I had missed that as well. I'll close the bug I filed as a duplicate and raise the priority of that bug. -- Kevin On 3/20/2021 11:54 AM, Philip Race wrote: > > Ah, I missed that. And with that, I've now found Gary's bug : > https://bugs.openjdk.java.net/browse/JDK-8239138 > > -phil. > > On 3/20/21 10:36 AM, Pedro Duque Vieira wrote: >> Hi Philip, >> >> Gary?Bentley is the blog owner and author of the post. Scott Palmer >> is commenting on Gary Bentley's blog post. >> I was talking about Gary Bentley's comment to Scott Palmer's asking >> why he didn't file an issue. >> >> *Scott Palme*r: "/It?s Open Source? submit an issue and a pull >> request to at least fix the performance."/ >> And Gary Bentley the author of the blog replied: >> *Gary Bentley*:".../I did raise this issue at the time, I raised a >> bug./"/. >> ? ? ? ? ? ? ? ? ? ? ? "...There is a rendering issue with WebView in >> 13+ versions that I also need to raise."/ >> >> >> Cheers, >> >> On Sat, Mar 20, 2021 at 5:12 PM Philip Race > > wrote: >> >> Actually the way I read it, Scott Palmer added a comment with a >> link to the 2014 change that *introduced* the problem. >> No one is saying they reported this performance issue in 2014. >> >> -phil. >> >> On 3/20/21 7:37 AM, Pedro Duque Vieira wrote: >>> Back to the discussion on why did the blog poster not raise an >>> issue for the problems he mentioned... >>> >>> Just FYI (in case you didn't see his recents comments), it >>> appears he did. He says he did it in a recent?comment on his >>> blog post (yesterday): >>> https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/#comment-464 >>> . >>> He says he filed an issue in 2014. >>> >>> Cheers, >>> >>> >>> -- >>> Pedro Duque Vieira - https://www.pixelduke.com >>> >> >> >> >> -- >> Pedro Duque Vieira - https://www.pixelduke.com >> > From fkirmaier at openjdk.java.net Mon Mar 22 14:30:58 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 22 Mar 2021 14:30:58 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v3] In-Reply-To: References: Message-ID: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8263402 Rewrote the style memoryleak test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/424/files - new: https://git.openjdk.java.net/jfx/pull/424/files/b39db419..52fa05f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=01-02 Stats: 61 lines in 1 file changed: 31 ins; 27 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Mon Mar 22 14:38:40 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 22 Mar 2021 14:38:40 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 18:59:40 GMT, Ambarish Rapte wrote: >> About whether we should use WeakReference here or not. >> >> It definitely falls into the exception for referring to the Parrent of a Node. (Or to the Parent in a more abstract sense, I think it can also be the parent of the parent, or even from another SceneGraph.) >> >> I don't know the CSS code very well, so I currently don't have the knowledge how to change it. >> But if we would change this variable, whenever the node is removed from the SceneGraph, my concern would be that it would have an unfavorable complexity. Currently (I hope) the complexity of removing a Node from the SceneGraph is O(1). If we would remove the stylehelper from the node, then the complexity would be O(). >> >> The current change assumes that we don't process the CSS, when a node is removed from the SG. This is why it isn't checked for null. I would argue, if this causes an Error, then it just reveals another issue, which would be preferable over a more complicated fix, and also changing the complexity of removing nodes from the SG. > > Below is a fix that I tried, It fixes the issue. The system test passed with this change. > I was suggesting a solution like this where we can know exactly when to `null` the reference. The change is not extensively tested though. (For example, test what happens if we remove a node and add it back, OR remove a node and add it to a different scenegraph) > However, in this case using `WeakReference` approach seems harmless. Using `WeakReference` for Listeners is not clean and may cause issues, but a `WeakReference` to Node should not cause any harm. > > I would recommend earlier way to explicitly release references/resources when it is possible. That way we get to have the control instead of gc. > > > diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java > index fd02c0c1ad..471d0071b5 100644 > --- a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java > +++ b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java > @@ -36,6 +36,7 @@ import java.util.Set; > > import javafx.beans.property.ObjectProperty; > import javafx.beans.property.SimpleObjectProperty; > +import javafx.beans.value.ChangeListener; > import javafx.beans.value.WritableValue; > import com.sun.javafx.css.CascadingStyle; > import javafx.css.CssMetaData; > @@ -82,6 +83,14 @@ final class CssStyleHelper { > this.triggerStates = new PseudoClassState(); > } > > + ChangeListener sceneChangeListener; > + > + static void dispose(CssStyleHelper styleHelper, Node node) { > + styleHelper.resetToInitialValues(node); > + styleHelper.firstStyleableAncestor = null; > + node.sceneProperty().removeListener(styleHelper.sceneChangeListener); > + } > + > /** > * Creates a new StyleHelper. > */ > @@ -158,7 +167,7 @@ final class CssStyleHelper { > // If this node had a style helper, then reset properties to their initial value > // since the node won't have a style helper after this call > if (node.styleHelper != null) { > - node.styleHelper.resetToInitialValues(node); > + dispose(node.styleHelper, node); > } > > // > @@ -181,8 +190,14 @@ final class CssStyleHelper { > // If this node had a style helper, then reset properties to their initial value > // since the style map might now be different > if (node.styleHelper != null) { > - node.styleHelper.resetToInitialValues(node); > + dispose(node.styleHelper, node); > } > + helper.sceneChangeListener = (ov, oldScene, newScene) -> { > + if (newScene == null) { > + helper.firstStyleableAncestor = null; > + } > + }; > + node.sceneProperty().addListener(helper.sceneChangeListener); > return helper; > } I rewrote now the test. The initialization and teardown of JavaFX are now separated from the actual test. Now also none of the variables which is used in the test, are accessible from outside the test, and vise versa. Should I switch the fix to your solution, or should I keep mine which is based on WeakReferences? As you've mentioned, WeakReference should be fine here too. As I've mentioned, doing something for every node, whose scene is set to null, might change the complexity of removing a node from O(1) to O(). I think it's also quite important to support fast removing/adding subtrees. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Mon Mar 22 14:53:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Mar 2021 14:53:43 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 14:35:58 GMT, Florian Kirmaier wrote: >> Below is a fix that I tried, It fixes the issue. The system test passed with this change. >> I was suggesting a solution like this where we can know exactly when to `null` the reference. The change is not extensively tested though. (For example, test what happens if we remove a node and add it back, OR remove a node and add it to a different scenegraph) >> However, in this case using `WeakReference` approach seems harmless. Using `WeakReference` for Listeners is not clean and may cause issues, but a `WeakReference` to Node should not cause any harm. >> >> I would recommend earlier way to explicitly release references/resources when it is possible. That way we get to have the control instead of gc. >> >> >> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java >> index fd02c0c1ad..471d0071b5 100644 >> --- a/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java >> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java >> @@ -36,6 +36,7 @@ import java.util.Set; >> >> import javafx.beans.property.ObjectProperty; >> import javafx.beans.property.SimpleObjectProperty; >> +import javafx.beans.value.ChangeListener; >> import javafx.beans.value.WritableValue; >> import com.sun.javafx.css.CascadingStyle; >> import javafx.css.CssMetaData; >> @@ -82,6 +83,14 @@ final class CssStyleHelper { >> this.triggerStates = new PseudoClassState(); >> } >> >> + ChangeListener sceneChangeListener; >> + >> + static void dispose(CssStyleHelper styleHelper, Node node) { >> + styleHelper.resetToInitialValues(node); >> + styleHelper.firstStyleableAncestor = null; >> + node.sceneProperty().removeListener(styleHelper.sceneChangeListener); >> + } >> + >> /** >> * Creates a new StyleHelper. >> */ >> @@ -158,7 +167,7 @@ final class CssStyleHelper { >> // If this node had a style helper, then reset properties to their initial value >> // since the node won't have a style helper after this call >> if (node.styleHelper != null) { >> - node.styleHelper.resetToInitialValues(node); >> + dispose(node.styleHelper, node); >> } >> >> // >> @@ -181,8 +190,14 @@ final class CssStyleHelper { >> // If this node had a style helper, then reset properties to their initial value >> // since the style map might now be different >> if (node.styleHelper != null) { >> - node.styleHelper.resetToInitialValues(node); >> + dispose(node.styleHelper, node); >> } >> + helper.sceneChangeListener = (ov, oldScene, newScene) -> { >> + if (newScene == null) { >> + helper.firstStyleableAncestor = null; >> + } >> + }; >> + node.sceneProperty().addListener(helper.sceneChangeListener); >> return helper; >> } > > I rewrote now the test. The initialization and teardown of JavaFX are now separated from the actual test. Now also none of the variables which is used in the test, are accessible from outside the test, and vise versa. > > Should I switch the fix to your solution, or should I keep mine which is based on WeakReferences? As you've mentioned, WeakReference should be fine here too. > As I've mentioned, doing something for every node, whose scene is set to null, might change the complexity of removing a node from O(1) to O({size-of-tree}). I think it's also quite important to support fast removing/adding subtrees. I think the fix based on `WeakReference` is fine in this case, for the reasons discussed (it is a back link to an ancestor node) and given the performance concerns. I'd like Ambarish to comment as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Mon Mar 22 16:30:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Mar 2021 16:30:44 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 22:30:11 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > fixed the names of some tests Looks good. The CSR is ready to move to the Proposed state (there is one typo in the description that I pointed out). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/421 From philip.race at oracle.com Mon Mar 22 22:27:25 2021 From: philip.race at oracle.com (Philip Race) Date: Mon, 22 Mar 2021 15:27:25 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> Message-ID: <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> I am informed that, for no reason given, the corporate IT folks will not allow attachment upload. Attempts over the years to persuade them otherwise have failed. The best suggestion is you upload it somewhere else and include the link in the bug report and the Oracle reviewer can grab it. I've suggested we add that suggestion - at least to the FAQ item about attachments - if not more prominently. https://bugs.java.com/bugdatabase/faq.do#faq-7 -phil. On 3/19/21 12:37 PM, Philip Race wrote: > Interesting that there's no way to add an attachment (image or > otherwise). > I'll ask why that can't be made possible. > > -phil. > > On 3/19/21 12:23 PM, John Neffenger wrote: >> On 3/19/21 11:05 AM, Philip Race wrote: >>> If this was important to him I don't understand why just a blog post >>> and not a bug report .. >> >> If I had to guess, it might be because, in the age of GitHub, this is >> not what people expect when they try to report a bug: >> >> Report a Bug or Request a Feature >> https://bugreport.java.com/bugreport/ >> >> There are two main problems: >> >> 1. You can't attach images. From nlisker at openjdk.java.net Mon Mar 22 23:05:03 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 22 Mar 2021 23:05:03 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v11] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Removed whitespace - Updated the system test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/39dc40cc..026ce1b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=09-10 Stats: 406 lines in 2 files changed: 261 ins; 145 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon Mar 22 23:05:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 22 Mar 2021 23:05:04 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Sun, 21 Mar 2021 17:48:10 GMT, Nir Lisker wrote: >> Finally getting back to this. >> >> There is an outstanding API question regarding the direction vector: Should the transforms of the SpotLight node to scene coordinates affect the direction vector (e.g., such that a rotation would rotate the direction the spotlight is pointing)? If so, do we even need the direction vector or could we define the direction as `(0,0,1)` in the local coordinates of the SpotLight, and tell applications to apply the appropriate rotation to define the direction. >> >> I think for consistency, the answer is "Yes" to the first question (that's how the position works and it would be odd for the transform to affect the position and not the direction). I'm less certain about the answer to the second question. Without utility functions like `lookAt` to help compute the appropriate transform, it seems important to be able to specify the direction as an explicit parameter. And even if we had utility functions, an app might want the control (although you might argue it would be unneeded). My instinct is to keep it as defined. If we go with this, the only change that is needed is a note that the transforms applied to the SpotLight node affect it's direction as well as its position. >> >> Implementation: >> >> Can you add a system test similar to what you did for attenuation to verify the basic functionality? >> >> I tested this a bit on Windows using D3D and it behaves as I would expect, although I didn't do exhaustive testing. >> >> On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. The falloff happens too fast (at 1 you can't see the light at all). For the inner/outer angles, something looks backwards. See the attached image >> SpotLight-macOS >> >> I left a few inline comments, although I haven't reviewed the shader files in detail yet. > >> There is an outstanding API question regarding the direction vector: Should the transforms of the SpotLight node to scene coordinates affect the direction vector (e.g., such that a rotation would rotate the direction the spotlight is pointing)? If so, do we even need the direction vector or could we define the direction as `(0,0,1)` in the local coordinates of the SpotLight, and tell applications to apply the appropriate rotation to define the direction. >> >> I think for consistency, the answer is "Yes" to the first question (that's how the position works and it would be odd for the transform to affect the position and not the direction). I'm less certain about the answer to the second question. Without utility functions like `lookAt` to help compute the appropriate transform, it seems important to be able to specify the direction as an explicit parameter. And even if we had utility functions, an app might want the control (although you might argue it would be unneeded). My instinct is to keep it as defined. If we go with this, the only change that is needed is a note that the transforms applied to the SpotLight node affect it's direction as well as its position. > > I would like to allow a developer to achieve a functionality like is shown in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are intuitive there. If we allow both rotation transforms and a direction, wouldn't that cause the direction to be unintuitive? Or do you mean that the direction is always the look-at regardless of rotation transforms and if it's `null` then the rotations take over? > >> On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. > > I don't see this on Linux and I don't have a Mac. Can you try on Linux and see what you get? If Linux works, I'm afraid I would not be able to debug the Mac. I modified the existing attenuation test to use a `SpotLight`, which is more general, and separated the tests for the various contributions of the light. I renamed the class, so the previous version is removed, but its tests are the same in the new class. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Mon Mar 22 23:49:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Mar 2021 23:49:41 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Mon, 22 Mar 2021 23:00:05 GMT, Nir Lisker wrote: >>> There is an outstanding API question regarding the direction vector: Should the transforms of the SpotLight node to scene coordinates affect the direction vector (e.g., such that a rotation would rotate the direction the spotlight is pointing)? If so, do we even need the direction vector or could we define the direction as `(0,0,1)` in the local coordinates of the SpotLight, and tell applications to apply the appropriate rotation to define the direction. >>> >>> I think for consistency, the answer is "Yes" to the first question (that's how the position works and it would be odd for the transform to affect the position and not the direction). I'm less certain about the answer to the second question. Without utility functions like `lookAt` to help compute the appropriate transform, it seems important to be able to specify the direction as an explicit parameter. And even if we had utility functions, an app might want the control (although you might argue it would be unneeded). My instinct is to keep it as defined. If we go with this, the only change that is needed is a note that the transforms applied to the SpotLight node affect it's direction as well as its position. >> >> I would like to allow a developer to achieve a functionality like is shown in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are intuitive there. If we allow both rotation transforms and a direction, wouldn't that cause the direction to be unintuitive? Or do you mean that the direction is always the look-at regardless of rotation transforms and if it's `null` then the rotations take over? >> >>> On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. >> >> I don't see this on Linux and I don't have a Mac. Can you try on Linux and see what you get? If Linux works, I'm afraid I would not be able to debug the Mac. > > I modified the existing attenuation test to use a `SpotLight`, which is more general, and separated the tests for the various contributions of the light. I renamed the class, so the previous version is removed, but its tests are the same in the new class. >From an API coverage point of view, it seems better to leave the existing `PointLight` tests and add new ones for `SpotLight`. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Mon Mar 22 23:58:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Mar 2021 23:58:41 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Sun, 21 Mar 2021 17:48:10 GMT, Nir Lisker wrote: > I would like to allow a developer to achieve a functionality like is shown in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are intuitive there. If we allow both rotation transforms and a direction, wouldn't that cause the direction to be unintuitive? Or do you mean that the direction is always the look-at regardless of rotation transforms and if it's `null` then the rotations take over? I the rotation needs to apply to whatever the direction vector is: whether that's implicitly (0,0,1) if we don't provide a separate direction vector or whether it's the user provided direction vector, it would be odd to ignore transforms if you set the vector. If we don't provide a vector, we could always add it later if people ask for it, so maybe it is better to leave it off if we aren't sure. The question then becomes how easy is it to modify the direction vector using the node transforms? > > On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. > > I don't see this on Linux and I don't have a Mac. Can you try on Linux and see what you get? If Linux works, I'm afraid I would not be able to debug the Mac. It's broken on Linux, too -- more so, since there is no lighting most of the time. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jgneff at openjdk.java.net Tue Mar 23 05:36:57 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Mar 2021 05:36:57 GMT Subject: RFR: 8264010: Add Gradle dependency verification Message-ID: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: * [JDK-8262236][1]: Configure Gradle checksum verification * [JDK-8263204][2]: Add Gradle Wrapper Validation Action * [JDK-8264010][3]: Add Gradle dependency verification "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: * [C?dric Champeau at Devoxx][6] in November 2019 * [Louis Jacomet at Jfokus][7] in February 2020 "We all run in a crazy-unsafe environment," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 [4]: https://docs.gradle.org/current/userguide/dependency_verification.html [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf [6]: https://youtu.be/GWGNp3a3hpk [7]: https://youtu.be/bwiafNatsf0 ------------- Commit messages: - 8264010: Add Gradle dependency verification Changes: https://git.openjdk.java.net/jfx/pull/437/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264010 Stats: 173 lines in 1 file changed: 173 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/437/head:pull/437 PR: https://git.openjdk.java.net/jfx/pull/437 From john at status6.com Tue Mar 23 06:27:32 2021 From: john at status6.com (John Neffenger) Date: Mon, 22 Mar 2021 23:27:32 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> Message-ID: <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> On 3/22/21 3:27 PM, Philip Race wrote: > I am informed that, for no reason given, the corporate IT folks will not > allow attachment upload. Thank you for looking into it, Phil. It's good at least to have a definitive answer. I brought this up on the mailing list three years ago, too: Re: More community participation in JavaFX https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021343.html I eventually created those bug reports, despite all the gate-keeping. In fact, I'm even starting to think there could be advantages to having pull requests as the only real way to participate in the OpenJFX project. A flood of easily-created issues on GitHub can be just as off-putting as that Oracle Web form. John From johan.vos at gluonhq.com Tue Mar 23 07:34:31 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 23 Mar 2021 08:34:31 +0100 Subject: Not really a nice comment but a real issue? In-Reply-To: <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> Message-ID: Hi John, all, Clearly, there are advantages and disadvantages to the Oracle Web form. It's not a black/white situation. We need to find a solution that combines the advantages of being accessible as well as not creating false expectations. I really like the JBS system, it is very powerful and flexible. For example, we now semi-automatically create the release notes for JavaFX using a script. Once you have an account there, it serves its purposes. But I agree, the barrier for non-JDK authors to submit a bug is too high, resulting in issues being reported in random places, not always in a nice way. Hence, I think we need to provide something easier, without giving up the power of JBS. Actually, I am in favor of keeping JBS as it is, as its benefits are mainly relevant *after* an issue is entered. The question then moves to *how* issues are entered, and I agree the webform isn't the best way for this. The transformation between "how" issues are created and then how they are tracked is currently done manually at Oracle, and that is something that might be done in a more open, collaborative way. It's not fun work though, but I agree transparency would help here, and if the JavaFX community can help the Oracle folks with triaging OpenJFX bugs, that sounds like a win-win to me. One of the things I want to avoid is a random "report" that shows part of a stacktrace, with the reporter not giving more information. That issue would then become a stale issue, giving a bad impression. If those issues pile up in a public issue tracker. So how do we manage expectations, avoiding nasty tweets like "I told them there was an issue and after 2 years it's still there!" In summary, I believe we need to separate a few things: * JBS: we use this as issue tracker, where we track, monitor, label, set versions, link to other issues, with different possible workflows. I think there is no alternative for this, and that's not needed. * bug-report system: I'm all in to find a more accessible way, keeping into account that would require work being done by the community (hence, us) for converting issues into high-quality JBS issues. - Johan On Tue, Mar 23, 2021 at 7:28 AM John Neffenger wrote: > On 3/22/21 3:27 PM, Philip Race wrote: > > I am informed that, for no reason given, the corporate IT folks will not > > allow attachment upload. > > Thank you for looking into it, Phil. It's good at least to have a > definitive answer. I brought this up on the mailing list three years > ago, too: > > Re: More community participation in JavaFX > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021343.html > > I eventually created those bug reports, despite all the gate-keeping. In > fact, I'm even starting to think there could be advantages to having > pull requests as the only real way to participate in the OpenJFX > project. A flood of easily-created issues on GitHub can be just as > off-putting as that Oracle Web form. > > John > From arapte at openjdk.java.net Tue Mar 23 07:55:45 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 07:55:45 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 22:30:11 GMT, Florian Kirmaier wrote: >> Fixing deadlock when calling Application.launch in the FXThread after Platform.startup > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8263322 > fixed the names of some tests Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From arapte at openjdk.java.net Tue Mar 23 08:07:50 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 08:07:50 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 14:35:58 GMT, Florian Kirmaier wrote: > I think it's also quite important to support fast removing/adding subtrees. Yes, Adding listener seems over kill here. Lets go with `WeakReference` approach. I will take a look at the test update. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From daniel.peintner at gmail.com Tue Mar 23 08:28:24 2021 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Tue, 23 Mar 2021 09:28:24 +0100 Subject: Dialog contentText does not wrap correctly always In-Reply-To: References: Message-ID: Hello, Sorry for bothering you with my first email providing an example that used a helper class for showing the dialog. I looked further and please find below or in [1] a Short, Self Contained, Correct (Compilable), Example. The issue appears for cases when setting "glass.win.uiScale" to "1.5". The need for a second line for the alert contentText seems to fail and ellipses appear. Setting dialog.getDialogPane().setExpanded(true); makes the line appear but the dialog buttons move out of scene. On [1] you can also see some screenshots that illustrate the issue. Do you consider this as a bug? Does it make sense to open a bug report (I don't have the privileges to do so)? I hope I can help to make JavaFX even better. Note: I am using Windows 10, JavaFX version 16. Thanks again, -- Daniel [1] https://github.com/danielpeintner/Java11Test/issues/5 import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Alert;import javafx.scene.control.Button;import javafx.scene.layout.BorderPane;import javafx.stage.Stage; public class TestDialog extends Application { public static void main(String[] args) { System.setProperty("glass.win.uiScale", "1.5"); launch(args); } @Override public void start(Stage primaryStage) { primaryStage.setTitle("DialogTest!"); Button btn = new Button(); btn.setText("Show Dialog"); btn.setOnAction(event -> { Alert dialog = new Alert(Alert.AlertType.CONFIRMATION); dialog.setTitle("MyTitle"); dialog.setHeaderText("MyHeader"); dialog.setContentText("myContent 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30"); // dialog.getDialogPane().setExpanded(true); // makes the 2nd text line appear but moves the buttons out of the scene dialog.showAndWait(); }); BorderPane bp = new BorderPane(); bp.setCenter(btn); primaryStage.setScene(new Scene(bp, 300, 250)); primaryStage.show(); } } On Thu, Mar 18, 2021 at 12:07 PM Daniel Peintner wrote: > Hello, > > Thank you all for your work. I believe JavaFX is getting better and better. > Some recent updates like [1] fixed some issues I was having with certain > scaling levels. > > Today I stumbled over one issue that still exists with JavaFX version 16. > It relates to dialog where the contentText usually nicels wraps to the > next line if it does not fit. > > See below a simple code snippet and find on [2] screenshots that show the > problem. > (the problem is that it shows "..." and does *not* wrap to the next line) > > Are you aware of that problem? > > Thanks, > > -- Daniel > > [1] https://github.com/openjdk/jfx/pull/351 > [2] https://github.com/danielpeintner/Java11Test/issues/5 > > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ButtonType; > import javafx.scene.control.Label; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > import java.util.Optional; > > public class TestDialog extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) { > primaryStage.setTitle("HelloTest!"); > Button btn = new Button(); > btn.setText("Show Dialog"); > btn.setOnAction(event -> { > System.out.println("Hello World!"); > Optional result = DialogUtil.showYesNoCancelDialog( > "MyTitle", "MyHeader", > "myContent 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30"); > }); > > BorderPane bp = new BorderPane(); > bp.setCenter(btn); > primaryStage.setScene(new Scene(bp, 300, 250)); > primaryStage.show(); > } > } > > > > > From arapte at openjdk.java.net Tue Mar 23 09:59:42 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 09:59:42 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v3] In-Reply-To: References: Message-ID: On Mon, 22 Mar 2021 14:30:58 GMT, Florian Kirmaier wrote: >> Fixing a memory leak. >> A node hard references its old parent after CSS layout and getting removed. >> This shouldn't be the case, this is very counterintuitive. >> >> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. >> This should be fine because the CSS should only depend on it if it's still the real parent. >> In that case, it doesn't get collected. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8263402 > Rewrote the style memoryleak test Provided few comments on test. tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 48: > 46: import static org.junit.Assert.fail; > 47: import static org.junit.Assert.assertTrue; > 48: The packages Application, Node and Parent are not used. tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 59: > 57: startupLatch.countDown(); > 58: }); > 59: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); The runnable passed to `Platform.startup()` is executed on JavaFX Application thread once it is started. `Platform.setImplicitExit(false);` can be called from any thread. So we do not need to pass the runnable and do not need CountDownLatch. This block can be replaced by, Platform.startup(null); Platform.setImplicitExit(false); tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 100: > 98: Platform.runLater(() -> { > 99: Platform.exit(); > 100: }); `Platform.exit()` can be called from any thread. So `Platform.runLater` is not required. tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 102: > 100: }); > 101: } > 102: } Include a new line at end of file. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/424 From kcr at openjdk.java.net Tue Mar 23 11:20:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 11:20:40 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v3] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 09:49:42 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263402 >> Rewrote the style memoryleak test > > tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 59: > >> 57: startupLatch.countDown(); >> 58: }); >> 59: assertTrue("Timeout waiting for FX runtime to start", startupLatch.await(15, TimeUnit.SECONDS)); > > The runnable passed to `Platform.startup()` is executed on JavaFX Application thread once it is started. `Platform.setImplicitExit(false);` can be called from any thread. So we do not need to pass the runnable and do not need CountDownLatch. > This block can be replaced by, > Platform.startup(null); > Platform.setImplicitExit(false); While this is true, I like the current logic better, since it asserts that the platform has started, which provides a better error message in case there is a problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From fastegal at openjdk.java.net Tue Mar 23 11:43:41 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 23 Mar 2021 11:43:41 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: On Mon, 22 Feb 2021 20:29:29 GMT, Kevin Rushforth wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > Not yet reviewed. All of the new API methods need to have an `@since 17` javadoc tag. wondering about the sequence of next steps: should I create the csr before or after (partial) review of this? Doing before feels like expecting duplicate work (whenever doc changes are required, I'll have to change the code in the pr and the csr draft as well, I assume). If that's the way, I'll go it, naturally :) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Tue Mar 23 12:10:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 12:10:47 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> On Tue, 23 Mar 2021 05:32:04 GMT, John Neffenger wrote: > This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: > > * [JDK-8262236][1]: Configure Gradle checksum verification > * [JDK-8263204][2]: Add Gradle Wrapper Validation Action > * [JDK-8264010][3]: Add Gradle dependency verification > > "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: > > * [C?dric Champeau at Devoxx][6] in November 2019 > * [Louis Jacomet at Jfokus][7] in February 2020 > > "We all run in a crazy-unsafe environment," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 > [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https://youtu.be/GWGNp3a3hpk > [7]: https://youtu.be/bwiafNatsf0 This seems like a good idea to do. I have a couple overall questions before reviewing / testing. 1. Can you add some sort of README file that describes the how to update the checksums? Also, the instructions in [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt) should be updated accordingly. 2. Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From arapte at openjdk.java.net Tue Mar 23 14:30:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 14:30:56 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: > The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. > Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). > > Fix is to remove the listener when MenuItem is removed. > Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. > Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. > With fix, the count is always same as number of MenuItems in scenegraph. > > Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. > This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. > Added a comment explaining this behavior in place of the TODO. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: correct test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/429/files - new: https://git.openjdk.java.net/jfx/pull/429/files/4ed3f72f..62344c7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=429&range=01-02 Stats: 21 lines in 1 file changed: 12 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/429/head:pull/429 PR: https://git.openjdk.java.net/jfx/pull/429 From kcr at openjdk.java.net Tue Mar 23 15:20:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 15:20:43 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 11:41:23 GMT, Jeanette Winzenburg wrote: >> Not yet reviewed. All of the new API methods need to have an `@since 17` javadoc tag. > > wondering about the sequence of next steps: should I create the csr before or after (partial) review of this? Doing before feels like expecting duplicate work (whenever doc changes are required, I'll have to change the code in the pr and the csr draft as well, I assume). If that's the way, I'll go it, naturally :) I'll review the API changes in the next day or so. Then you can update the CSR and move to Proposed. I'll also ask Ambarish to be the second reviewer on this. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From arapte at openjdk.java.net Tue Mar 23 15:24:42 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 15:24:42 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport In-Reply-To: <4ne2j1FAVj78R61qHlfdYrj8pyxCU1933iU4oUOKV8Y=.7852666e-9997-43bf-b66d-58cbec9c9d21@github.com> References: <4ne2j1FAVj78R61qHlfdYrj8pyxCU1933iU4oUOKV8Y=.7852666e-9997-43bf-b66d-58cbec9c9d21@github.com> Message-ID: <9I6ihxA33UmMI_HT738j73sOjz7QxXQa_D9zfXn6rvc=.80c52d0c-c4e6-46f9-9e11-1f5395825fbb@github.com> On Sat, 20 Mar 2021 13:11:55 GMT, Kevin Rushforth wrote: > The new unit test fails on all platforms, as you can see from the GitHub actions log: The test failed because, change listeners added by other tests get accumulated in the `changeListenerMap`. These listeners can get GCed only if the tests correctly cleanup themselves. The test passes if executed individually. The test needed correction that, it should not assume the Map to be empty, instead verify fix by using current size of the `changeListenerMap` as reference. The Windows pre-submit test action has failed because _Task :graphics:compileDecoraNativeShadersWin FAILED_, and not because of the new test. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From john at status6.com Tue Mar 23 16:05:23 2021 From: john at status6.com (John Neffenger) Date: Tue, 23 Mar 2021 09:05:23 -0700 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> Message-ID: On 3/23/21 12:34 AM, Johan Vos wrote: > * bug-report system: I'm all in to find a more accessible way, keeping into > account that would require work being done by the community (hence, us) for > converting issues into high-quality JBS issues. I have two GitHub Issue Templates that gather the same information as the Oracle Web form for bug reports and feature requests. OpenJFX was the first project to move to GitHub. It could be the first to take over the bug submission, too. I know, easy for me to say! The burden would fall mainly on you and Kevin as project leads. You can look at the old sandbox repository to see the kind of reports we would get, as they're still coming in there at a steady pace. I think we could be pretty ruthless in regards to the quality. I'm losing patience with Java developers who say a bug is important but can't bother to push the "Step Into" button instead of the "Step Over" button in their debugger. But I'm fine as is, too. Maybe just let people know that they can become an Author and get access to the Java Bug System after only two commits! I was stunned when that happened. John From arapte at openjdk.java.net Tue Mar 23 17:28:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Mar 2021 17:28:40 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: References: Message-ID: On Sat, 20 Mar 2021 13:40:51 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments to fix typo in comment Fix looks good to me. Sanity testing with all three d3d, es2, sw pipelines behave as expected. Apps work as expected in case of remote desktop, sleep, screen lock. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/430 From ajoseph at openjdk.java.net Tue Mar 23 17:39:43 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 23 Mar 2021 17:39:43 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: References: Message-ID: On Sat, 20 Mar 2021 13:40:51 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments to fix typo in comment Fix looks good. Tested WebView by reconnecting via remote desktop. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/430 From arun.aj.joseph at oracle.com Tue Mar 23 17:53:47 2021 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Tue, 23 Mar 2021 17:53:47 +0000 Subject: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276) In-Reply-To: References: <7994E3AE-A95A-42F1-B96E-A1059AA6477B@oracle.com> <548B61D9-09D6-4871-8A90-771BE5FB8148@oracle.com> Message-ID: <6F577FB4-A5C6-485A-9BB1-066CB796658B@oracle.com> The thread dump doesn?t have enough details to locate where the problem occurs. Using a debug build with assertions disabled (as mentioned in the previous mail) may help in generating a thread dump for getting some more information. ? Arun Joseph On 18-Mar-2021, at 3:39 PM, Primo? Kokol > wrote: Thanks for pointing us in the right direction. I wasn't aware that jfxwebkit.pdb will be generated also in the case of a production build. So after generating a production build we were able to produce a thread dump (using jfxwebkit.pdb symbols) at the time when the application freezes. The complete bug report including thread dump is there: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788 Could you please just scan through it and let us know whether there is enough information to pursue this further or whether any additional information is needed? ? PrimosK On Tue, 16 Mar 2021 at 13:30, Arun Joseph > wrote: The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. ? Arun Joseph On 15-Mar-2021, at 6:08 PM, Primo? Kokol > wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 00000025dabfaf00() Unknown Non-user code 00000025dabfafc0() Unknown Non-user code 00000164ca445b4b() Unknown Non-user code cccccccccccccccc() Unknown Non-user code 00000164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph > wrote: I?m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. ? Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primo? Kokol > wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primo? Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * >>> globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols >> loaded. >>> jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, >>> JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ >>> Symbols loaded. >>> jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * >>> pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, >>> JSC::JSValue baseValue, const JSC::Identifier & ident, >>> JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. >>> jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, >> const >>> JSC::Instruction * pc) Line 833 C++ Symbols loaded. >>> jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. >>> 000000c7ef8fae90() Unknown Non-user code >>> 000000c7ef8faf50() Unknown Non-user code >>> 0000028d52eeedbb() Unknown Non-user code >>> cccccccccccccccc() Unknown Non-user code >>> 0000028d52eeedb6() Unknown Non-user code >>> >>> ... and partial output from the output console: >>> >>> .... >>> (S)tacking Context/(F)orced SC/O(P)portunistic SC, (N)ormal flow only, >>> (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates >>> blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, Behaves as >> fi(x)ed, >>> (C)omposited, (P)rovides backing/uses (p)rovided backing/paints to >>> (a)ncestor, (c)omposited descendant, (s)scrolling ancestor, >> (t)transformed >>> ancestor >>> Dirty (z)-lists, Dirty (n)ormal flow lists >>> Traversal needs: requirements (t)raversal on descendants, (b)acking or >>> hierarchy traversal on descendants, (r)equirements traversal on all >>> descendants, requirements traversal on all (s)ubsequent layers, >> (h)ierarchy >>> traversal on all descendants, update of paint (o)rder children >>> Update needs: post-(l)ayout requirements, (g)eometry, (k)ids geometry, >>> (c)onfig, layer conne(x)ion, (s)crolling tree >>> Scrolling scope: box contents >>> >>> S-------------- -- ------ -----s 34 34 0000028D98F22260 (0,0) width=460 >>> height=650 RenderView 0x28d4d4d1cd0 >>> S-------------- -- ------ ------ 34 34 + 0000028D4D98D430 (0,0) width= >> no >>> compositing work to do >>> FrameView 0000028D4F2A4CF0 performPostLayoutTasks >>> >>> FrameView 0000028D4F2A4CF0 updateLayoutViewport() totalContentSize >>> width=460 height=650 unscaledDocumentRect (0,0) width=460 height=650 >> header >>> height 0 footer height 0 fixed behavior 0 >>> layoutViewport: (0,0) width=460 height=650 >>> visualViewport: (0,0) width=460 height=650 (is override 0) >>> stable origins: min: (0.00,0.00) max: (0.00,0.00) >>> DocumentTimelinesController::updateAnimationsAndSendEvents for time >> 24.89s >>> DeclarativeAnimation::tick for element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C406A0 DIV >>> 0x28d40c406a0 class='leaflet-proxy leaflet-zoom-animated' >>> DeclarativeAnimation::tick for element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> KeyframeEffect::invalidate on element node 0000028D40C42E90 DIV >>> 0x28d40c42e90 class='leaflet-tile-container leaflet-zoom-animated' >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> EventDispatcher::dispatchEvent transitioncancel on node DIV >>> ASSERTION FAILED: canCast == from->JSCell::inherits(vm, Target::info()) >>> >> C:\jfx\modules\javafx.web\src\main\native\Source\JavaScriptCore\runtime\JSCast.h(143) >>> : JSC::JSCastingHelpers::inheritsJSTypeImpl >>> Unhandled exception at 0x00007FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> Note that this crash isn't happening with official JavaFX 15, 16, and >>> 17-ea+2 builds (that are at the time of writing this available on the >>> maven), but unfortunately we can't use these for debugging purposes. >>> >>> Does that indicate any issues with the native debug build or is this some >>> regression that was introduced in the current `master` branch recently >>> (after 17-ea+2)? >>> >>> Thanks for any helpful hints/advice in advance! >>> >>> Best regards, >>> PrimosK >> >> From jgneff at openjdk.java.net Tue Mar 23 18:30:48 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Mar 2021 18:30:48 GMT Subject: RFR: 8264061: LocalDateTimeStringConverterTest fails in Canada Message-ID: As the comment in the test case mentions, "Tests require that default locale is en_US." The default locale is required by the objects created in the static method `implementations`, marked with the JUnit annotation `@Parameterized.Parameters`. So the static method `initDefaultLocale`, marked with the JUnit annotation `@BeforeClass`, calls the method to set the required default: `Locale.setDefault(Locale.US)`. The problem occurs because the `@Parameterized.Parameters` method is called before the `@BeforeClass` method, so the system locale is used as the default instead of `Locale.US`. The fix is to move the call to the first instruction of the `@Parameterized.Parameters` method so that the default is set before it's required. ------------- Commit messages: - 8264061: LocalDateTimeStringConverterTest fails in Canada Changes: https://git.openjdk.java.net/jfx/pull/438/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=438&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264061 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/438.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/438/head:pull/438 PR: https://git.openjdk.java.net/jfx/pull/438 From kcr at openjdk.java.net Tue Mar 23 19:19:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 19:19:40 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: References: Message-ID: <1zpYucEDfRcyCqfB44vSYAfDOj_cOCdc3wEvTD7U5qc=.7ceabd52-18fc-46ec-9de2-5285c639c485@github.com> On Tue, 23 Mar 2021 17:36:28 GMT, Arun Joseph wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments to fix typo in comment > > Fix looks good. Tested WebView by reconnecting via remote desktop. @Schmidor did you have any further comments or feedback? Btw, I realized that you don't have a role in the openjfx project, so you can't formally review it. As such, I'll change the requirements back to 2 reviewers. I'll hold off integrating it until tomorrow in case you have additional feedback. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Tue Mar 23 19:49:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 19:49:39 GMT Subject: RFR: 8264061: LocalDateTimeStringConverterTest fails in Canada In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 18:24:40 GMT, John Neffenger wrote: > As the comment in the test case mentions, "Tests require that default locale is en_US." The default locale is required by the objects created in the static method `implementations`, marked with the JUnit annotation `@Parameterized.Parameters`. So the static method `initDefaultLocale`, marked with the JUnit annotation `@BeforeClass`, calls the method to set the required default: `Locale.setDefault(Locale.US)`. > > The problem occurs because the `@Parameterized.Parameters` method is called before the `@BeforeClass` method, so the system locale is used as the default instead of `Locale.US`. > > The fix is to move the call to the first instruction of the `@Parameterized.Parameters` method so that the default is set before it's required. Ah, I hadn't realized that. So this is a correction to the earlier fix for [JDK-8160039](https://bugs.openjdk.java.net/browse/JDK-8160039). Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/438 From github.com+10960818+schmidor at openjdk.java.net Tue Mar 23 20:08:42 2021 From: github.com+10960818+schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 23 Mar 2021 20:08:42 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: <1zpYucEDfRcyCqfB44vSYAfDOj_cOCdc3wEvTD7U5qc=.7ceabd52-18fc-46ec-9de2-5285c639c485@github.com> References: <1zpYucEDfRcyCqfB44vSYAfDOj_cOCdc3wEvTD7U5qc=.7ceabd52-18fc-46ec-9de2-5285c639c485@github.com> Message-ID: <6P3wfzDjmsIKYstf_fU-491eDdKDevG7tb_vs8vxFiY=.fbba28ed-1829-4bc9-a5e9-9367244364bf@github.com> On Tue, 23 Mar 2021 19:17:20 GMT, Kevin Rushforth wrote: >> Fix looks good. Tested WebView by reconnecting via remote desktop. > > @Schmidor did you have any further comments or feedback? > > Btw, I realized that you don't have a role in the openjfx project, so you can't formally review it. As such, I'll change the requirements back to 2 reviewers. I'll hold off integrating it until tomorrow in case you have additional feedback. @kevinrushforth No further concerns. I've checked embedded WebView and MediaPlayer in Swing and a standalone WebView. Looks good. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From alexsch at openjdk.java.net Tue Mar 23 20:26:47 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 23 Mar 2021 20:26:47 GMT Subject: RFR: 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) Message-ID: This is a proposal for cross compiling JavaFX base modules (excluding media and webkit) for Windows AArch64 (ARM64). Main changes: - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition - HOST_ARCH and TARGET_ARCH are retrieved from ext.OS_ARCH and ext.TARGET_ARCH using substitution aarch64 to arm64 and amd64 to x64 - VCARCH is set to "${HOST_ARCH}_${TARGET_ARCH}" architecture for cross compilation. VCARCH is set to x64 for amd64 target architecture (according to the [vcvarsall.bat doc](https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-160#developer_command_file_locations) x64 and amd64 are interchangeable) - arm64 rc.exe and fxc.exe execution fails on non arm64 host. The fix checks that and falls back to host rc.exe and fxc.exe. The right way would be to use rc.exe and fxc.exe from arm64 but I did not find a right way to run them on host system. I also looked which changes are required to build media module for Windows aarch64. The main changes could be using: - `ARCH=arm64` for building media libs in build.gradle file - `-MACHINE:arm64` LDFLAGS in media make files - `msvc_build/aarch64/aarch64_include` header files for include, `src/aarch64/win64_armasm.S` for ASM_SOURCES, `armasm64.exe` for ML in gstreamer/projects/win/glib-lite/Makefile.glib file and corresponding include in gstreamer/projects/win/glib-lite/Makefile.gobject file - setting `ENABLE_SIMD_SSE2` to 0 in ColorConverter.c in the similar way how it is done for Apple Silicon port In this way the media is build but it is crashed when I run a JavaFX sample with video. Is it possible to send the media Windows aarch64 port to review and investigate the crash in the separate fix? ------------- Commit messages: - 8264064: Cross compile JavaFX graphics and controls modules for Windows AArch64 (ARM64) Changes: https://git.openjdk.java.net/jfx/pull/439/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264064 Stats: 40 lines in 2 files changed: 29 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/439.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/439/head:pull/439 PR: https://git.openjdk.java.net/jfx/pull/439 From kcr at openjdk.java.net Tue Mar 23 20:30:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 20:30:40 GMT Subject: Integrated: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: Message-ID: <5smlR2SuxqPoeAY6RovWXEKag-gwGTeNOI0Gv3Yq5Ko=.de99862c-68a2-4252-a3df-a16d4c25770c@github.com> On Wed, 17 Mar 2021 18:17:48 GMT, Kevin Rushforth wrote: > This is a fix for a long-standing bug where the D3D pipeline will stop rendering when a Windows remote desktop session is disconnected and then reconnected. > > A preliminary Draft PR #315 by @Schmidor was a good first step in solving this. I took that and continued the work in my Draft PR #403. It is now ready for formal review in this new PR. You can see PR #403 for details on the history of the changes. > > ## Evaluation > > The root cause of this bug is that the D3D pipeline did not handle a return code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error occurs, an application needs to destroy and recreate the Direct3D device. > > The solution is to implement a new `D3DPipeline::reinitialize` method that will destroy the native D3D device and dispose the existing ResourceFactory objects and their associated BaseContext objects upon receiving `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is not recreated (it remains a singleton). In support of this, I implemented proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean everything up and also to avoid memory leaks. > > Additionally, there were several places that assumed that some textures (and mesh vertices) could be made permanent and never need to handle the case of a lost device. These all had to be fixed to allow for the possibility of a lost device and associated resource factory. They included: > > * UploadingPainter and PresentingPainter need to set the resource factory to null when not ready, so it will get the (possibly new) factory the next time it tries. > * The gradient texture cache in `PaintHelper` has to be cleared and recreated when the surface is lost > * The 3D triangle mesh and Phong material classes need to be disposed when the resource factory is disposed. > * WebView often renders to a texture image at a time other than from the main rendering job, so needs to directly handle the case of a resource factory that is lost. > * Decora PPSRenderer assumed that the resource factory never went away; it also accessed it on the wrong thread. Both problems were addressed by deferring the initialization of the resource factory and handling the case where the device is disposed. > * Snapshot needs to allow for the platform image to be null if the device has been disposed. > > ## Notes to Reviewers > > I created this PR from a branch that contains the original 4 commits by @Schmidor (rebased on top of the current `master`) and then a single commit on top of that to complete it. This allows anyone who is interested to easily see the diffs between this PR and Oliver's original Draft PR. Most reviewers can just go to the list of "Files" and see the aggregate diffs. > > During the course of my testing I discovered three outstanding problems, which will be handled by filing follow-up issues. Once I file them, I'll add a comment to this PR with the bug IDs. > > 1. Media: a media stream playing at the time of a reconnect doesn't continue playing. Reloading the media works fine. This is not directly related to this bug, since it also happens with the software pipeline. > 2. Canvas: doesn't preserve the contents after a device reconnect (noticed while running Zoomy, where the BG color is wrong after device reinitialization). This might point to a need to let the app know they have to repaint, since there is no possible way to preserve the contents of the texture when the device is lost. > 3. WebView: there is a possible memory leak when device isn't ready after first reset, due to a `WCRenderQueueImpl::gc` instance being held in a JNIGlobal. This looks like a preexisting condition that could happen with a page (re)load today. It happens rarely. > > This is a complicated enough change that I'd like three reviewers. The bulk of the changes are Windows-specific, but there are changes in common code so at least a sanity check needs to be done on all platforms using both the HW and SW pipelines. The case of a disposed device can currently only happen on Windows with the D3D pipeline. This pull request has now been integrated. Changeset: 73e70fe9 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/73e70fe9 Stats: 850 lines in 47 files changed: 728 ins; 36 del; 86 mod 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Co-authored-by: Oliver Schmidtmer Co-authored-by: Kevin Rushforth Reviewed-by: arapte, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From kcr at openjdk.java.net Tue Mar 23 20:30:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Mar 2021 20:30:38 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5] In-Reply-To: <6P3wfzDjmsIKYstf_fU-491eDdKDevG7tb_vs8vxFiY=.fbba28ed-1829-4bc9-a5e9-9367244364bf@github.com> References: <1zpYucEDfRcyCqfB44vSYAfDOj_cOCdc3wEvTD7U5qc=.7ceabd52-18fc-46ec-9de2-5285c639c485@github.com> <6P3wfzDjmsIKYstf_fU-491eDdKDevG7tb_vs8vxFiY=.fbba28ed-1829-4bc9-a5e9-9367244364bf@github.com> Message-ID: <2-jwCUCUENolKwXz-UoHvKI4-BLSTd7LjaE0JC2NImY=.630ce523-73ff-44a4-bda2-f9579cb88883@github.com> On Tue, 23 Mar 2021 20:06:15 GMT, Oliver Schmidtmer wrote: >> @Schmidor did you have any further comments or feedback? >> >> Btw, I realized that you don't have a role in the openjfx project, so you can't formally review it. As such, I'll change the requirements back to 2 reviewers. I'll hold off integrating it until tomorrow in case you have additional feedback. > > @kevinrushforth No further concerns. I've checked embedded WebView and MediaPlayer in Swing and a standalone WebView. Looks good. Thanks for the reply. I'll go ahead and integrate it then. ------------- PR: https://git.openjdk.java.net/jfx/pull/430 From github.com+1498664+hsiafan at openjdk.java.net Tue Mar 23 20:54:53 2021 From: github.com+1498664+hsiafan at openjdk.java.net (Hsiafan) Date: Tue, 23 Mar 2021 20:54:53 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method Message-ID: The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. ------------- Commit messages: - fix input UTF-16 surrogate-pairs in macOS Changes: https://git.openjdk.java.net/jfx/pull/436/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=436&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258381 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/436.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/436/head:pull/436 PR: https://git.openjdk.java.net/jfx/pull/436 From jgneff at openjdk.java.net Tue Mar 23 22:58:39 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 23 Mar 2021 22:58:39 GMT Subject: Integrated: 8264061: LocalDateTimeStringConverterTest fails in Canada In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 18:24:40 GMT, John Neffenger wrote: > As the comment in the test case mentions, "Tests require that default locale is en_US." The default locale is required by the objects created in the static method `implementations`, marked with the JUnit annotation `@Parameterized.Parameters`. So the static method `initDefaultLocale`, marked with the JUnit annotation `@BeforeClass`, calls the method to set the required default: `Locale.setDefault(Locale.US)`. > > The problem occurs because the `@Parameterized.Parameters` method is called before the `@BeforeClass` method, so the system locale is used as the default instead of `Locale.US`. > > The fix is to move the call to the first instruction of the `@Parameterized.Parameters` method so that the default is set before it's required. This pull request has now been integrated. Changeset: 3bbcf977 Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3bbcf977 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8264061: LocalDateTimeStringConverterTest fails in Canada Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/438 From johan.vos at gluonhq.com Wed Mar 24 08:15:43 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 24 Mar 2021 09:15:43 +0100 Subject: software cursor on hardware rendering Message-ID: Hi, I'm currently adding a software-cursor on top of hardware rendering (in case no hardware or OS-provided cursor is available). On all desktop platforms (and on Monocle with X11), we use the cursor provided by the window manager. In case there is no window manager, Monocle can use a software cursor in case we use the SW rendering pipeline. But there are cases where hw-rendering is available, but no hw-cursor is available. Instead of giving up all the hw-rendering, I want to add a sw-cursor on top of the EGL/OpenGLES-based rendering. There are a number of hooks that I can use: 1. do it entirely in the native layer. This will not be the fastest approach, as we need to somehow decompose the EGL surface and add a texture to it, but it should work. But it requires a fair amount of native code that is driver-dependent and hard to maintain. 2. intercept the ViewPainter.paintImpl call, and add a Cursor similar to how e.g. rectangles around dirtyRegions are rendered 3. invoke setOverlayRoot in ViewPainter, although that method seems to be created solely for displaying a warning when going full screen 4. do it similar to how the SW cursor is rendered in Monocle: PaintCollector will *after* all rendering is done invoke `Application.GetApplication().notifyRenderingFinished();` and the Monocle implementation will invoke MonocleScreen.swapBuffers() which will upload the pixels for the cursor to the framebuffer. I'm not sure that is the best approach, as it splits the rendering in 2 different chunks, and it doesn't easily translate to the hw rendering case (where we simply call swapBuffers on the GL Context). Are there any thoughts/opinions about this? - Johan From kcr at openjdk.java.net Wed Mar 24 12:12:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 12:12:44 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: References: Message-ID: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> On Sun, 21 Mar 2021 04:13:48 GMT, Hsiafan wrote: > The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. I'll review this. The fix seems fine at first glance. With your patch it uses a similar mechanism to the attributed string case; I'm curious why copying the string is needed in that case, but not in this case. What testing have you done to ensure that this will not cause any regressions? Perhaps @prrace or @jperedadnr or @johanvos could be a second reviewer? ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From pbansal at openjdk.java.net Wed Mar 24 12:35:41 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Wed, 24 Mar 2021 12:35:41 GMT Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code In-Reply-To: References: <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com> <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com> <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com> Message-ID: On Sun, 21 Mar 2021 00:31:35 GMT, Thiago Milczarek Sayao wrote: >> Looks good now. > > Testing: > > **master** > ![master](https://user-images.githubusercontent.com/30704286/111889893-6e793f80-89c3-11eb-8f38-640e8123794c.png) > > **tsayao:glass_gtk_new_position_and_size** > ![branch](https://user-images.githubusercontent.com/30704286/111889897-733df380-89c3-11eb-9929-2ed55471638e.png) > > `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes. I ran the full test on Ubuntu 20.10 and the results look fine. I do not see any new failure. ------------- PR: https://git.openjdk.java.net/jfx/pull/367 From kcr at openjdk.java.net Wed Mar 24 13:43:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 13:43:57 GMT Subject: RFR: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set Message-ID: If the macOS system settings for opening documents as tabs is set to "Always", then all JavaFX windows, including Dialogs, are opened as tabs, unless they are child windows (that is, a Window with an owner). This is a real problem for certain types of dialogs, such as `APPLICATION_MODAL` dialogs, regardless of whether the app uses `show()` or uses `showAndWait()` to spin up a nested event loop. Also, if the dialog is of a different size that the main window, it will resize itself when switching tabs (which is visually jarring), and will not be sized correctly. Even for ordinary stages, this isn't the desired behavior. The fix is to disallow opening in tabs for all JavaFX windows. There are a couple existing tests that fail when the setting for opening documents in tabs is set to "Always", but I also added a new explicit test for this by creating two Stages and verifying that both are active at the same time. ------------- Commit messages: - 8263169: [macos] With changed system preference JavaFX window will open as tabs Changes: https://git.openjdk.java.net/jfx/pull/440/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=440&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263169 Stats: 174 lines in 2 files changed: 174 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/440.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/440/head:pull/440 PR: https://git.openjdk.java.net/jfx/pull/440 From fkirmaier at openjdk.java.net Wed Mar 24 15:02:54 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 24 Mar 2021 15:02:54 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing Message-ID: Fixing ListCell editing status is true, when index changes while editing. ------------- Commit messages: - 8264127: Changes: https://git.openjdk.java.net/jfx/pull/441/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264127 Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Wed Mar 24 15:06:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 15:06:48 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 14:30:56 GMT, Ambarish Rapte wrote: >> The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. >> Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). >> >> Fix is to remove the listener when MenuItem is removed. >> Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. >> Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. >> With fix, the count is always same as number of MenuItems in scenegraph. >> >> Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. >> This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. >> Added a comment explaining this behavior in place of the TODO. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct test The fix looks good. The test looks OK as far as it goes, although I note that it is testing for the leak in an indirect way, since it looks at the `changeListenerMap` rather than checking the listeners of `menuitem.acceleratorProperty()` which is what we really care about. Is there a way to test it more directly? If not then I think this is fine. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlAcceleratorSupportTest.java line 46: > 44: public static void setup() throws Exception { > 45: for (int i = 0; i < 4; i++) { > 46: System.gc(); Maybe call `System.runFinalization()`, too? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/429 From github.com+12087024+beldenfox at openjdk.java.net Wed Mar 24 18:20:40 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Wed, 24 Mar 2021 18:20:40 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <4DMGohjcVKz0vg0kZq0Qs7e5X1mQfkahhQGd1WerBS0=.b7e4fb1a-8984-4ed2-bde9-5a4070501086@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> <4DMGohjcVKz0vg0kZq0Qs7e5X1mQfkahhQGd1WerBS0=.b7e4fb1a-8984-4ed2-bde9-5a4070501086@github.com> Message-ID: On Tue, 16 Mar 2021 19:48:56 GMT, Martin Fox wrote: >> Maybe this is a very dumb idea but why are we not using the char to map back to the keycode? At least for everything in the ASCII-Range this would be ok not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) first. So once we checked and the text is of length 1 we could do the mapping from the char. > > The Function/arrow/number pad keys are handled using a hard-coded table since they don?t vary based on keyboard layout. Beyond that you?re asking exactly the right question. > > JavaFX KeyCodes seem to be modeled on similar systems present in Windows and X11. On these platforms the system assigns a key code to each key which remains stable regardless of the modifier state. The system tries to ensure that codes for A-Z and 0-9 are assigned to keys even on keyboards that don?t generate Latin characters. > > My implementation is conservative in that it?s trying to emulate the behavior of Windows and X11 and associate each key with a stable code including A-Z and 0-9. On the Mac that has no real utility when it comes to accelerator matching, we could use the character information in the event to generate the JavaFX key code and still match user?s expectations. But that would break other JavaFX assumptions, like that the key code is stable. Take the =/+ key on the US keyboard as an example. If Cmd is not held down it will generate = or + depending on the shift state and so vary between KeyCode.EQUALS and KeyCode.PLUS. And key events for non-Latin characters would have an UNDEFINED KeyCode until Cmd was held down and we got a useable ASCII character. > > I have no idea if these deviations from the original design would be an issue. At this point I?m pretty sure that any problems would lie outside accelerator processing e.g. with the Robot. > > P.S. What I would not do is what Swing is trying, namely to emulate Windows (stable codes, A-Z present, etc.) using just the NSEvent character information and heuristics. That?s generating all sorts of oddness under the hood. Better to generate UNDEFINED KeyCodes than bad guesses. I've written a command line utility that runs through all the keyboard layouts available in macOS 11.2.3 and generates a report on how this PR would change the Java key codes for each layout. I used it to spot-check the behavior on various layouts and to flag potential trouble spots (like Lithuanian where digits are typed using a dead key.) I thought it would also be useful for this review. For example, I can now say that with this PR Meta-, (comma) will still be available on all layouts. If the report would be of interest where should I put it? Add it to this PR, attach it to a comment in this thread, put it someplace public and link to it? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From jose.pereda at gluonhq.com Wed Mar 24 19:07:37 2021 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Wed, 24 Mar 2021 20:07:37 +0100 Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> References: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> Message-ID: I've done a quick test and it looks good to me, however I'm still on macOS 10.15.6. I've tried a virtual keyboard with both Spanish and with Chinese input, and I could verify that the change produces the same jStr result as before. However I'm not sure if I can try those extended emoji characters? On Wed, Mar 24, 2021 at 1:13 PM Kevin Rushforth wrote: > On Sun, 21 Mar 2021 04:13:48 GMT, Hsiafan 1498664+hsiafan at openjdk.org> wrote: > > > The convertNSStringToJString function convert NSString to Java String > using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix > using UTF-16 encoding for converting. > > I'll review this. The fix seems fine at first glance. With your patch it > uses a similar mechanism to the attributed string case; I'm curious why > copying the string is needed in that case, but not in this case. > > What testing have you done to ensure that this will not cause any > regressions? > > Perhaps @prrace or @jperedadnr or @johanvos could be a second reviewer? > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/436 > -- From jgneff at openjdk.java.net Wed Mar 24 19:45:55 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 24 Mar 2021 19:45:55 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v2] In-Reply-To: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: > This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: > > * [JDK-8262236][1]: Configure Gradle checksum verification > * [JDK-8263204][2]: Add Gradle Wrapper Validation Action > * [JDK-8264010][3]: Add Gradle dependency verification > > "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: > > * [C?dric Champeau at Devoxx][6] in November 2019 > * [Louis Jacomet at Jfokus][7] in February 2020 > > "We all run in a crazy-unsafe environment," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 > [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https://youtu.be/GWGNp3a3hpk > [7]: https://youtu.be/bwiafNatsf0 John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Add a README file and update 'UPDATING-lucene.txt' ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/437/files - new: https://git.openjdk.java.net/jfx/pull/437/files/2a11d401..c7ac7f62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=437&range=00-01 Stats: 53 lines in 2 files changed: 41 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/437/head:pull/437 PR: https://git.openjdk.java.net/jfx/pull/437 From kevin.rushforth at oracle.com Wed Mar 24 19:47:55 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Mar 2021 12:47:55 -0700 Subject: Result: New OpenJFX Committer: Jose Pereda Message-ID: Voting for John Neffenger [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#jgneff [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-March/029150.html From kevin.rushforth at oracle.com Wed Mar 24 19:48:38 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Mar 2021 12:48:38 -0700 Subject: Result: New OpenJFX Committer: John Neffenger Message-ID: <5b8b1fa1-af47-4571-e708-f7462b7266e4@oracle.com> [corrected subject line] Voting for John Neffenger [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#jgneff [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-March/029150.html From kevin.rushforth at oracle.com Wed Mar 24 19:51:23 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Mar 2021 12:51:23 -0700 Subject: Result: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: Please ignore this, as Jose Pereda is already a Committer in the OpenJFX Project. I resent the results email with the correct subject line. -- Kevin From jgneff at openjdk.java.net Wed Mar 24 19:52:45 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 24 Mar 2021 19:52:45 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> Message-ID: <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> On Tue, 23 Mar 2021 12:07:48 GMT, Kevin Rushforth wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > This seems like a good idea to do. I have a couple overall questions before reviewing / testing. > > 1. Can you add some sort of README file that describes the how to update the checksums? Also, the instructions in [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt) should be updated accordingly. > 2. Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? Thanks, Kevin. I added a README file and updated the Lucene instructions, as you suggested. I'm open to any other suggestions on the wording or formatting, no matter how minor. > Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? The Gradle command, now documented in the `gradle/README.txt` file, adds entries to the dependency verification file for all dependencies, including transitive ones. I think that's the list of everything downloaded during the builds on Linux, macOS, and Windows. I'll clear the Gradle cache and double-check it now. I'll let you know if I find anything unexpected. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Wed Mar 24 19:57:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 19:57:39 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: On Wed, 24 Mar 2021 19:50:11 GMT, John Neffenger wrote: >> This seems like a good idea to do. I have a couple overall questions before reviewing / testing. >> >> 1. Can you add some sort of README file that describes the how to update the checksums? Also, the instructions in [UPDATING-lucene.txt](https://github.com/openjdk/jfx/blob/master/apps/samples/Ensemble8/UPDATING-lucene.txt) should be updated accordingly. >> 2. Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? > > Thanks, Kevin. I added a README file and updated the Lucene instructions, as you suggested. I'm open to any other suggestions on the wording or formatting, no matter how minor. > >> Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? > > The Gradle command, now documented in the `gradle/README.txt` file, adds entries to the dependency verification file for all dependencies, including transitive ones. I think that's the list of everything downloaded during the builds on Linux, macOS, and Windows. I'll clear the Gradle cache and double-check it now. I'll let you know if I find anything unexpected. Thanks for providing / updating the instructions. My internal test build failed right off the bat, since we have a supplemental closed gradle file that augments the build and downloads additional build tools for our internal CI machines. I don't yet know to handle this, since there is a single, global `validation.xml` file and no way that I know of to supplement this. This validation file must contain all artifacts that gradle downloads (and their transitive dependencies). From the gradle docs: > A dependency verification configuration is global: a single file is used to configure verification of the whole build. In particular, the same file is used for both the (sub)projects and buildSrc. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From nlisker at openjdk.java.net Wed Mar 24 20:38:10 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 24 Mar 2021 20:38:10 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v12] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Restored PointLight test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/026ce1b9..ce075b22 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=10-11 Stats: 430 lines in 3 files changed: 258 ins; 161 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From jgneff at openjdk.java.net Wed Mar 24 21:08:40 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 24 Mar 2021 21:08:40 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: <-iLAgYV0zYRBLJ3VMKWGWhji3nNzx11EKLy_tVOjMIU=.82715fe8-b9e1-4f6a-86b7-e8b9db7f25b5@github.com> On Wed, 24 Mar 2021 19:55:20 GMT, Kevin Rushforth wrote: > I don't yet know to handle this ... Would any of the following options work? 1. If you're using your own supplemental closed Gradle build file, create your own supplemental closed Gradle verification file, too. Before the internal build, replace the current file with your own. 2. Remove the verification file before running your internal build. In this case, though, you'll also lose its protection against software supply-chain attacks. 3. Add your internal dependency checksum entries to the public verification file and publish the updated file in the repository. I think the protection from the verification file is worth having as a default in the public repository. Gluon, Oracle, BellSoft, and anyone else building JavaFX can decide, based on their own security assessment, whether or not they want to use it. The point of including the file in the repository is to make that decision explicit. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From kcr at openjdk.java.net Wed Mar 24 21:33:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 21:33:40 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: <-iLAgYV0zYRBLJ3VMKWGWhji3nNzx11EKLy_tVOjMIU=.82715fe8-b9e1-4f6a-86b7-e8b9db7f25b5@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> <-iLAgYV0zYRBLJ3VMKWGWhji3nNzx11EKLy_tVOjMIU=.82715fe8-b9e1-4f6a-86b7-e8b9db7f25b5@github.com> Message-ID: On Wed, 24 Mar 2021 21:06:08 GMT, John Neffenger wrote: >> Thanks for providing / updating the instructions. >> >> My internal test build failed right off the bat, since we have a supplemental closed gradle file that augments the build and downloads additional build tools for our internal CI machines. >> >> I don't yet know to handle this, since there is a single, global `validation.xml` file and no way that I know of to supplement this. This validation file must contain all artifacts that gradle downloads (and their transitive dependencies). From the gradle docs: >> >>> A dependency verification configuration is global: a single file is used to configure verification of the whole build. In particular, the same file is used for both the (sub)projects and buildSrc. > >> I don't yet know to handle this ... > > Would any of the following options work? > > 1. If you're using your own supplemental closed Gradle build file, create your own supplemental closed Gradle verification file, too. Before the internal build, replace the current file with your own. > 2. Remove the verification file before running your internal build. In this case, though, you'll also lose its protection against software supply-chain attacks. > 3. Add your internal dependency checksum entries to the public verification file and publish the updated file in the repository. > > I think the protection from the verification file is worth having as a default in the public repository. Gluon, Oracle, BellSoft, and anyone else building JavaFX can decide, based on their own security assessment, whether or not they want to use it. The point of including the file in the repository is to make that decision explicit. The three options you listed are roughly what I had come up with as well. Option 1 would otherwise be ideal, but it would violate the best practice of not writing to an SCM-managed file during the build. If gradle were to provide a way to specify an alternate location -- even if it were a single global file -- then that's what we'd do. I'll check gradle 7 and see if they've added something like this, since we will want to update at some point in the not-too-distant future (so we can support JDK 16 as a boot JDK). Option 2 could be easily achieved by setting system property `org.gradle.dependency.verification` to `lenient|off`. We never download anything from outside our firewall during our CI builds -- we only download pre-verified binaries from our local server. Still, this isn't the ideal situation. What I'd really like is a mode that would verify everything that is in the `validation.xml` file, and warn (but not fail) if an artifact is missing. It would be better than turning it off entirely, but not as good as failing if there are missing dependencies. Option 3 is what I was leaning towards. I'll take a look (not this week, though) at generating the checksums for the internal files and see what it looks like. It's really only cmake (for WebKit build), Ninja (for WebKit build on Windows), and the compiler toolchain "devkit". Unless I'm forgetting something. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From hjohn at xs4all.nl Wed Mar 24 21:49:16 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 24 Mar 2021 22:49:16 +0100 Subject: Proof of concept for fluent bindings for ObservableValue Message-ID: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> I just wanted to draw some attention to a recent proof of concept I made in this pull request: https://github.com/openjdk/jfx/pull/434 It is based on the work I did in https://github.com/hjohn/hs.jfx.eventstream which is in part based on work done in ReactFX by Tomas Mikula. The PR itself however shares no code with ReactFX and is completely written by me. If there is interest, I'm willing to invest more time in smoothing out the API and documentation, investigating further how this would interact with the primitive types and adding unit test coverage (I have extensive tests, but thesea are written in JUnit 5, so they would require conversion or JavaFX could move to support JUnit 5). What follows below is the text of the PR for easy reading. Feedback is appreciated. ================ This is a proof of concept of how fluent bindings could be introduced to JavaFX. The main benefit of fluent bindings are ease of use, type safety and less surprises. Features: Flexible Mappings Map the contents of a property any way you like with map, or map nested properties with flatMap. Lazy The bindings created are lazy, which means they are always invalid when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as Node without listeners being created when the binding itself is not used (this would allow for the inclusion of a treeShowingProperty in Node without creating excessive listeners, see this fix I did in an earlier PR: #185) Null Safe The map and flatMap methods are skipped, similar to java.util.Optional when the value they would be mapping is null. This makes mapping nested properties with flatMap trivial as the null case does not need to be taken into account in a chain like this: node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). Instead a default can be provided with orElse or orElseGet. Conditional Bindings Bindings can be made conditional using the conditionOn method. A conditional binding retains its last value when its condition is false. Conditional bindings donot observe their source when the condition is false, allowing developers to automatically stop listening to properties when a certain condition is met. A major use of this feature is to have UI components that need to keep models updated which may outlive the UI conditionally update the long lived model only when the UI is showing. Some examples: void mapProperty() { // Standard JavaFX: label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); // Fluent: much more compact, no need to handle null label.textProperty().bind(text.map(String::toUpperCase)); } void calculateCharactersLeft() { // Standard JavaFX: label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); // Fluent: slightly more compact and more clear (no negate needed) label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); } void mapNestedValue() { // Standard JavaFX: label.textProperty().bind(Bindings.createStringBinding( () -> employee.get() == null ? "" : employee.get().getCompany() == null ? "" : employee.get().getCompany().getName(), employee )); // Fluent: no need to handle nulls everywhere label.textProperty().bind( employee.map(Employee::getCompany) .map(Company::getName) .orElse("") ); } void mapNestedProperty() { // Standard JavaFX: label.textProperty().bind( Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) .then("Visible") .otherwise("Not Visible") ); // Fluent: type safe label.textProperty().bind(label.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .map(showing -> showing ? "Visible" : "Not Visible") ); } void updateLongLivedModelWhileAvoidingMemoryLeaks() { // Standard JavaFX: naive, memory leak; UI won't get garbage collected listView.getSelectionModel().selectedItemProperty().addListener( (obs, old, current) -> longLivedModel.lastSelectedProperty().set(current) ); // Standard JavaFX: no leak, but stops updating after a while listView.getSelectionModel().selectedItemProperty().addListener( new WeakChangeListener<>( (obs, old, current) -> longLivedModel.lastSelectedProperty().set(current) ) ); // Standard JavaFX: fixed version listenerReference = (obs, old, current) -> longLivedModel.lastSelectedProperty().set(current); listView.getSelectionModel().selectedItemProperty().addListener( new WeakChangeListener<>(listenerReference) ); // Fluent: naive, memory leak... fluent won't solve this... listView.getSelectionModel().selectedItemProperty() .subscribe(longLivedModel.lastSelectedProperty()::set); // Fluent: conditional update when control visible // Create a property which is only true when the UI is visible: ObservableValue showing = listView.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false); // Use showing property to automatically disconnect long lived model // allowing garbage collection of the UI: listView.getSelectionModel().selectedItemProperty() .conditionOn(showing) .subscribe(longLivedModel.lastSelectedProperty()::set); // Note that the 'showing' property can be provided in multiple ways: // - create manually (can be re-used for multiple bindings though) // - create with a helper: Nodes.showing(Node node) -> ObservableValue // - make it part of the Node class; as the fluent bindings only bind themselves // to their source when needed (lazy binding), this won't create overhead // for each node in the scene } Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. --John From kcr at openjdk.java.net Wed Mar 24 22:02:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 22:02:37 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> <4DMGohjcVKz0vg0kZq0Qs7e5X1mQfkahhQGd1WerBS0=.b7e4fb1a-8984-4ed2-bde9-5a4070501086@github.com> Message-ID: <6TZ5-DxE6HC8Da5xN3_upn8nXtdM21NiPhdgVgsWEIA=.c8db34d4-b49d-4124-a43e-a2cfe05d9ed3@github.com> On Wed, 24 Mar 2021 18:17:59 GMT, Martin Fox wrote: >> The Function/arrow/number pad keys are handled using a hard-coded table since they don?t vary based on keyboard layout. Beyond that you?re asking exactly the right question. >> >> JavaFX KeyCodes seem to be modeled on similar systems present in Windows and X11. On these platforms the system assigns a key code to each key which remains stable regardless of the modifier state. The system tries to ensure that codes for A-Z and 0-9 are assigned to keys even on keyboards that don?t generate Latin characters. >> >> My implementation is conservative in that it?s trying to emulate the behavior of Windows and X11 and associate each key with a stable code including A-Z and 0-9. On the Mac that has no real utility when it comes to accelerator matching, we could use the character information in the event to generate the JavaFX key code and still match user?s expectations. But that would break other JavaFX assumptions, like that the key code is stable. Take the =/+ key on the US keyboard as an example. If Cmd is not held down it will generate = or + depending on the shift state and so vary between KeyCode.EQUALS and KeyCode.PLUS. And key events for non-Latin characters would have an UNDEFINED KeyCode until Cmd was held down and we got a useable ASCII character. >> >> I have no idea if these deviations from the original design would be an issue. At this point I?m pretty sure that any problems would lie outside accelerator processing e.g. with the Robot. >> >> P.S. What I would not do is what Swing is trying, namely to emulate Windows (stable codes, A-Z present, etc.) using just the NSEvent character information and heuristics. That?s generating all sorts of oddness under the hood. Better to generate UNDEFINED KeyCodes than bad guesses. > > I've written a command line utility that runs through all the keyboard layouts available in macOS 11.2.3 and generates a report on how this PR would change the Java key codes for each layout. I used it to spot-check the behavior on various layouts and to flag potential trouble spots (like Lithuanian where digits are typed using a dead key.) I thought it would also be useful for this review. For example, I can now say that with this PR Meta-, (comma) will still be available on all layouts. > > If the report would be of interest where should I put it? Add it to this PR, attach it to a comment in this thread, put it someplace public and link to it? I guess it depends on how large the table is. Adding it as an inline table using markdown could be helpful, unless it is so large that it takes too long to scroll past it. In that case, I'd probably recommend attaching it to a comment in the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Wed Mar 24 22:50:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 22:50:41 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <3DPMO4Wp3At7A1RrZdT8GSw594DOJbIKbV6zIlqFXMQ=.38f8e10f-771c-426e-83c0-5a5e7847fd02@github.com> On Tue, 23 Mar 2021 15:18:06 GMT, Kevin Rushforth wrote: >> wondering about the sequence of next steps: should I create the csr before or after (partial) review of this? Doing before feels like expecting duplicate work (whenever doc changes are required, I'll have to change the code in the pr and the csr draft as well, I assume). If that's the way, I'll go it, naturally :) > > I'll review the API changes in the next day or so. Then you can update the CSR and move to Proposed. I'll also ask Ambarish to be the second reviewer on this. The API looks good to me, so go ahead and create a Draft CSR (go to your JBS issue and select "More --> Create CSR"). I don't think it will change much, if any, so you won't be duplicating work. Since you are adding new methods to an existing class, you can use the format from [JDK-8259868](https://bugs.openjdk.java.net/browse/JDK-8259868) for the Specification section, just listing the new methods and their API docs, rather than diffs, which would be needed if changing existing javadoc comments. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Wed Mar 24 23:41:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Mar 2021 23:41:40 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <-6Tu_Q1VN3A5ZURtTigsIOT6Q2vgllZo2mYIuw5cmZA=.14408107-1821-4255-b1b3-67d94f63642b@github.com> On Tue, 9 Mar 2021 22:20:10 GMT, John Neffenger wrote: > This is a continuation of the [pull request][1] started by @bmwiedemann in January 2020. After this change is integrated, I can follow up immediately with additional pull requests that get us much closer to providing fully reproducible builds. > > #### Motivation > > The only conclusive way to verify a software package is to reproduce it. That's the main point of the Linux Foundation article [Preventing Supply Chain Attacks like SolarWinds][2] by David Wheeler, Director of Open Source Supply Chain Security. "In the longer term," he writes, "I know of only one strong countermeasure for this kind of attack: verified reproducible builds." > > It's not enough anymore to trust the person, organization, or company that publishes a software package. David Wheeler explains, "Assuming a system can 'never be broken into' is a failing strategy." As I see it, any project that doesn't yet allow for reproducible builds is on a list of possible attack vectors. I'd like to get OpenJFX off that list. > > This is a huge undertaking involving the entire open-source community. Just [Debian, for example][3], has over 30,000 source packages to build in a reproducible manner. Remarkably, it's almost 96 percent complete. The OpenJFX package is one of three percent still failing. Our first step towards helping in this goal is to support the [`SOURCE_DATE_EPOCH` specification][4]. > > #### Implementation > > When you want to build 30,000 packages in a reproducible manner, [command-line flags][5] unique to each package aren't so helpful. The environment variable needs to be set, anyway, for the tools invoked by Gradle to pick it up. We could allow for a Gradle property in addition to the environment variable. The Gradle property would override the default current date and export the environment variable, and the environment variable would override the command-line property. I think it makes more sense in the OpenJFX build to support the environment variable directly. > > With these considerations, I added the support just as recommended by the example for "Java / gradle" on the Reproducible Builds [`SOURCE_DATE_EPOCH`][6] page. For comparison, the [OpenJDK build][7] does the reverse, using the *configure* script option `--with-source-date` to export the `SOURCE_DATE_EPOCH` environment variable. > > [1]: https://github.com/openjdk/jfx/pull/99 > [2]: https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds > [3]: https://tests.reproducible-builds.org/debian/reproducible.html > [4]: https://reproducible-builds.org/specs/source-date-epoch/ > [5]: https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables#More_detailed_discussion > [6]: https://reproducible-builds.org/docs/source-date-epoch/ > [7]: https://github.com/openjdk/jdk/commit/1a16a4b6 This looks good to me. I tested it and it does what I would expect. I generally prefer gradle properties to env vars, but supporting the `SOURCE_DATE_EPOCH` env variable directly makes sense for the reasons you pointed out. We could always add a property later to override it, but I suspect we won't ever feel the need to do that. > @jgneff Could not parse `bmwiedemann` as a valid contributor. You might retry the "contributor" command with the `@` before their GitHub username (I'm not 100% sure that will work, though). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/422 From nlisker at openjdk.java.net Wed Mar 24 23:55:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 24 Mar 2021 23:55:43 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: On Tue, 23 Feb 2021 12:06:08 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing/incorrect @since tags in new api doc I reviewed only the public API methods. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LambdaMultiplePropertyChangeListenerHandler.java line 63: > 61: */ > 62: public final class LambdaMultiplePropertyChangeListenerHandler { > 63: // FIXME: name doesn't fit after widening to support more notification event types Maybe `MultipleObservableListenersHandler`? I didn't look at the class too much. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 250: > 248: * > 249: * @param observable the observable to observe for invalidation events > 250: * @param consumer the consumer Could be just me because I'm unfamiliar with this API, but I'd like to see an explanation for what the consumer is used for. If the consumer is executed on invalidation events on this observable, then clearly state it. Maybe the doc could be something like: Registers an action to take when an {@code Observable} is invalidated. An {@code InvalidationListener} is registered on the given {@code observable} and the {@code consumer} is run whenever the listener sends an invalidation event. If multiple consumers are registered on the same observable, they are run in the order in which they were registered. @param observable the observable to observe for invalidation events @param consumer the action to take when the observable is invalidated Since it's a `protected final` method, I don't think that the "Subclasses can use this..." portion is necessary - that's the only use of these methods. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 253: > 251: * @since 17 > 252: */ > 253: protected final void registerInvalidationListener(Observable observable, Consumer consumer) { Can either of the arguments be `null`? Should there be an `Objects#RequireNonNull` check(s)? modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 264: > 262: * {@link #registerInvalidationListener(Observable, Consumer)} > 263: * for the given observable. The end result is that the given observable is no longer observed by any of the invalidation > 264: * listeners, but it may still have additional listeners registered on it through means outside of Maybe instead of "The end result..." something like: Only listeners that were registered using the aforementioned method are removed; listeners registered through other means are unaffected. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 267: > 265: * {@link #registerInvalidationListener(Observable, Consumer)}. > 266: * > 267: * @param observable The observable for which all listeners should be removed. Maybe not "all listeners", but "the listeners". Will be less confusing and in line with the method description. Also, the style is to use lowercase for the first word and no period at the end. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 268: > 266: * > 267: * @param observable The observable for which all listeners should be removed. > 268: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through 1. There's no need for a `@link` on a class that is in the arguments or return of the method since they are linked there anyway, and it is recommended to use `@link` only the first time the class appears. 2. You might want to clarify that by "chained" you mean that they were composed using `Consumer#andThen`, either using `@plainlink` on "chained", or explicitly by "chained using Consumer#andThen`. Then again, it might be obvious. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: > 268: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through > 269: * {@link #registerInvalidationListener(Observable, Consumer)}. If no consumers have been registered on this > 270: * property, null will be returned. "null" --> `{@code null}` "property" --> "observable" modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 273: > 271: * @since 17 > 272: */ > 273: protected final Consumer unregisterInvalidationListeners(Observable observable) { Is `null` check on `observable` needed? modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 290: > 288: * @since 17 > 289: */ > 290: protected final void registerListChangeListener(ObservableList observableList, Consumer> consumer) { Same comments as for the invalidation method. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 311: > 309: * @since 17 > 310: */ > 311: protected final Consumer> unregisterListChangeListeners(ObservableList observableList) { Same comments as for the invalidation method. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at openjdk.java.net Thu Mar 25 00:57:40 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 00:57:40 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Mon, 22 Mar 2021 23:55:34 GMT, Kevin Rushforth wrote: > I the rotation needs to apply to whatever the direction vector is: whether that's implicitly (0,0,1) if we don't provide a separate direction vector or whether it's the user provided direction vector, it would be odd to ignore transforms if you set the vector. I see, so we compose the transforms on top of the direction vector. It's an option indeed. > If we don't provide a vector, we could always add it later if people ask for it, so maybe it is better to leave it off if we aren't sure. > > The question then becomes how easy is it to modify the direction vector using the node transforms? Yes, the ease of use is the issue I brought up initially with this approach. The rotation transforms are non-commutable, so it's going to be unintuitive for complex operations. A look-at method could be very useful not only in this case, but for any node in a 3D scene (or even 2D). Do you think that this is a worthy addition? ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Thu Mar 25 01:58:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 01:58:04 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v13] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Corrected light direction in the es2 pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/ce075b22..7c36639e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=11-12 Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Thu Mar 25 02:04:43 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 02:04:43 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Thu, 25 Mar 2021 00:54:33 GMT, Nir Lisker wrote: >>> I would like to allow a developer to achieve a functionality like is shown in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are intuitive there. If we allow both rotation transforms and a direction, wouldn't that cause the direction to be unintuitive? Or do you mean that the direction is always the look-at regardless of rotation transforms and if it's `null` then the rotations take over? >> >> I the rotation needs to apply to whatever the direction vector is: whether that's implicitly (0,0,1) if we don't provide a separate direction vector or whether it's the user provided direction vector, it would be odd to ignore transforms if you set the vector. >> >> If we don't provide a vector, we could always add it later if people ask for it, so maybe it is better to leave it off if we aren't sure. >> >> The question then becomes how easy is it to modify the direction vector using the node transforms? >> >>> > On Mac I no longer get a GLSL shader error at runtime, but spotlights aren't working correctly, either. >>> >>> I don't see this on Linux and I don't have a Mac. Can you try on Linux and see what you get? If Linux works, I'm afraid I would not be able to debug the Mac. >> >> It's broken on Linux, too -- more so, since there is no lighting most of the time. > >> I the rotation needs to apply to whatever the direction vector is: whether that's implicitly (0,0,1) if we don't provide a separate direction vector or whether it's the user provided direction vector, it would be odd to ignore transforms if you set the vector. > > I see, so we compose the transforms on top of the direction vector. It's an option indeed. > >> If we don't provide a vector, we could always add it later if people ask for it, so maybe it is better to leave it off if we aren't sure. >> >> The question then becomes how easy is it to modify the direction vector using the node transforms? > > Yes, the ease of use is the issue I brought up initially with this approach. The rotation transforms are non-commutable, so it's going to be unintuitive for complex operations. A look-at method could be very useful not only in this case, but for any node in a 3D scene (or even 2D). Do you think that this is a worthy addition? I think I corrected the GL pipeline issue. The dot product should have used the negative light direction. It worked for me because I was testing in the -1 z direction instead of the +1. I still don't know why Mac and Linux would have given different results. This is what I get after the commit: ![Screenshot from 2021-03-25 03-59-57](https://user-images.githubusercontent.com/37422899/112407458-c941cc80-8d1e-11eb-85c2-468508e5018a.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jgneff at openjdk.java.net Thu Mar 25 02:37:39 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 25 Mar 2021 02:37:39 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: <-6Tu_Q1VN3A5ZURtTigsIOT6Q2vgllZo2mYIuw5cmZA=.14408107-1821-4255-b1b3-67d94f63642b@github.com> References: <-6Tu_Q1VN3A5ZURtTigsIOT6Q2vgllZo2mYIuw5cmZA=.14408107-1821-4255-b1b3-67d94f63642b@github.com> Message-ID: On Wed, 24 Mar 2021 23:39:21 GMT, Kevin Rushforth wrote: > You might retry the "contributor" command with the `@` before their GitHub username. Thanks. I'll try that now. I checked and Bernhard is on the list of "OCAs submitted prior to 2021," but not on the OpenJDK Census list, in case that matters. By the way, should I be adding my own name, too? It looks as if sometimes people do that and sometimes not. That would put me as "Author" and also on a line with "Co-authored-by" in the commit message. ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From github.com+1498664+hsiafan at openjdk.java.net Thu Mar 25 03:20:41 2021 From: github.com+1498664+hsiafan at openjdk.java.net (Hsiafan) Date: Thu, 25 Mar 2021 03:20:41 GMT Subject: RFR: JDK-8258381 : [macos] Exception when input emoji using Chinese input method In-Reply-To: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> References: <5E9pnxme_BB3V0mKbjtppP-pAGvE05e5CCyA6Mt8DXM=.d148de57-434e-438d-85bd-e4d8e6ab4686@github.com> Message-ID: <75_kkdXsJ_j-xQ59icTOdZQlm2uOGdpa63J7cLOMabc=.e3a47368-bf1a-4e02-a95b-617f558469e1@github.com> On Wed, 24 Mar 2021 12:09:27 GMT, Kevin Rushforth wrote: >> The convertNSStringToJString function convert NSString to Java String using NewStringUTF?NewStringUTF accept modified-UTF8 encoded str?This fix using UTF-16 encoding for converting. > > I'll review this. The fix seems fine at first glance. With your patch it uses a similar mechanism to the attributed string case; I'm curious why copying the string is needed in that case, but not in this case. > > What testing have you done to ensure that this will not cause any regressions? > > Perhaps @prrace or @jperedadnr or @johanvos could be a second reviewer? I've test on macOS 11.2.3 with Chinese input method, including ascii chars, CJK chars, emojis, and inputing ascii/cjk chars+emojis together. All works as expected. The memory allocation in NSAttributedString could be eliminated either, AFAIK. I haven't tested it, do not know how to input a NSAttributedString. ------------- PR: https://git.openjdk.java.net/jfx/pull/436 From john at status6.com Thu Mar 25 04:37:15 2021 From: john at status6.com (John Neffenger) Date: Wed, 24 Mar 2021 21:37:15 -0700 Subject: E-mail addresses at openjdk.org Message-ID: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> I noticed that my last commit used the address jgneff at openjdk.org instead of the address I normally use to create and sign commits. GitHub didn't recognize the commit as mine until I added the address to my account. Do the openjdk.org addresses receive e-mail? If not, do we just leave the address unverified in our GitHub accounts? Thanks, John From kevin.rushforth at oracle.com Thu Mar 25 11:12:05 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Mar 2021 04:12:05 -0700 Subject: E-mail addresses at openjdk.org In-Reply-To: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> References: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> Message-ID: Eventually the openjdk.org addresses will be live. I haven't heard a recent update on the timing for this. Until then, adding the email address as an unverified additional email address in your GitHub profile is the way to go. -- Kevin On 3/24/2021 9:37 PM, John Neffenger wrote: > I noticed that my last commit used the address jgneff at openjdk.org > instead of the address I normally use to create and sign commits. > GitHub didn't recognize the commit as mine until I added the address > to my account. > > Do the openjdk.org addresses receive e-mail? If not, do we just leave > the address unverified in our GitHub accounts? > > Thanks, > John From fastegal at openjdk.java.net Thu Mar 25 11:27:40 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Mar 2021 11:27:40 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:53:24 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > I reviewed only the public API methods. @nlisker thanks for the detailed doc review - I really like your suggestions, which I think are considerable improvements (I did part of it in the respective methods of the handler) over the original doc :) Because that's what the doc of the new methods are: c&p from the un/registerChangeListener javadoc, adjusted to the specific type of the listener. For consistency, all related method doc should be improved along your lines. How to get there? Options - use old doc with new methods, leave improving the doc for all methods to a follow-up issue - keep old doc for old method, use improved doc for the new methods, leave improving the doc for the old method to a follow-up issue - use improved doc in old and new methods in this issue, changing the old Last would be doing it right once and for all .. my reluctant (against my lazy self ;) preference would be the last. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Thu Mar 25 11:46:42 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Mar 2021 11:46:42 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 14:58:40 GMT, Florian Kirmaier wrote: > Fixing ListCell editing status is true, when index changes while editing. good catch, yet another property that's not correctly updated on index change :) Quick questions: - what are the macroscopic effects (that is in a running list) that you see without fixing it? - do we want mere cell re-use fire a editCancel? (which the list seems to ignore in the test, don't know why) ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From jvos at openjdk.java.net Thu Mar 25 12:06:52 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 25 Mar 2021 12:06:52 GMT Subject: RFR: 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Message-ID: Fix for JDK-8211362 Compile javafx-iio native files with -f-visibiliy=hidden in order not to export the non-JNI symbols. Although this issue was about libjavafx_iio.so only (and not about libjavafx_iio.a), this PR allows fixing the static build as well. For static builds, we also use ld -r to build a static library, so that objcopy or similar can be used to remove the names of the hidden symbols. ------------- Commit messages: - remove trailing whitespace - Fix for JDK-8211362 Changes: https://git.openjdk.java.net/jfx/pull/442/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=442&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211362 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/442.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/442/head:pull/442 PR: https://git.openjdk.java.net/jfx/pull/442 From kcr at openjdk.java.net Thu Mar 25 12:34:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 12:34:51 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket Message-ID: Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. ------------- Commit messages: - 8264162: PickResult.toString() is missing the closing square bracket Changes: https://git.openjdk.java.net/jfx/pull/443/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=443&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264162 Stats: 33 lines in 2 files changed: 33 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/443.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/443/head:pull/443 PR: https://git.openjdk.java.net/jfx/pull/443 From kcr at openjdk.java.net Thu Mar 25 12:48:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 12:48:40 GMT Subject: RFR: 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 12:02:25 GMT, Johan Vos wrote: > Fix for JDK-8211362 > > Compile javafx-iio native files with -f-visibiliy=hidden in order > not to export the non-JNI symbols. > Although this issue was about libjavafx_iio.so only (and not about libjavafx_iio.a), this PR allows fixing the static build as well. > > For static builds, we also use ld -r to build a static library, so that objcopy or similar can be used to remove the names of the > hidden symbols. Looks good. Test build passed. I confirmed that the internal jpeg symbols are now hidden. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/442 From jvos at openjdk.java.net Thu Mar 25 13:08:38 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 25 Mar 2021 13:08:38 GMT Subject: Integrated: 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 12:02:25 GMT, Johan Vos wrote: > Fix for JDK-8211362 > > Compile javafx-iio native files with -f-visibiliy=hidden in order > not to export the non-JNI symbols. > Although this issue was about libjavafx_iio.so only (and not about libjavafx_iio.a), this PR allows fixing the static build as well. > > For static builds, we also use ld -r to build a static library, so that objcopy or similar can be used to remove the names of the > hidden symbols. This pull request has now been integrated. Changeset: ed5cfe72 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/ed5cfe72 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod 8211362: Restrict export of libjpeg symbols from libjavafx_iio.so Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/442 From nlisker at openjdk.java.net Thu Mar 25 13:17:38 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 13:17:38 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> On Thu, 25 Mar 2021 11:25:18 GMT, Jeanette Winzenburg wrote: >> I reviewed only the public API methods. > > @nlisker thanks for the detailed doc review - I really like your suggestions, which I think are considerable improvements (I did part of it in the respective methods of the handler) over the original doc :) Because that's what the doc of the new methods are: c&p from the un/registerChangeListener javadoc, adjusted to the specific type of the listener. > > For consistency, all related method doc should be improved along your lines. How to get there? Options > > - use old doc with new methods, leave improving the doc for all methods to a follow-up issue > - keep old doc for old method, use improved doc for the new methods, leave improving the doc for the old method to a follow-up issue > - use improved doc in old and new methods in this issue, changing the old > > Last would be doing it right once and for all .. my reluctant (against my lazy self ;) preference would be the last. Can you list the other affected methods? ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From jvos at openjdk.java.net Thu Mar 25 13:24:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 25 Mar 2021 13:24:45 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 12:29:38 GMT, Kevin Rushforth wrote: > Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. Good catch. Test fails before and succeeds after the patch. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/443 From fastegal at openjdk.java.net Thu Mar 25 13:32:05 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Mar 2021 13:32:05 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> Message-ID: On Thu, 25 Mar 2021 13:14:45 GMT, Nir Lisker wrote: > > > Can you list the other affected methods? at line 211 (in the changed skinBase) /** * Subclasses can invoke this method to register that they want to listen to * property change events for the given property. Registered {@link Consumer} instances * will be executed in the order in which they are registered. * @param property the property * @param consumer the consumer */ protected final void registerChangeListener(ObservableValue property, Consumer> consumer) { and at line 255 /** * Unregisters all change listeners that have been registered using {@link #registerChangeListener(ObservableValue, Consumer)} * for the given property. The end result is that the given property is no longer observed by any of the change * listeners, but it may still have additional listeners registered on it through means outside of * {@link #registerChangeListener(ObservableValue, Consumer)}. * * @param property The property for which all listeners should be removed. * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through * {@link #registerChangeListener(ObservableValue, Consumer)}. If no consumers have been registered on this * property, null will be returned. * @since 9 */ protected final Consumer> unregisterChangeListeners(ObservableValue property) { ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at openjdk.java.net Thu Mar 25 13:35:30 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 13:35:30 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: References: Message-ID: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> On Thu, 25 Mar 2021 12:29:38 GMT, Kevin Rushforth wrote: > Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. modules/javafx.graphics/src/main/java/javafx/scene/input/PickResult.java line 204: > 202: } > 203: if (getIntersectedTexCoord() != null) { > 204: sb.append(", texCoord = ").append(getIntersectedTexCoord()); Can you fix the double indentation in the `if` bodies? modules/javafx.graphics/src/test/java/test/javafx/scene/input/MouseEventTest.java line 139: > 137: case ']': > 138: --bracketCount; > 139: assertTrue("Too many closing brackets: " + str, bracketCount >= 0); This test can fail due to a malformed `toString` result in the node (`getIntersectedNode()`), which I would think is outside the scope of this test. In practice, this test's result is dependent on what node I choose to test. Shouldn't we be testing the structure of the string and not its contents? ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From kcr at openjdk.java.net Thu Mar 25 13:49:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 13:49:26 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> References: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> Message-ID: On Thu, 25 Mar 2021 13:18:24 GMT, Nir Lisker wrote: >> Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. > > modules/javafx.graphics/src/main/java/javafx/scene/input/PickResult.java line 204: > >> 202: } >> 203: if (getIntersectedTexCoord() != null) { >> 204: sb.append(", texCoord = ").append(getIntersectedTexCoord()); > > Can you fix the double indentation in the `if` bodies? Sure, as long as I am there, I'll do that. ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From nlisker at openjdk.java.net Thu Mar 25 13:55:30 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 13:55:30 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> Message-ID: <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> On Thu, 25 Mar 2021 13:29:44 GMT, Jeanette Winzenburg wrote: >> Can you list the other affected methods? > >> >> >> Can you list the other affected methods? > > at line 211 (in the changed skinBase) > > /** > * Subclasses can invoke this method to register that they want to listen to > * property change events for the given property. Registered {@link Consumer} instances > * will be executed in the order in which they are registered. > * @param property the property > * @param consumer the consumer > */ > protected final void registerChangeListener(ObservableValue property, Consumer> consumer) { > > > > and at line 255 > > /** > * Unregisters all change listeners that have been registered using {@link #registerChangeListener(ObservableValue, Consumer)} > * for the given property. The end result is that the given property is no longer observed by any of the change > * listeners, but it may still have additional listeners registered on it through means outside of > * {@link #registerChangeListener(ObservableValue, Consumer)}. > * > * @param property The property for which all listeners should be removed. > * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through > * {@link #registerChangeListener(ObservableValue, Consumer)}. If no consumers have been registered on this > * property, null will be returned. > * @since 9 > */ > protected final Consumer> unregisterChangeListeners(ObservableValue property) { I see. I recommend that they be improved in this PR. I don't know if this will need to be part of the CSR, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Mar 25 14:02:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 14:02:30 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> Message-ID: <4mi6BMlAWOXe40fBhwkSH0C8BC59FaNX8SHJlkqZhe8=.26e0f162-7d9d-4672-a6e7-16d5641c6f1d@github.com> On Thu, 25 Mar 2021 13:52:20 GMT, Nir Lisker wrote: >>> >>> >>> Can you list the other affected methods? >> >> at line 211 (in the changed skinBase) >> >> /** >> * Subclasses can invoke this method to register that they want to listen to >> * property change events for the given property. Registered {@link Consumer} instances >> * will be executed in the order in which they are registered. >> * @param property the property >> * @param consumer the consumer >> */ >> protected final void registerChangeListener(ObservableValue property, Consumer> consumer) { >> >> >> >> and at line 255 >> >> /** >> * Unregisters all change listeners that have been registered using {@link #registerChangeListener(ObservableValue, Consumer)} >> * for the given property. The end result is that the given property is no longer observed by any of the change >> * listeners, but it may still have additional listeners registered on it through means outside of >> * {@link #registerChangeListener(ObservableValue, Consumer)}. >> * >> * @param property The property for which all listeners should be removed. >> * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through >> * {@link #registerChangeListener(ObservableValue, Consumer)}. If no consumers have been registered on this >> * property, null will be returned. >> * @since 9 >> */ >> protected final Consumer> unregisterChangeListeners(ObservableValue property) { > > I see. I recommend that they be improved in this PR. I don't know if this will need to be part of the CSR, though. Making this change seems fine to me, and better than using different language in the new methods without fixing the existing. > I don't know if this will need to be part of the CSR, though. It would be best to include them. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at gmail.com Thu Mar 25 14:03:57 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Mar 2021 16:03:57 +0200 Subject: E-mail addresses at openjdk.org In-Reply-To: References: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> Message-ID: What are these email addresses? On Thu, Mar 25, 2021 at 1:12 PM Kevin Rushforth wrote: > Eventually the openjdk.org addresses will be live. I haven't heard a > recent update on the timing for this. Until then, adding the email > address as an unverified additional email address in your GitHub profile > is the way to go. > > -- Kevin > > > On 3/24/2021 9:37 PM, John Neffenger wrote: > > I noticed that my last commit used the address jgneff at openjdk.org > > instead of the address I normally use to create and sign commits. > > GitHub didn't recognize the commit as mine until I added the address > > to my account. > > > > Do the openjdk.org addresses receive e-mail? If not, do we just leave > > the address unverified in our GitHub accounts? > > > > Thanks, > > John > > From fastegal at openjdk.java.net Thu Mar 25 14:10:25 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Mar 2021 14:10:25 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> Message-ID: On Thu, 25 Mar 2021 13:52:20 GMT, Nir Lisker wrote: >>> >>> >>> Can you list the other affected methods? >> >> at line 211 (in the changed skinBase) >> >> /** >> * Subclasses can invoke this method to register that they want to listen to >> * property change events for the given property. Registered {@link Consumer} instances >> * will be executed in the order in which they are registered. >> * @param property the property >> * @param consumer the consumer >> */ >> protected final void registerChangeListener(ObservableValue property, Consumer> consumer) { >> >> >> >> and at line 255 >> >> /** >> * Unregisters all change listeners that have been registered using {@link #registerChangeListener(ObservableValue, Consumer)} >> * for the given property. The end result is that the given property is no longer observed by any of the change >> * listeners, but it may still have additional listeners registered on it through means outside of >> * {@link #registerChangeListener(ObservableValue, Consumer)}. >> * >> * @param property The property for which all listeners should be removed. >> * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through >> * {@link #registerChangeListener(ObservableValue, Consumer)}. If no consumers have been registered on this >> * property, null will be returned. >> * @since 9 >> */ >> protected final Consumer> unregisterChangeListeners(ObservableValue property) { > > I see. I recommend that they be improved in this PR. I don't know if this will need to be part of the CSR, though. @nlisker and @Kevin so we agree, thanks :) my plan: - will work on the exact doc along the lines of Nir's suggestion for the xxInvalidationEvent methods - once that's basically agreed upon, will c&p the spec (with adjustments) to the methods for the other listener types - at a last step, create the csr draft (that would be a patch for the changeListener methods and simply added spec for the new methods, I assume?) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Thu Mar 25 14:18:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 14:18:26 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> References: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> Message-ID: On Thu, 25 Mar 2021 13:32:53 GMT, Nir Lisker wrote: >> Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. > > modules/javafx.graphics/src/test/java/test/javafx/scene/input/MouseEventTest.java line 139: > >> 137: case ']': >> 138: --bracketCount; >> 139: assertTrue("Too many closing brackets: " + str, bracketCount >= 0); > > This test can fail due to a malformed `toString` result in the node (`getIntersectedNode()`), which I would think is outside the scope of this test. In practice, this test's result is dependent on what node I choose to test. > > Shouldn't we be testing the structure of the string and not its contents? On the one hand, I can see your point that it's somewhat tangential that Rectangle has matched brackets, but you could say the same about the Point3D. Here is the result of MouseEvent.toString for the test: MouseEvent [source = javafx.event.Event$$Lambda$110/0x0000000800c52fa8 at 461111c0, target = javafx.event.Event$$Lambda$110/0x0000000800c52fa8 at 461111c0, eventType = MOUSE_PRESSED, consumed = false, x = 18.0, y = 27.0, z = 150.0, button = PRIMARY, primaryButtonDown, pickResult = PickResult [node = Rectangle[x=0.0, y=0.0, width=0.0, height=0.0, fill=0x000000ff], point = Point3D [x = 15.0, y = 25.0, z = 100.0], distance = 33.0]] The test would be more complicated if it were changed to ignore the results of the `toString()` of both the intersected node and the point. If I were to go down this path, I would likely just change it to do match a regex of `"^MouseEvent [.*PickResult [.*]]$"`, which would be simple. Do you think it's worth it? Maybe instead I could add a comment that this test checks for matching brackets in the entire composed string returned by `MouseEvent::toString`, including `PickResult::toString`, which in turn includes `Node::toString` for the intersected node? ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From kevin.rushforth at oracle.com Thu Mar 25 14:25:50 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Mar 2021 07:25:50 -0700 Subject: [External] : Re: E-mail addresses at openjdk.org In-Reply-To: References: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> Message-ID: The email address used by the Skara tooling for all git commits, for the Committer and for the Author if the Author has an associated OpenJDK ID, is: `openjdkid at openjdk.org` -- Kevin On 3/25/2021 7:03 AM, Nir Lisker wrote: > What are these email addresses? > > On Thu, Mar 25, 2021 at 1:12 PM Kevin Rushforth > > wrote: > > Eventually the openjdk.org addresses will be > live. I haven't heard a > recent update on the timing for this. Until then, adding the email > address as an unverified additional email address in your GitHub > profile > is the way to go. > > -- Kevin > > > On 3/24/2021 9:37 PM, John Neffenger wrote: > > I noticed that my last commit used the address > jgneff at openjdk.org > > instead of the address I normally use to create and sign commits. > > GitHub didn't recognize the commit as mine until I added the > address > > to my account. > > > > Do the openjdk.org addresses receive > e-mail? If not, do we just leave > > the address unverified in our GitHub accounts? > > > > Thanks, > > John > From nlisker at openjdk.java.net Thu Mar 25 15:21:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 15:21:27 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: References: <-SYntOuNDeg3RL2lWjj5d7nYTUpNnUpPjPcyba8HFzM=.4bed260c-460c-4067-aa08-40c7fd3205b7@github.com> Message-ID: On Thu, 25 Mar 2021 14:15:47 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/input/MouseEventTest.java line 139: >> >>> 137: case ']': >>> 138: --bracketCount; >>> 139: assertTrue("Too many closing brackets: " + str, bracketCount >= 0); >> >> This test can fail due to a malformed `toString` result in the node (`getIntersectedNode()`), which I would think is outside the scope of this test. In practice, this test's result is dependent on what node I choose to test. >> >> Shouldn't we be testing the structure of the string and not its contents? > > On the one hand, I can see your point that it's somewhat tangential that Rectangle has matched brackets, but you could say the same about the Point3D. Here is the result of MouseEvent.toString for the test: > > MouseEvent [source = javafx.event.Event$$Lambda$110/0x0000000800c52fa8 at 461111c0, > target = javafx.event.Event$$Lambda$110/0x0000000800c52fa8 at 461111c0, eventType = MOUSE_PRESSED, > consumed = false, x = 18.0, y = 27.0, z = 150.0, button = PRIMARY, primaryButtonDown, > pickResult = PickResult [node = Rectangle[x=0.0, y=0.0, width=0.0, height=0.0, fill=0x000000ff], > point = Point3D [x = 15.0, y = 25.0, z = 100.0], distance = 33.0]] > > The test would be more complicated if it were changed to ignore the results of the `toString()` of both the intersected node and the point. If I were to go down this path, I would likely just change it to do match a regex of `"^MouseEvent [.*PickResult [.*]]$"`, which would be simple. Do you think it's worth it? > > Maybe instead I could add a comment that this test checks for matching brackets in the entire composed string returned by `MouseEvent::toString`, including `PickResult::toString`, which in turn includes `Node::toString` for the intersected node? I don't think it matters too much, but a change in any of the classes used here could break this test, which is a bit off. I will be satisfied with a comment warning about this case so if it breaks it will be easy to see where the problem is. ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From nlisker at openjdk.java.net Thu Mar 25 16:33:25 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 16:33:25 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: References: Message-ID: <560wl532boyST1k39FHlAY_mtCqx4No88JQngngE1dQ=.ff633665-5dbe-41c5-9c57-0ebc00b75b26@github.com> On Thu, 25 Mar 2021 13:21:24 GMT, Johan Vos wrote: >> Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. > > Good catch. Test fails before and succeeds after the patch. By the way, this class could easily be converted to a `record`, and that would take care of the `toString` and other ceremonies. I'm not sure it's a backwards compatible change, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From github.com+12087024+beldenfox at openjdk.java.net Thu Mar 25 17:36:46 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Thu, 25 Mar 2021 17:36:46 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v3] In-Reply-To: References: Message-ID: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: A small number of keyboard layouts require the Option key to reach critical letters like 'Q'. Added a third probe (after Command and Shift+Command) to look for letters that require Option. The keyboards in question are Azeri, Turkmen, and the Sami layouts. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/425/files - new: https://git.openjdk.java.net/jfx/pull/425/files/6238c49c..26a6fb0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=01-02 Stats: 59 lines in 1 file changed: 29 ins; 14 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/425.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/425/head:pull/425 PR: https://git.openjdk.java.net/jfx/pull/425 From github.com+12087024+beldenfox at openjdk.java.net Thu Mar 25 17:41:40 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Thu, 25 Mar 2021 17:41:40 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: > This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. > > When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. > > There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. > > https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts > https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard > https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout > https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace error. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/425/files - new: https://git.openjdk.java.net/jfx/pull/425/files/26a6fb0d..fb449d93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/425.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/425/head:pull/425 PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Thu Mar 25 17:53:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 17:53:26 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: <560wl532boyST1k39FHlAY_mtCqx4No88JQngngE1dQ=.ff633665-5dbe-41c5-9c57-0ebc00b75b26@github.com> References: <560wl532boyST1k39FHlAY_mtCqx4No88JQngngE1dQ=.ff633665-5dbe-41c5-9c57-0ebc00b75b26@github.com> Message-ID: <0-0ArCEmTRkT-9EDYa1jm-4rWZxr_H5f03FDVYIIkiY=.17ae0904-64d8-46c3-9428-da22dcd31465@github.com> On Thu, 25 Mar 2021 16:30:30 GMT, Nir Lisker wrote: >> Good catch. Test fails before and succeeds after the patch. > > By the way, this class could easily be converted to a `record`, and that would take care of the `toString` and other ceremonies. I'm not sure it's a backwards compatible change, though. Converting an existing class to a Record wouldn't be backward compatible (not to mention we can't use them yet). It wouldn't help for the Node::toString portion in any case. I'll add the comment and send out a new version. ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From jgneff at openjdk.java.net Thu Mar 25 18:56:24 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 25 Mar 2021 18:56:24 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: On Wed, 24 Mar 2021 19:50:11 GMT, John Neffenger wrote: > Are all of them actually needed? Just to follow up on that question, all of them are in fact downloaded during the build, at least. I removed the Gradle directory `$HOME/.gradle` and ran the build as follows. Then I compared the list of downloaded artifacts with the ones listed in the dependency verification file. $ rm -r $HOME/.gradle $ bash gradlew sdk jmods javadoc apps test -x :web:test ... $ find ~/.gradle/caches/modules-2 ( -name "*.jar" -o -name "*.pom" ) \ -exec basename {} ; | sort > downloaded.log $ grep '/\1/' \ | sort > verified.log $ diff downloaded.log verified.log 31a32 > org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512-.jar 32a34 > org.eclipse.swt.win32.win32.x86_64_3.105.3.v20170228-0512-.jar A total of 36 artifacts (14 JAR files and 22 POM files) are downloaded during the build. The SWT libraries for macOS and Windows were not downloaded because I ran the build on Linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From github.com+12087024+beldenfox at openjdk.java.net Thu Mar 25 19:04:25 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Thu, 25 Mar 2021 19:04:25 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) In-Reply-To: <6TZ5-DxE6HC8Da5xN3_upn8nXtdM21NiPhdgVgsWEIA=.c8db34d4-b49d-4124-a43e-a2cfe05d9ed3@github.com> References: <-aR9ye-2FqZU5i1KLggvHU6WdkujQ_Fm02Lb24vNxIw=.04d4194d-d63b-4a9a-a20a-4c61b6c897c4@github.com> <8xBQwI5lyPhc2iteqLG0o9sP7IKKIMzXneBI4Ay1EMo=.9dcafb4c-187d-45cc-ba6a-7944e0ef516c@github.com> <6L35edHJmP9B4bSrCvccUvAud20PCuZMqfGyXUB2m9g=.90ca871f-4cec-461f-82ab-16bd71063b26@github.com> <4DMGohjcVKz0vg0kZq0Qs7e5X1mQfkahhQGd1WerBS0=.b7e4fb1a-8984-4ed2-bde9-5a4070501086@github.com> <6TZ5-DxE6HC8Da5xN3_upn8nXtdM21NiPhdgVgsWEIA=.c8db34d4-b49d-4124-a43e-a2cfe05d9ed3@github.com> Message-ID: <1r6LZTj02pfDoO4bagzF85HF94j91HC3bn2GzoR9Tng=.9cc18382-063b-405c-ad3f-4b27ebe94041@github.com> On Wed, 24 Mar 2021 22:00:03 GMT, Kevin Rushforth wrote: >> I've written a command line utility that runs through all the keyboard layouts available in macOS 11.2.3 and generates a report on how this PR would change the Java key codes for each layout. I used it to spot-check the behavior on various layouts and to flag potential trouble spots (like Lithuanian where digits are typed using a dead key.) I thought it would also be useful for this review. For example, I can now say that with this PR Meta-, (comma) will still be available on all layouts. >> >> If the report would be of interest where should I put it? Add it to this PR, attach it to a comment in this thread, put it someplace public and link to it? > > I guess it depends on how large the table is. Adding it as an inline table using markdown could be helpful, unless it is so large that it takes too long to scroll past it. In that case, I'd probably recommend attaching it to a comment in the PR. I've attached a text document which details which Java key codes are lost and gained for each keyboard layout compared to the pre-PR code. It also flags some potential trouble spots with the word "Warning". Note that at the bottom of the file there's a long list of layouts which are unchanged. I've added it as a file to make it easier to diff against future versions if I need to tweak the algorithm some more (here's hoping I don't). With the latest code tweak the Java key codes A to Z are available on all keyboards except Turkmen as there really is no way to type 'X' on that layout. The key codes Digit0 to Digit9 are available on all keyboards except Lithuanian where the digits require a dead-key to type. [GainsAndLosses.txt](https://github.com/openjdk/jfx/files/6207211/GainsAndLosses.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Thu Mar 25 22:08:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 22:08:36 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket [v2] In-Reply-To: References: Message-ID: > Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review feedback: fix indentation in PickResult::toString, add comment to the test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/443/files - new: https://git.openjdk.java.net/jfx/pull/443/files/7b037029..ebad8e26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=443&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=443&range=00-01 Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/443.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/443/head:pull/443 PR: https://git.openjdk.java.net/jfx/pull/443 From nlisker at openjdk.java.net Thu Mar 25 22:19:26 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 25 Mar 2021 22:19:26 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket [v2] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 22:08:36 GMT, Kevin Rushforth wrote: >> Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback: fix indentation in PickResult::toString, add comment to the test Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From kcr at openjdk.java.net Thu Mar 25 23:01:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Mar 2021 23:01:26 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 22:07:34 GMT, Alessadro Parisi wrote: > Can you also update the build script located in tools/scripts? > Build fails on my system with `FAIL: WINSDK_DIR not defined` I filed [JDK-8264219](https://bugs.openjdk.java.net/browse/JDK-8264219) to track this. We don't use that script, and I have no good way to test it. Maybe someone in the community could pick it up. > Also, it's not possible to install Windows SDK 7.1 on Windows 10, so that should be updated too The dependency on Windows SDK 7.1 has been eliminated; I noted that in the bug report. ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From fkirmaier at openjdk.java.net Thu Mar 25 23:14:27 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 25 Mar 2021 23:14:27 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 11:44:21 GMT, Jeanette Winzenburg wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > good catch, yet another property that's not correctly updated on index change :) > > Quick questions: > - what are the macroscopic effects (that is in a running list) that you see without fixing it? > - do we want mere cell re-use fire a editCancel? (which the list seems to ignore in the test, don't know why) To clarify, this with happening with ListViews in production code. In some conditions, the status of a single cell doesn't update. The effect is, that a Cell is stuck in the Editing mode. If I remember correctly, it was irreversible stuck. It happened rarely, it might be connected to cells with variable sizes. Handling the logic from the ListView seems wrong to me, I think the ListCell should update its state automatically dependent of the properties. But I wouldn't know where to add it in the ListView. If that's how it's done in the other cell-based components, then it would make sense and the code more linear. I'm not really opinionated on how to solve it, just went for the simplest fix I've found. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Thu Mar 25 23:26:28 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 25 Mar 2021 23:26:28 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 07:53:03 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8263322 >> fixed the names of some tests > > Marked as reviewed by arapte (Reviewer). The CSR is now in the proposed state! ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From tbee at tbee.org Fri Mar 26 07:07:36 2021 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 26 Mar 2021 08:07:36 +0100 Subject: javafx-maven-plugin eclipse java version Message-ID: <831e1805-17bc-d656-0034-b22730567464@tbee.org> To prevent me from going on a long search-and-rescue, I figured I'd post a small question here. I'm trying to run an application with the javafx-maven-plugin on top of JDK 15. Works fine. But the moment I do javafx:run from within Eclipse, it complains about the classfile versions: it says the compiler generated 59 (Java 15) while it can only run 55 (Java 11). I only have Java 15 JDK configured in Eclipse, running "mvn -version" from Eclipse says it uses Java 15, so that does not seem to be the problem. If I run maven with -X, the compiler plugin just above uses release/source/target 15, but javafx:run indeeds mentions release/source/target 11. The output is the same from the shell and from eclipse, however in Eclipse it is an issue. Shouldn't javafx:run using the version settings from the maven project? Why is it different between shell and eclipse? Regards, Tom From fkirmaier at openjdk.java.net Fri Mar 26 12:02:40 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 26 Mar 2021 12:02:40 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v4] In-Reply-To: References: Message-ID: > Fixing a memory leak. > A node hard references its old parent after CSS layout and getting removed. > This shouldn't be the case, this is very counterintuitive. > > The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor. > This should be fine because the CSS should only depend on it if it's still the real parent. > In that case, it doesn't get collected. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8263402 Minor cleanup based on codereview ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/424/files - new: https://git.openjdk.java.net/jfx/pull/424/files/52fa05f6..e8063e30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=424&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/424.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/424/head:pull/424 PR: https://git.openjdk.java.net/jfx/pull/424 From fkirmaier at openjdk.java.net Fri Mar 26 12:02:42 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 26 Mar 2021 12:02:42 GMT Subject: RFR: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene [v3] In-Reply-To: References: Message-ID: <1G9GVvRdI992pfjLkdDs-6fH3mlM-62sU2ld238BBsA=.72313c28-be98-4803-ac40-9940d2898e02@github.com> On Tue, 23 Mar 2021 09:57:11 GMT, Ambarish Rapte wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263402 >> Rewrote the style memoryleak test > > Provided few comments on test. I've added the requested changes from the codereview > tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 48: > >> 46: import static org.junit.Assert.fail; >> 47: import static org.junit.Assert.assertTrue; >> 48: > > The packages Application, Node and Parent are not used. done > tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 100: > >> 98: Platform.runLater(() -> { >> 99: Platform.exit(); >> 100: }); > > `Platform.exit()` can be called from any thread. So `Platform.runLater` is not required. done > tests/system/src/test/java/test/javafx/scene/StyleMemoryLeakTest.java line 102: > >> 100: }); >> 101: } >> 102: } > > Include a new line at end of file. done ------------- PR: https://git.openjdk.java.net/jfx/pull/424 From fastegal at openjdk.java.net Fri Mar 26 12:30:31 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 26 Mar 2021 12:30:31 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 23:11:28 GMT, Florian Kirmaier wrote: > > Handling the logic from the ListView seems wrong to me, looks like I was unclear, because that's a 100% me-too :) Reformulating my second sentence in test snippets: A: cell.updateIndex(1); list.edit(1); cell.updateIndex(0); // failing/passing before/after fix assertFalse("cell re-use must update cell editing state" , cell.isEditing()); B: List events = new ArrayList(); list.setOnEditCancel(e -> { events.add(e); }); .... setup test state as in A // passing/failing before/after fix assertTrue("cell re-use must not trigger edit events", events.isEmpty()); C: .... setup test state as in A // passing/passing before/after fix assertEquals("cell re-use must not change list editing state", 1, list.getEditingIndex); My question was, whether we agree on B. My wondering was about C passing in the light of B failing. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From nlisker at openjdk.java.net Fri Mar 26 14:01:30 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 26 Mar 2021 14:01:30 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v9] In-Reply-To: References: <2jub2GNQua2uK7g1zTRo2QMSgEyI7QTwFxFcqcud6tk=.a40a5feb-37d9-4a14-a20a-d63b4f87e0ef@github.com> Message-ID: On Thu, 25 Mar 2021 02:02:25 GMT, Nir Lisker wrote: >>> I the rotation needs to apply to whatever the direction vector is: whether that's implicitly (0,0,1) if we don't provide a separate direction vector or whether it's the user provided direction vector, it would be odd to ignore transforms if you set the vector. >> >> I see, so we compose the transforms on top of the direction vector. It's an option indeed. >> >>> If we don't provide a vector, we could always add it later if people ask for it, so maybe it is better to leave it off if we aren't sure. >>> >>> The question then becomes how easy is it to modify the direction vector using the node transforms? >> >> Yes, the ease of use is the issue I brought up initially with this approach. The rotation transforms are non-commutable, so it's going to be unintuitive for complex operations. A look-at method could be very useful not only in this case, but for any node in a 3D scene (or even 2D). Do you think that this is a worthy addition? > > I think I corrected the GL pipeline issue. The dot product should have used the negative light direction. It worked for me because I was testing in the -1 z direction instead of the +1. I still don't know why Mac and Linux would have given different results. This is what I get after the commit: > > ![Screenshot from 2021-03-25 03-59-57](https://user-images.githubusercontent.com/37422899/112407458-c941cc80-8d1e-11eb-85c2-468508e5018a.png) If you want to test aiming the light with transforms instead of a direction vector, I modified the `NGSpotLight` and `AttenLightingSample` files to use the rotation transforms. [transforms.zip](https://github.com/openjdk/jfx/files/6212221/transforms.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From jackyguo579 at gmail.com Fri Mar 26 14:57:58 2021 From: jackyguo579 at gmail.com (Jacky Guo) Date: Fri, 26 Mar 2021 10:57:58 -0400 Subject: Implementing a shader API In-Reply-To: <04bdb68c-3d7c-7880-842d-65223f5dc6f5@videotron.ca> References: <04bdb68c-3d7c-7880-842d-65223f5dc6f5@videotron.ca> Message-ID: Regarding the shader API, if an error occurs during shader compilation, should it simply default to the basic Phong shaders or throw an Exception (likely in a new package with other shader stuff)? I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can someone give me a quick rundown on that? On Wed, Mar 17, 2021 at 9:06 PM Dan Howard wrote: > This is cool. You should like up with Almas Baimagambetov > > > https://github.com/AlmasB > > > On 3/15/2021 10:12 PM, Jacky Guo wrote: > > Regarding uniform parameters (i.e. variables set from Java and called on > > the shader): > > Since OpenGL's data passing uses locations, you could simply store a map > of > > uniform parameters (or whatever their JSL equivalent is) to their > > locations, and call the required methods and perform the necessary > > type-safety checks. > > For D3D, you would still use the parameter map, but only for type safety. > > > > This is assuming I understand how the APIs work and I am not overlooking > > something crucial. > > > > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker wrote: > > > >> I've thought about this too for a bit. My question would be how to tell > >> the CPU what data to pass to the shader. Take OpenGL for example: > writing > >> an API to pass a shader and compiling it in runtime is not hard, but you > >> need the CPU side to feed the shader its parameters. You would need an > API > >> for arbitrary data that the shader has been preconfigured to handle. > That's > >> quite an undertaking. > >> And what level of flexibility is this going to give? The shader might > >> require data that the public Java API does not expose, so you are > limited > >> in that regard too. When I wrote the enhancements for the shaders, I > also > >> had to change the Java side, which you won't be able to do. > >> On the D3D side, the shaders are precompiled, so it's a slightly > different > >> story. > >> > >> - Can high school students sign the OCA? (I saw the job title field > >>> on the form and wasn't so sure I was legally allowed to sign it) > >> > >> Maybe ask on adoption-discuss at openjdk.java.net. > >> > >> On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen > >> wrote: > >> > >>> I messed around with adding features to JavaFX's "JSLC" (Java Shader > >>> Language Compiler) which currently is only used > >>> at compile-time for JavaFX to convert "JSL" shaders to various platform > >>> dependent shader languages (GLSL, HLSL, etc.). > >>> > >>> In my opinion the ideal way to implement a public shader API would be > to > >>> extend JSLC to be able to be used either > >>> at user application compile time, or more ideally, at application > run-time > >>> to dynamically generate platform dependent shaders > >>> depending on what platform JavaFX is running on. Then a JavaFX > application > >>> developer can write platform independent > >>> shaders in JSL. This would be quite a large undertaking and have a high > >>> burden of maintenance to keep it current with > >>> fast moving shader languages. > >>> > >>> I was able to convert JSLC grammar to antlr4 (from the previous antlr3 > >>> version) in this merged commit (pre-dates the move > >>> to Github): > >>> > >>> > >>> > https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > >>> > >>> I then took advantage of a new feature in antlr4 which allows for > >>> extracting embedded actions from the grammar definition file to a > visitor > >>> class: > >>> > >>> > >>> > https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > >>> > >>> I then, in a test repository did some work in fleshing out what it > would > >>> take to implement more features for JSLC which you can find (as messy > >>> commits) here: > >>> > >>> https://github.com/brcolow/jslc > >>> > >>> That's just my two cents on how a public shader API should best be > added > >>> to > >>> JavaFX, by building on previous work that exists in the source code > >>> repository but is only > >>> used in a very limited and small way - but there is much potential > there > >>> and I believe the original author of JSL's intent was to have it be a > >>> public API feature to allow > >>> JavaFX developers to write platform independent shaders in JSL. > >>> > >>> > >>> On Sun, Mar 14, 2021 at 3:32 PM superminerJG > >>> wrote: > >>> > >>>> Hi everyone. > >>>> > >>>> This problem might have been discussed numerous times, and has been > held > >>>> off for quite a while. > >>>> > >>>> Although we are starting to see lighting improvements added to > JavaFX, I > >>>> feel that it's necessary for JavaFX to have some kind of custom shader > >>>> pipeline. However, nobody has gotten around to doing it, so I thought > >>> that > >>>> I could lend a hand. Before I get into things, I would like to know > how > >>> and > >>>> what I can contribute. The questions are at the bottom of the email. > >>>> > >>>> Thanks! > >>>> - jgcodes > >>>> > >>>> Questions: > >>>> > >>>> - Can high school students sign the OCA? (I saw the job title > field > >>> on > >>>> the form and wasn't so sure I was legally allowed to sign it) > >>>> - When I implement the shader API, should it use some kind of > GLSL > >>>> mapping, or should I try to extend JSL to work in 3D? > >>>> - Should I have sent this email to another mailing list? > >>>> > >>> > >>> -- > >>> Michael Ennen > >>> > From nlisker at gmail.com Fri Mar 26 15:34:58 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 26 Mar 2021 18:34:58 +0300 Subject: Implementing a shader API In-Reply-To: References: <04bdb68c-3d7c-7880-842d-65223f5dc6f5@videotron.ca> Message-ID: Let's keep the discussion in the openjfx-discuss at openjdk.java.net list for now. I'm sending this mail on the dev list just for continuity. I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > someone give me a quick rundown on that? > The D3D shader pointers are in D3DPhongShader.h. There is 1 vertex shader and several pixel shaders that account for different illumination modes for performance reasons, and these are swapped at runtime in D3DMeshView.cc whenever a render is requested. In this class, the vertex shader is set with IDirect3DDevice9::SetVertexShader, taking in D3DPhongShader::getVertexShader. The pixel shader is set with D3DPhongShader::setPixelShader, taking in the illumination mode parameters and retrieving the appropriate shader. It is then set with IDirect3DDevice9::SetPixelShader. Regarding the shader API, if an error occurs during shader compilation, > should it simply default to the basic Phong shaders or throw an Exception > (likely in a new package with other shader stuff)? > If you are talking about a new API, then this is too detailed to figure out at this point. We need to step back and figure out how to have things working with each other before figuring out what to do on invalid input. On Fri, Mar 26, 2021 at 5:58 PM Jacky Guo wrote: > Regarding the shader API, if an error occurs during shader compilation, > should it simply default to the basic Phong shaders or throw an Exception > (likely in a new package with other shader stuff)? > > I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > someone give me a quick rundown on that? > > On Wed, Mar 17, 2021 at 9:06 PM Dan Howard wrote: > >> This is cool. You should like up with Almas Baimagambetov >> >> >> https://github.com/AlmasB >> >> >> On 3/15/2021 10:12 PM, Jacky Guo wrote: >> > Regarding uniform parameters (i.e. variables set from Java and called on >> > the shader): >> > Since OpenGL's data passing uses locations, you could simply store a >> map of >> > uniform parameters (or whatever their JSL equivalent is) to their >> > locations, and call the required methods and perform the necessary >> > type-safety checks. >> > For D3D, you would still use the parameter map, but only for type >> safety. >> > >> > This is assuming I understand how the APIs work and I am not overlooking >> > something crucial. >> > >> > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker wrote: >> > >> >> I've thought about this too for a bit. My question would be how to tell >> >> the CPU what data to pass to the shader. Take OpenGL for example: >> writing >> >> an API to pass a shader and compiling it in runtime is not hard, but >> you >> >> need the CPU side to feed the shader its parameters. You would need an >> API >> >> for arbitrary data that the shader has been preconfigured to handle. >> That's >> >> quite an undertaking. >> >> And what level of flexibility is this going to give? The shader might >> >> require data that the public Java API does not expose, so you are >> limited >> >> in that regard too. When I wrote the enhancements for the shaders, I >> also >> >> had to change the Java side, which you won't be able to do. >> >> On the D3D side, the shaders are precompiled, so it's a slightly >> different >> >> story. >> >> >> >> - Can high school students sign the OCA? (I saw the job title field >> >>> on the form and wasn't so sure I was legally allowed to sign it) >> >> >> >> Maybe ask on adoption-discuss at openjdk.java.net. >> >> >> >> On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen >> >> wrote: >> >> >> >>> I messed around with adding features to JavaFX's "JSLC" (Java Shader >> >>> Language Compiler) which currently is only used >> >>> at compile-time for JavaFX to convert "JSL" shaders to various >> platform >> >>> dependent shader languages (GLSL, HLSL, etc.). >> >>> >> >>> In my opinion the ideal way to implement a public shader API would be >> to >> >>> extend JSLC to be able to be used either >> >>> at user application compile time, or more ideally, at application >> run-time >> >>> to dynamically generate platform dependent shaders >> >>> depending on what platform JavaFX is running on. Then a JavaFX >> application >> >>> developer can write platform independent >> >>> shaders in JSL. This would be quite a large undertaking and have a >> high >> >>> burden of maintenance to keep it current with >> >>> fast moving shader languages. >> >>> >> >>> I was able to convert JSLC grammar to antlr4 (from the previous antlr3 >> >>> version) in this merged commit (pre-dates the move >> >>> to Github): >> >>> >> >>> >> >>> >> https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 >> >>> >> >>> I then took advantage of a new feature in antlr4 which allows for >> >>> extracting embedded actions from the grammar definition file to a >> visitor >> >>> class: >> >>> >> >>> >> >>> >> https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 >> >>> >> >>> I then, in a test repository did some work in fleshing out what it >> would >> >>> take to implement more features for JSLC which you can find (as messy >> >>> commits) here: >> >>> >> >>> https://github.com/brcolow/jslc >> >>> >> >>> That's just my two cents on how a public shader API should best be >> added >> >>> to >> >>> JavaFX, by building on previous work that exists in the source code >> >>> repository but is only >> >>> used in a very limited and small way - but there is much potential >> there >> >>> and I believe the original author of JSL's intent was to have it be a >> >>> public API feature to allow >> >>> JavaFX developers to write platform independent shaders in JSL. >> >>> >> >>> >> >>> On Sun, Mar 14, 2021 at 3:32 PM superminerJG >> >>> wrote: >> >>> >> >>>> Hi everyone. >> >>>> >> >>>> This problem might have been discussed numerous times, and has been >> held >> >>>> off for quite a while. >> >>>> >> >>>> Although we are starting to see lighting improvements added to >> JavaFX, I >> >>>> feel that it's necessary for JavaFX to have some kind of custom >> shader >> >>>> pipeline. However, nobody has gotten around to doing it, so I thought >> >>> that >> >>>> I could lend a hand. Before I get into things, I would like to know >> how >> >>> and >> >>>> what I can contribute. The questions are at the bottom of the email. >> >>>> >> >>>> Thanks! >> >>>> - jgcodes >> >>>> >> >>>> Questions: >> >>>> >> >>>> - Can high school students sign the OCA? (I saw the job title >> field >> >>> on >> >>>> the form and wasn't so sure I was legally allowed to sign it) >> >>>> - When I implement the shader API, should it use some kind of >> GLSL >> >>>> mapping, or should I try to extend JSL to work in 3D? >> >>>> - Should I have sent this email to another mailing list? >> >>>> >> >>> >> >>> -- >> >>> Michael Ennen >> >>> >> > From nlisker at gmail.com Fri Mar 26 21:04:49 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 27 Mar 2021 00:04:49 +0300 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> Message-ID: There's no question that the JBS is the way to go for handling existing reports. As for incoming reports, I dislike the GitHub issues as they are just a text dump, and many reporters are not careful about giving you versions (Java/JavaFX/OS...) or working environment details. You can help GitHub with templates like Gradle does, but I find it still a bit shaky and overall produces much less quality reports. There's also the issue of transferring them from whatever system we use to JBS, how to do it and who exactly will do it? Will the triage team at Oracle that work on the webform work here too? It takes a lot of time to try to reproduce a bug using (sometimes cryptic) submitter instructions. Let's enumerate the webform issues: 1. Bugs don't immediately reappear on JBS since they are triaged internally. 2. Can't add images/attachments. 3. No submitter name for those who want the credit. 4. ??? Suppose we create our own webform: 1. We technically have credentials to forward them directly into JBS because we have Authors (needless to say it should not be dependent on a specific person, but for now...). Will we lose Oracle's triage team in this case or can we tell them to have a look at these bugs (we can adda label to mark them)? 2. We can allow attachments and transfer them directly to Jira attachments. 3. We can't credit the submitter because the Reporter field in Jira is not editable (at least at my permissions level) and I'm getting the impression the people who are in charge of this will not make an exception for us, but we can add a text line with "submitted by" as a workaround. Is it worth it? Can we do better? N.B. As John Neffenger said about issues still coming to the old repo, maybe we should close it so they won't be misled. On Tue, Mar 23, 2021 at 9:35 AM Johan Vos wrote: > Hi John, all, > > Clearly, there are advantages and disadvantages to the Oracle Web form. > It's not a black/white situation. > We need to find a solution that combines the advantages of being accessible > as well as not creating false expectations. > > I really like the JBS system, it is very powerful and flexible. For > example, we now semi-automatically create the release notes for JavaFX > using a script. Once you have an account there, it serves its purposes. > But I agree, the barrier for non-JDK authors to submit a bug is too high, > resulting in issues being reported in random places, not always in a nice > way. Hence, I think we need to provide something easier, without giving up > the power of JBS. Actually, I am in favor of keeping JBS as it is, as its > benefits are mainly relevant *after* an issue is entered. The question then > moves to *how* issues are entered, and I agree the webform isn't the best > way for this. > The transformation between "how" issues are created and then how they are > tracked is currently done manually at Oracle, and that is something that > might be done in a more open, collaborative way. It's not fun work though, > but I agree transparency would help here, and if the JavaFX community can > help the Oracle folks with triaging OpenJFX bugs, that sounds like a > win-win to me. > > One of the things I want to avoid is a random "report" that shows part of a > stacktrace, with the reporter not giving more information. That issue would > then become a stale issue, giving a bad impression. > If those issues pile up in a public issue tracker. So how do we manage > expectations, avoiding nasty tweets like "I told them there was an issue > and after 2 years it's still there!" > > In summary, I believe we need to separate a few things: > * JBS: we use this as issue tracker, where we track, monitor, label, set > versions, link to other issues, with different possible workflows. I think > there is no alternative for this, and that's not needed. > * bug-report system: I'm all in to find a more accessible way, keeping into > account that would require work being done by the community (hence, us) for > converting issues into high-quality JBS issues. > > - Johan > > > > On Tue, Mar 23, 2021 at 7:28 AM John Neffenger wrote: > > > On 3/22/21 3:27 PM, Philip Race wrote: > > > I am informed that, for no reason given, the corporate IT folks will > not > > > allow attachment upload. > > > > Thank you for looking into it, Phil. It's good at least to have a > > definitive answer. I brought this up on the mailing list three years > > ago, too: > > > > Re: More community participation in JavaFX > > > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021343.html > > > > I eventually created those bug reports, despite all the gate-keeping. In > > fact, I'm even starting to think there could be advantages to having > > pull requests as the only real way to participate in the OpenJFX > > project. A flood of easily-created issues on GitHub can be just as > > off-putting as that Oracle Web form. > > > > John > > > From nlisker at gmail.com Fri Mar 26 21:12:12 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 27 Mar 2021 00:12:12 +0300 Subject: javafx-maven-plugin eclipse java version In-Reply-To: <831e1805-17bc-d656-0034-b22730567464@tbee.org> References: <831e1805-17bc-d656-0034-b22730567464@tbee.org> Message-ID: What is "javafx:run"? If you run it from within Eclipse (the green "play" button), does it work? On Fri, Mar 26, 2021 at 10:08 AM Tom Eugelink wrote: > To prevent me from going on a long search-and-rescue, I figured I'd post a > small question here. > > I'm trying to run an application with the javafx-maven-plugin on top of > JDK 15. Works fine. But the moment I do javafx:run from within Eclipse, it > complains about the classfile versions: it says the compiler generated 59 > (Java 15) while it can only run 55 (Java 11). > > I only have Java 15 JDK configured in Eclipse, running "mvn -version" from > Eclipse says it uses Java 15, so that does not seem to be the problem. > > If I run maven with -X, the compiler plugin just above uses > release/source/target 15, but javafx:run indeeds mentions > release/source/target 11. The output is the same from the shell and from > eclipse, however in Eclipse it is an issue. > > Shouldn't javafx:run using the version settings from the maven project? > Why is it different between shell and eclipse? > > Regards, Tom > > From tbee at tbee.org Sat Mar 27 07:29:10 2021 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Mar 2021 08:29:10 +0100 Subject: javafx-maven-plugin eclipse java version In-Reply-To: References: <831e1805-17bc-d656-0034-b22730567464@tbee.org> Message-ID: It is a maven goal to start a javafx application with all the native stuff setup correctly. https://openjfx.io/openjfx-docs/#maven I have not configured an direct Eclipse run, because that is more work with defining the native librars and stuff, while I should just be able to run the maven goal. https://openjfx.io/openjfx-docs/#maven But apparently only on Java 11. I'll checkout out the plugin and see what is up. On 2021-03-26 22:12, Nir Lisker wrote: > What is "javafx:run"? If you run it from within?Eclipse (the green "play" button), does it work? > > On Fri, Mar 26, 2021 at 10:08 AM Tom Eugelink > wrote: > > To prevent me from going on a long search-and-rescue, I figured I'd post a small question here. > > I'm trying to run an application with the javafx-maven-plugin on top of JDK 15. Works fine. But the moment I do javafx:run from within Eclipse, it complains about the classfile versions: it says the compiler generated 59 (Java 15) while it can only run 55 (Java 11). > > I only have Java 15 JDK configured in Eclipse, running "mvn -version" from Eclipse says it uses Java 15, so that does not seem to be the problem. > > If I run maven with -X, the compiler plugin just above uses release/source/target 15, but javafx:run indeeds mentions release/source/target 11. The output is the same from the shell and from eclipse, however in Eclipse it is an issue. > > Shouldn't javafx:run using the version settings from the maven project? Why is it different between shell and eclipse? > > Regards, Tom > From tbee at tbee.org Sat Mar 27 09:47:00 2021 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 27 Mar 2021 10:47:00 +0100 Subject: javafx-maven-plugin eclipse java version In-Reply-To: References: <831e1805-17bc-d656-0034-b22730567464@tbee.org> Message-ID: <10f8919e-df23-6cd1-7aeb-efb46c6e5507@tbee.org> The plugin has an executable option which can refer to the java executable. Per it uses the system default, which apparently is different between my bash and the shell that eclipse uses. If I hard code the correct path, it works correctly. But a hardcoded path is not okay, so I'm going to try and see if I can make a PR so the plugin use the same java as the compiler. That would make it less unpredictable. And possibly use toolchains, since I now know it exists :-) From ebresie at gmail.com Sat Mar 27 11:22:20 2021 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 27 Mar 2021 06:22:20 -0500 Subject: Implementing a shader API In-Reply-To: CA+0ynh9fjXcnGGqhqv8A=Tb=8VwfREgCzX65p2G-VzTYgHBV=w@mail.gmail.com References: CA+1EH6ZeLP2istwc0AGcXuUxurqFv08oxWF7YjQfFqPYPGFwuA@mail.gmail.com CA+1EH6aVa7D=j8-tu1Ydx7YLRVNe6hwYo5XW_B+0MNXtHL2zLw@mail.gmail.com CAOTPd66cYg-LpvaEe74mg1GQBSwXZcjTVXhoh+fV6ZWtOLn4Cg@mail.gmail.com CA+0ynh8tzdFW5HRToxqsS1dbHSmRGRqWt6TNC-aR89CQDadoJw@mail.gmail.com LzDQlkiZ9NMBWLzDSlZwoZ@videotron.ca 04bdb68c-3d7c-7880-842d-65223f5dc6f5@videotron.ca CA+1EH6bBHrqUGDBo_29rU9ZtYvrkRJ5f88=pGVAXX7sFr8NxTA@mail.gmail.com CA+1EH6bBHrqUGDBo_29rU9ZtYvrkRJ5f88=pGVAXX7sFr8NxTA@mail.gmail.com Message-ID: Don?t suppose integrating Java OpenGL if not already done would help? https://jogamp.org/jogl/www/ They are a little dated but there are the OpenGL related JSRs like JSR 239: JavaTM Binding for the OpenGL? ES API https://www.jcp.org/en/jsr/detail?id=239 I think this was targeted at Java ME mobile platforms JSR 231: JavaTM Binding for the OpenGL? API https://www.jcp.org/en/jsr/detail?id=231 Or is some updated JSR really needed here? Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On March 26, 2021 at 10:34:58 AM CDT, Nir Lisker wrote: > Let's keep the discussion in the openjfx-discuss at openjdk.java.net (mailto:openjfx-discuss at openjdk.java.net) list for > now. I'm sending this mail on the dev list just for continuity. > > I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > > someone give me a quick rundown on that? > > > > The D3D shader pointers are in D3DPhongShader.h. There is 1 vertex shader > and several pixel shaders that account for different illumination modes for > performance reasons, and these are swapped at runtime in D3DMeshView.cc (http://D3DMeshView.cc) > whenever a render is requested. > In this class, the vertex shader is set > with IDirect3DDevice9::SetVertexShader, taking > in D3DPhongShader::getVertexShader. The pixel shader is set > with D3DPhongShader::setPixelShader, taking in the illumination mode > parameters and retrieving the appropriate shader. It is then set with > IDirect3DDevice9::SetPixelShader. > > Regarding the shader API, if an error occurs during shader compilation, > > should it simply default to the basic Phong shaders or throw an Exception > > (likely in a new package with other shader stuff)? > > > > If you are talking about a new API, then this is too detailed to figure out > at this point. We need to step back and figure out how to have things > working with each other before figuring out what to do on invalid input. > > On Fri, Mar 26, 2021 at 5:58 PM Jacky Guo wrote: > > > Regarding the shader API, if an error occurs during shader compilation, > > should it simply default to the basic Phong shaders or throw an Exception > > (likely in a new package with other shader stuff)? > > > > I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > > someone give me a quick rundown on that? > > > > On Wed, Mar 17, 2021 at 9:06 PM Dan Howard wrote: > > > > > This is cool. You should like up with Almas Baimagambetov > > > > > > > > > https://github.com/AlmasB > > > > > > > > > On 3/15/2021 10:12 PM, Jacky Guo wrote: > > > > Regarding uniform parameters (i.e. variables set from Java and called on > > > > the shader): > > > > Since OpenGL's data passing uses locations, you could simply store a > > > map of > > > > uniform parameters (or whatever their JSL equivalent is) to their > > > > locations, and call the required methods and perform the necessary > > > > type-safety checks. > > > > For D3D, you would still use the parameter map, but only for type > > > safety. > > > > > > > > This is assuming I understand how the APIs work and I am not overlooking > > > > something crucial. > > > > > > > > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker wrote: > > > > > > > > > I've thought about this too for a bit. My question would be how to tell > > > > > the CPU what data to pass to the shader. Take OpenGL for example: > > > writing > > > > > an API to pass a shader and compiling it in runtime is not hard, but > > > you > > > > > need the CPU side to feed the shader its parameters. You would need an > > > API > > > > > for arbitrary data that the shader has been preconfigured to handle. > > > That's > > > > > quite an undertaking. > > > > > And what level of flexibility is this going to give? The shader might > > > > > require data that the public Java API does not expose, so you are > > > limited > > > > > in that regard too. When I wrote the enhancements for the shaders, I > > > also > > > > > had to change the Java side, which you won't be able to do. > > > > > On the D3D side, the shaders are precompiled, so it's a slightly > > > different > > > > > story. > > > > > > > > > > - Can high school students sign the OCA? (I saw the job title field > > > > > > on the form and wasn't so sure I was legally allowed to sign it) > > > > > > > > > > Maybe ask on adoption-discuss at openjdk.java.net (mailto:adoption-discuss at openjdk.java.net). > > > > > > > > > > On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen > > > > > wrote: > > > > > > > > > > > I messed around with adding features to JavaFX's "JSLC" (Java Shader > > > > > > Language Compiler) which currently is only used > > > > > > at compile-time for JavaFX to convert "JSL" shaders to various > > > platform > > > > > > dependent shader languages (GLSL, HLSL, etc.). > > > > > > > > > > > > In my opinion the ideal way to implement a public shader API would be > > > to > > > > > > extend JSLC to be able to be used either > > > > > > at user application compile time, or more ideally, at application > > > run-time > > > > > > to dynamically generate platform dependent shaders > > > > > > depending on what platform JavaFX is running on. Then a JavaFX > > > application > > > > > > developer can write platform independent > > > > > > shaders in JSL. This would be quite a large undertaking and have a > > > high > > > > > > burden of maintenance to keep it current with > > > > > > fast moving shader languages. > > > > > > > > > > > > I was able to convert JSLC grammar to antlr4 (from the previous antlr3 > > > > > > version) in this merged commit (pre-dates the move > > > > > > to Github): > > > > > > > > > > > > > > > > > > > > > https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > > > > > > > > > > > I then took advantage of a new feature in antlr4 which allows for > > > > > > extracting embedded actions from the grammar definition file to a > > > visitor > > > > > > class: > > > > > > > > > > > > > > > > > > > > > https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > > > > > > > > > > > I then, in a test repository did some work in fleshing out what it > > > would > > > > > > take to implement more features for JSLC which you can find (as messy > > > > > > commits) here: > > > > > > > > > > > > https://github.com/brcolow/jslc > > > > > > > > > > > > That's just my two cents on how a public shader API should best be > > > added > > > > > > to > > > > > > JavaFX, by building on previous work that exists in the source code > > > > > > repository but is only > > > > > > used in a very limited and small way - but there is much potential > > > there > > > > > > and I believe the original author of JSL's intent was to have it be a > > > > > > public API feature to allow > > > > > > JavaFX developers to write platform independent shaders in JSL. > > > > > > > > > > > > > > > > > > On Sun, Mar 14, 2021 at 3:32 PM superminerJG > > > > > > wrote: > > > > > > > > > > > > > Hi everyone. > > > > > > > > > > > > > > This problem might have been discussed numerous times, and has been > > > held > > > > > > > off for quite a while. > > > > > > > > > > > > > > Although we are starting to see lighting improvements added to > > > JavaFX, I > > > > > > > feel that it's necessary for JavaFX to have some kind of custom > > > shader > > > > > > > pipeline. However, nobody has gotten around to doing it, so I thought > > > > > > that > > > > > > > I could lend a hand. Before I get into things, I would like to know > > > how > > > > > > and > > > > > > > what I can contribute. The questions are at the bottom of the email. > > > > > > > > > > > > > > Thanks! > > > > > > > - jgcodes > > > > > > > > > > > > > > Questions: > > > > > > > > > > > > > > - Can high school students sign the OCA? (I saw the job title > > > field > > > > > > on > > > > > > > the form and wasn't so sure I was legally allowed to sign it) > > > > > > > - When I implement the shader API, should it use some kind of > > > GLSL > > > > > > > mapping, or should I try to extend JSL to work in 3D? > > > > > > > - Should I have sent this email to another mailing list? > > > > > > > > > > > > > > > > > > > -- > > > > > > Michael Ennen > > > > > > > > > > > From michaelstrau2 at gmail.com Sun Mar 28 01:14:29 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sun, 28 Mar 2021 03:14:29 +0200 Subject: Not really a nice comment but a real issue? In-Reply-To: References: <7BFEA8B4-0B84-4AFA-A985-398B258A20D6@ORACLE.COM> <97de99a7-0eed-e4e4-4ae7-4a62443dcda8@oracle.com> <92ee0ac0-5a5f-9597-52c2-013cffaf9b36@status6.com> <4317c589-f431-e1c5-01fa-7cd5735fa5a8@oracle.com> <1c2cd7bd-acb5-88b4-2b2e-a666604f7f9a@status6.com> Message-ID: Part of the reason why it's hard to reproduce a bug using a one-shot report is that there's no way to have a low-effort open discussion and no way to ask questions that would help clear things up. Not only is having open discussions of issues beneficial for quickly zeroing in on a workable solution, it also helps with getting a better understanding on where common pain points are for users. Even if a user wrongly identifies or poorly describes an issue, you'll often get a better understanding of an underlying issue just by allowing discussion. Am Fr., 26. M?rz 2021 um 22:05 Uhr schrieb Nir Lisker : > > There's no question that the JBS is the way to go for handling existing > reports. > > As for incoming reports, I dislike the GitHub issues as they are just a > text dump, and many reporters are not careful about giving you versions > (Java/JavaFX/OS...) or working environment details. You can help GitHub > with templates like Gradle does, but I find it still a bit shaky and > overall produces much less quality reports. > There's also the issue of transferring them from whatever system we use to > JBS, how to do it and who exactly will do it? Will the triage team at > Oracle that work on the webform work here too? It takes a lot of time to > try to reproduce a bug using (sometimes cryptic) submitter instructions. > > Let's enumerate the webform issues: > 1. Bugs don't immediately reappear on JBS since they are triaged internally. > 2. Can't add images/attachments. > 3. No submitter name for those who want the credit. > 4. ??? > > Suppose we create our own webform: > 1. We technically have credentials to forward them directly into JBS > because we have Authors (needless to say it should not be dependent on a > specific person, but for now...). Will we lose Oracle's triage team in this > case or can we tell them to have a look at these bugs (we can adda label to > mark them)? > 2. We can allow attachments and transfer them directly to Jira attachments. > 3. We can't credit the submitter because the Reporter field in Jira is not > editable (at least at my permissions level) and I'm getting the impression > the people who are in charge of this will not make an exception for us, but > we can add a text line with "submitted by" as a workaround. > > Is it worth it? Can we do better? > > N.B. As John Neffenger said about issues still coming to the old repo, > maybe we should close it so they won't be misled. > From tbee at tbee.org Sun Mar 28 11:12:27 2021 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 28 Mar 2021 13:12:27 +0200 Subject: javafx-maven-plugin eclipse java version In-Reply-To: <10f8919e-df23-6cd1-7aeb-efb46c6e5507@tbee.org> References: <831e1805-17bc-d656-0034-b22730567464@tbee.org> <10f8919e-df23-6cd1-7aeb-efb46c6e5507@tbee.org> Message-ID: <2ed205a1-c8d6-6987-234c-175b991134c1@tbee.org> Added toolchains support to javafx-maven-plugin and created a PR. https://github.com/openjfx/javafx-maven-plugin/pull/118 So you can do: org.apache.maven.plugins maven-toolchains-plugin 3.0.0 toolchain ${maven.compiler.release} That will make sure the same JDK is used for compiling and javafx:run (given the PR is merged). The easiest way to get that setup is using sdkman, install the required jdks, then also install jbang (sdk install jbang) and run 'jbang sdkman at tbee/mavenToolchains' On 2021-03-27 10:47, Tom Eugelink wrote: > The plugin has an executable option which can refer to the java executable. Per it uses the system default, which apparently is different between my bash and the shell that eclipse uses. If I hard code the correct path, it works correctly. > > But a hardcoded path is not okay, so I'm going to try and see if I can make a PR so the plugin use the same java as the compiler. That would make it less unpredictable. And possibly use toolchains, since I now know it exists :-) > From hjohn at xs4all.nl Sun Mar 28 12:03:55 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 28 Mar 2021 14:03:55 +0200 Subject: Detecting memory leaks in a Scene Message-ID: I've created a bit of helper code I've been using to detect Nodes that have been removed from a Scene that are not getting garbage collected. It takes a Scene as input, and will then monitor all Nodes that are added and removed to compile a list of Nodes that are no longer part of the Scene but are still being referenced. The code is here: https://gist.github.com/hjohn/f7b2d5b6d56ba5e5bb6b6c5621799ca5 One major issue I've already discovered with this code (apart from my own mistakes) is that Scene$MouseHandler is holding on to references to Nodes that it thinks might be part of a future drag/drop action. It does this in the pdrEventTargets fields. I haven't been able to reproduce this yet in a small sample program, but in my larger program I can reproduce it at any time: 1) Hover over a component 2) Trigger some action with the keyboard which replaces or removes the hovered component 3) References to the replaced nodes still exist in pdrEventTargets (seen with VisualVM) The references disappear as soon as you press a mouse button (moving the mouse around isn't sufficient). Note that I'm not doing any drag'n'drop type actions nor do I use any drag'n'drop things in my program (it is fully keyboard controlled). There is code in Scene$MouseHandler to apparently deal with this case where a node gets removed, but it doesn't seem to help in a more complex UI. I'll attempt to debug this further, but would also appreciate any help if someone knows that code. The removal code: /** * Generates mouse exited event for a node which is going to be removed * and its children, where appropriate. * @param removing Node which is going to be removed */ void generateMouseExited(Node removing) { mouseHandler.handleNodeRemoval(removing); } In the "handleNodeRemoval" a lot of things are happening, but a lot of it is skipped when certain conditions aren't met (like "pdrInProgress"). As there won't be a DnD in progress I think the references are not being removed from the arraylists the MouseHandler is maintaining. Anyway, I hope the leak detecting code will be useful, I've been toying around with something like this for quite a while, and now that I've got something that is actually really useful for detecting leaks as soon as they happen I thought it be good to share. --John From johan.vos at gluonhq.com Sun Mar 28 12:24:11 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 28 Mar 2021 14:24:11 +0200 Subject: issues on javafxports/openjdk-jfx Message-ID: I'm creating a separate thread for this, as it might get lost in other threads. We see that issues are still created in the old github.com/javafxports/openjdk-jfx project. The README of that project clearly mentions that repository is obsolete, but the issue tracker is still open. It is not hard to close the issue tracker, but it seems there is no way to make it read-only. Hence, if we close it, we can not refer to it. I'm still in favor of closing it though. Thoughts? - Johan From hjohn at xs4all.nl Sun Mar 28 12:42:59 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 28 Mar 2021 14:42:59 +0200 Subject: Detecting memory leaks in a Scene In-Reply-To: References: Message-ID: Hah, managed to reproduce it in a small sample program. Filed bug: https://bugs.openjdk.java.net/browse/JDK-8264330 --John On 28/03/2021 14:03, John Hendrikx wrote: > I've created a bit of helper code I've been using to detect Nodes that > have been removed from a Scene that are not getting garbage collected. > > It takes a Scene as input, and will then monitor all Nodes that are > added and removed to compile a list of Nodes that are no longer part of > the Scene but are still being referenced. > > The code is here: > https://gist.github.com/hjohn/f7b2d5b6d56ba5e5bb6b6c5621799ca5 > > One major issue I've already discovered with this code (apart from my > own mistakes) is that Scene$MouseHandler is holding on to references to > Nodes that it thinks might be part of a future drag/drop action. It does > this in the pdrEventTargets fields. I haven't been able to reproduce > this yet in a small sample program, but in my larger program I > can reproduce it at any time: > > 1) Hover over a component > > 2) Trigger some action with the keyboard which replaces or removes > the hovered component > > 3) References to the replaced nodes still exist in pdrEventTargets > (seen with VisualVM) > > The references disappear as soon as you press a mouse button (moving the > mouse around isn't sufficient). Note that I'm not doing any drag'n'drop > type actions nor do I use any drag'n'drop things in my program (it is > fully keyboard controlled). > > There is code in Scene$MouseHandler to apparently deal with this case > where a node gets removed, but it doesn't seem to help in a more complex > UI. I'll attempt to debug this further, but would also appreciate any > help if someone knows that code. > > The removal code: > > /** > * Generates mouse exited event for a node which is going to be removed > * and its children, where appropriate. > * @param removing Node which is going to be removed > */ > void generateMouseExited(Node removing) { > mouseHandler.handleNodeRemoval(removing); > } > > In the "handleNodeRemoval" a lot of things are happening, but a lot of > it is skipped when certain conditions aren't met (like "pdrInProgress"). > As there won't be a DnD in progress I think the references are not being > removed from the arraylists the MouseHandler is maintaining. > > Anyway, I hope the leak detecting code will be useful, I've been toying > around with something like this for quite a while, and now that I've got > something that is actually really useful for detecting leaks as soon as > they happen I thought it be good to share. > > --John > From github.com+66004280+maran23 at openjdk.java.net Sun Mar 28 23:18:44 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Sun, 28 Mar 2021 23:18:44 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed Message-ID: This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. This bug only occurs, when a fixed cell size is set to the table. I also added 3 more tests beside the mandatory test, which tests my fix. 1 alternative test, which tests the same with no fixed cell size set. The other 2 tests are testing the same, but the table columns are set invisible instead. -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). See also: TableRowSkinBase#updateCells(boolean) ------------- Commit messages: - 8258663: Fixed issue, where TableRows with fixedCellSize set do not remove cells when the corresponding column is removed Changes: https://git.openjdk.java.net/jfx/pull/444/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=444&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258663 Stats: 166 lines in 2 files changed: 159 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/444.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/444/head:pull/444 PR: https://git.openjdk.java.net/jfx/pull/444 From fastegal at openjdk.java.net Mon Mar 29 11:43:29 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 11:43:29 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed In-Reply-To: References: Message-ID: On Sun, 28 Mar 2021 23:13:22 GMT, Marius Hanl wrote: > This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. > This bug only occurs, when a fixed cell size is set to the table. > > I also added 3 more tests beside the mandatory test, which tests my fix. > 1 alternative test, which tests the same with no fixed cell size set. > The other 2 tests are testing the same, but the table columns are set invisible instead. > > -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. > Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). > See also: TableRowSkinBase#updateCells(boolean) modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 556: > 554: } > 555: getChildren().removeAll(toRemove); > 556: } else if (resetChildren || cellsEmpty) { just curious : any idea why fixedCellSize was special-cased here? Not to clean them up sounds (and is) very much wrong, so there must have been a reason? ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From github.com+66004280+maran23 at openjdk.java.net Mon Mar 29 12:39:36 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Mon, 29 Mar 2021 12:39:36 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 11:40:40 GMT, Jeanette Winzenburg wrote: >> This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. >> This bug only occurs, when a fixed cell size is set to the table. >> >> I also added 3 more tests beside the mandatory test, which tests my fix. >> 1 alternative test, which tests the same with no fixed cell size set. >> The other 2 tests are testing the same, but the table columns are set invisible instead. >> >> -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. >> Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). >> See also: TableRowSkinBase#updateCells(boolean) > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 556: > >> 554: } >> 555: getChildren().removeAll(toRemove); >> 556: } else if (resetChildren || cellsEmpty) { > > just curious : any idea why fixedCellSize was special-cased here? Not to clean them up sounds (and is) very much wrong, so there must have been a reason? The '!fixedCellSizeEnabled' check is not needed, as we already check for fixedCellSizeEnabled in the main if condition. `if (fixedCellSizeEnabled) {...}` So before, it was like: `if (fixedCellSizeEnabled) {...} ` `else if (!fixedCellSizeEnabled && (resetChildren || cellsEmpty)) {...}` So we only execute the else condition, if fixedCellSizeEnabled is not true -> !fixedCellSizeEnabled. -> The check is not necessary, as fixedCellSizeEnabled must be false, when we come to the else condition. The variable fixedCellSizeEnabled is also a primitive boolean, so it can't be null, making this check obsolete. ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From fastegal at openjdk.java.net Mon Mar 29 15:01:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 15:01:49 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v3] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: SkinBase: changed javadoc for xxInvalidationListener ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/a342eba7..f93b6d8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=01-02 Stats: 17 lines in 1 file changed: 2 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Mar 29 15:20:29 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 15:20:29 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <5yA8Rb2Dl6THmmLjqowYElZk-vn1qzXmXTLOM6OYgN8=.a97a9085-2431-45fd-a4de-cd5e9ed07cc3@github.com> On Wed, 24 Mar 2021 23:18:25 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 250: > >> 248: * >> 249: * @param observable the observable to observe for invalidation events >> 250: * @param consumer the consumer > > Could be just me because I'm unfamiliar with this API, but I'd like to see an explanation for what the consumer is used for. If the consumer is executed on invalidation events on this observable, then clearly state it. Maybe the doc could be something like: > > Registers an action to take when an {@code Observable} is invalidated. > An {@code InvalidationListener} is registered on the given {@code observable} and the {@code consumer} is run > whenever the listener sends an invalidation event. If multiple consumers are registered on the same observable, > they are run in the order in which they were registered. > > @param observable the observable to observe for invalidation events > @param consumer the action to take when the observable is invalidated > > Since it's a `protected final` method, I don't think that the "Subclasses can use this..." portion is necessary - that's the only use of these methods. Changed the api doc along your suggestions (for invalidationListener related methods only - those for the other types of listener will be changed analogously once the wording is agreed on :) did deviate a bit from your suggestion in - instead of _action to take_ I used _operation to perform_ because in ui contexts, _action_ feels a bit loaded and the replacement is from the doc of Consumer in its overview and method doc for accept - removed mentioning of InvalidationListener: while we do have it, the when/how/how many are added is an implementation detail Also clarified the null handling: both parameters can be null, if so nothing happens. Still not quite clear, when to use code tags in the description (vs. plain words) - [styling doc](https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html) seems to advocate it for all class names, actual java doc (including javafx doc) seems to use it inconsistently. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Mar 29 15:28:32 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 15:28:32 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:39:13 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 264: > >> 262: * {@link #registerInvalidationListener(Observable, Consumer)} >> 263: * for the given observable. The end result is that the given observable is no longer observed by any of the invalidation >> 264: * listeners, but it may still have additional listeners registered on it through means outside of > > Maybe instead of "The end result..." something like: > > Only listeners that were registered using the aforementioned method are removed; listeners registered through other means are unaffected. did a complete overhaul - thinking that clarification is no longer needed: stating to remove all that have been registered with the registration method should be enough (there is no other way to inject additional consumers). I think that trying to be over-clear on removing _all_ was a result of the debates at the time it was introduced (we did a bit of dancing then ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From ajoseph at openjdk.java.net Mon Mar 29 15:35:49 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 29 Mar 2021 15:35:49 GMT Subject: RFR: 8262276: Debug build of WebKit fails [v2] In-Reply-To: References: Message-ID: > Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix InternalFunction crash ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/417/files - new: https://git.openjdk.java.net/jfx/pull/417/files/6cab829e..31ea28c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=417&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=417&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417 From fastegal at openjdk.java.net Mon Mar 29 15:43:33 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 15:43:33 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: Message-ID: <_h-cNm6vO3zxqEU-H23VfE4HPvOxHucS3-zBJRucYhE=.8eda533a-d4ab-421d-a414-ab0052ac293b@github.com> On Wed, 24 Mar 2021 23:28:47 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed missing/incorrect @since tags in new api doc > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 268: > >> 266: * >> 267: * @param observable The observable for which all listeners should be removed. >> 268: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through > > 1. There's no need for a `@link` on a class that is in the arguments or return of the method since they are linked there anyway, and it is recommended to use `@link` only the first time the class appears. > > 2. You might want to clarify that by "chained" you mean that they were composed using `Consumer#andThen`, either using `@plainlink` on "chained", or explicitly by "chained using Consumer#andThen`. Then again, it might be obvious. - kept only the link to the registerXX method (to clarify the scope of the removal) - replaced "chained" by "composed" - concentrated on what that composed consumer does (performs all removed operations) Not entirely certain whether it's clear enough now - should the description have an additional sentence `Returns a composed [same-as-in-returns]` Undecided. - should the `same-as-in-returns` contain the specification of the sequence of performing (from the register method)? Tend to no (because it's getting too long), but then .. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Mon Mar 29 15:53:55 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Mar 2021 15:53:55 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v4] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/f93b6d8e..68d70c6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at openjdk.java.net Mon Mar 29 17:30:28 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 29 Mar 2021 17:30:28 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v4] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 15:53:55 GMT, Jeanette Winzenburg wrote: >> Changes in Lambda..Handler: >> - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners >> - added java doc >> - added tests >> >> Changes in SkinBase >> - added api (and implementation delegating to the handler) >> - copied java doc from the change listener un/register methods >> - added tests to verify that the new (and old) api is indeed delegating to the handler >> >> Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed trailing whitespace modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 246: > 244: /** > 245: * Registers an operation to perform when the given {@code Observable} sends an invalidation event. > 246: * Does nothing if observable or operation is {@code null}. I would write "Does nothing if either {@code observable} or {@code operation} are {@code null}" modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 265: > 263: * Unregisters all operations that have been registered using > 264: * {@link #registerInvalidationListener(Observable, Consumer)} > 265: * for the given observable. If the parameter can be `null`, mention what happens like in `registerInvalidationListener`. modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: > 268: * may be {@code null} > 269: * @return a composed consumer that performs all removed operations or > 270: * {@code null} if none has been registered or the observable is {@null} * Comma before the first "or" * "none *have* been" ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From nlisker at openjdk.java.net Mon Mar 29 17:34:26 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 29 Mar 2021 17:34:26 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <5yA8Rb2Dl6THmmLjqowYElZk-vn1qzXmXTLOM6OYgN8=.a97a9085-2431-45fd-a4de-cd5e9ed07cc3@github.com> References: <5yA8Rb2Dl6THmmLjqowYElZk-vn1qzXmXTLOM6OYgN8=.a97a9085-2431-45fd-a4de-cd5e9ed07cc3@github.com> Message-ID: On Mon, 29 Mar 2021 15:17:22 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 250: >> >>> 248: * >>> 249: * @param observable the observable to observe for invalidation events >>> 250: * @param consumer the consumer >> >> Could be just me because I'm unfamiliar with this API, but I'd like to see an explanation for what the consumer is used for. If the consumer is executed on invalidation events on this observable, then clearly state it. Maybe the doc could be something like: >> >> Registers an action to take when an {@code Observable} is invalidated. >> An {@code InvalidationListener} is registered on the given {@code observable} and the {@code consumer} is run >> whenever the listener sends an invalidation event. If multiple consumers are registered on the same observable, >> they are run in the order in which they were registered. >> >> @param observable the observable to observe for invalidation events >> @param consumer the action to take when the observable is invalidated >> >> Since it's a `protected final` method, I don't think that the "Subclasses can use this..." portion is necessary - that's the only use of these methods. > > Changed the api doc along your suggestions (for invalidationListener related methods only - those for the other types of listener will be changed analogously once the wording is agreed on :) > > did deviate a bit from your suggestion in > > - instead of _action to take_ I used _operation to perform_ because in ui contexts, _action_ feels a bit loaded and the replacement is from the doc of Consumer in its overview and method doc for accept > - removed mentioning of InvalidationListener: while we do have it, the when/how/how many are added is an implementation detail > > Also clarified the null handling: both parameters can be null, if so nothing happens. > > Still not quite clear, when to use code tags in the description (vs. plain words) - [styling doc](https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html) seems to advocate it for all class names, actual java doc (including javafx doc) seems to use it inconsistently. The changes look good. We use code tags when we refer to terms found in code, such as class, method and argument names, and literal like `true`, `class` and `null`. The docs have not been consistent, I know, but wherever we touch we try to fix it along the way. It's just not worth to do fixes specifically for that. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From github.com+31666175+jonathanvusich at openjdk.java.net Mon Mar 29 22:21:45 2021 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Mon, 29 Mar 2021 22:21:45 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> <7ivK8A9fCK-8XRFBlGkBkoWRP5xuwDDy_P8tNSKHxYE=.c81f3909-bc9c-4d85-a837-8ade6afc27d9@github.com> Message-ID: On Wed, 3 Feb 2021 17:08:17 GMT, Jeanette Winzenburg wrote: >> wondering about the system test - what stands in the way to add a simple "normal" unit test? > >> >> >> wondering about the system test - what stands in the way to add a simple "normal" unit test? > > looks like there might be a bug in StubFontLoader that makes a normal unit test fail w/out the fix: Axis uses a Text field (measure) for measuring size requirements for the tick labels - its font has no nativeFont set in the stub context such that all fields of the bounds of text are always 0, consequently the change in autoRange never kicks in. Hacking around with explicitly setting a tickLabelFont gives us a test that fails before and passes after the fix: > > @Test > public void testRotatedStandAlone() { > Pane root = new Pane(); > Scene scene = new Scene(root); > Stage stage = new Stage(); > stage.setScene(scene); > CategoryAxis xAxis = new CategoryAxis(FXCollections.observableArrayList(categories)); > // hack around stubFontLoader bug (?feature) > xAxis.setTickLabelFont(new Font(8)); > BarChart chart = new BarChart<>(xAxis, new NumberAxis()); > chart.setPrefWidth(400); > root.getChildren().add(chart); > stage.show(); > assertEquals(90, xAxis.getTickLabelRotation(), 0.1); > } > > Question is why the stubFontLoader fails: its load implementation looks like it should always set the nativeFont fiel to a fitting test font, but it doesn't if the name is a plain "Amble" (vs. a more specialized like "Amble Regular"). @kleopatra @kevinrushforth Are the system tests that I have provided sufficient for this PR to move forward or do they need to be rewritten as unit tests? ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From nlisker at gmail.com Mon Mar 29 22:35:18 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 30 Mar 2021 01:35:18 +0300 Subject: issues on javafxports/openjdk-jfx In-Reply-To: References: Message-ID: Can you make it private? This way we could still see if there are relevant issues there like those that halted during the transition. On Sun, Mar 28, 2021 at 3:24 PM Johan Vos wrote: > I'm creating a separate thread for this, as it might get lost in other > threads. > We see that issues are still created in the old > github.com/javafxports/openjdk-jfx project. The README of that project > clearly mentions that repository is obsolete, but the issue tracker is > still open. > It is not hard to close the issue tracker, but it seems there is no way to > make it read-only. Hence, if we close it, we can not refer to it. > I'm still in favor of closing it though. > > Thoughts? > > - Johan > From thiago.sayao at gmail.com Tue Mar 30 00:25:39 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 29 Mar 2021 21:25:39 -0300 Subject: Wayland glass backend Message-ID: I've been superficially looking into this (wayland). Seems like we could bind libwayland to java and build a managed backend from there. This would be so cool. Looks like here is an easy way to create bindings: https://github.com/wayland-project/wayland/blob/master/protocol/wayland.xml It's too much to tackle alone, but would dig in if anyone else is interested. Cheers From tbee at tbee.org Tue Mar 30 05:18:33 2021 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 30 Mar 2021 07:18:33 +0200 Subject: javafx-maven-plugin eclipse java version In-Reply-To: <2ed205a1-c8d6-6987-234c-175b991134c1@tbee.org> References: <831e1805-17bc-d656-0034-b22730567464@tbee.org> <10f8919e-df23-6cd1-7aeb-efb46c6e5507@tbee.org> <2ed205a1-c8d6-6987-234c-175b991134c1@tbee.org> Message-ID: Interesting. Is anyone monitoring the plugin repo? On 2021-03-28 13:12, Tom Eugelink wrote: > Added toolchains support to javafx-maven-plugin and created a PR. > https://github.com/openjfx/javafx-maven-plugin/pull/118 > > So you can do: > > > org.apache.maven.plugins > maven-toolchains-plugin > 3.0.0 > > > > toolchain > > > > > > > ${maven.compiler.release} > > > > > > That will make sure the same JDK is used for compiling and javafx:run (given the PR is merged). > > The easiest way to get that setup is using sdkman, install the required jdks, then also install jbang (sdk install jbang) and run 'jbang sdkman at tbee/mavenToolchains' > > > > > On 2021-03-27 10:47, Tom Eugelink wrote: >> The plugin has an executable option which can refer to the java executable. Per it uses the system default, which apparently is different between my bash and the shell that eclipse uses. If I hard code the correct path, it works correctly. >> >> But a hardcoded path is not okay, so I'm going to try and see if I can make a PR so the plugin use the same java as the compiler. That would make it less unpredictable. And possibly use toolchains, since I now know it exists :-) >> > From fastegal at openjdk.java.net Tue Mar 30 09:53:55 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 09:53:55 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v5] In-Reply-To: References: Message-ID: > Changes in Lambda..Handler: > - added api and implemenation to support invalidation and listChange listeners in the same way as changeListeners > - added java doc > - added tests > > Changes in SkinBase > - added api (and implementation delegating to the handler) > - copied java doc from the change listener un/register methods > - added tests to verify that the new (and old) api is indeed delegating to the handler > > Note that the null handling is slightly extended: all methods now can handle both null consumers (as before) and null observables (new) - this allows simplified code on rewiring "path" properties (see reference example in the issue) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: xxInvalidationListener: changed doc as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/409/files - new: https://git.openjdk.java.net/jfx/pull/409/files/68d70c6b..cf3a0228 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=409&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/409.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/409/head:pull/409 PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Mar 30 10:09:31 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 10:09:31 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> Message-ID: On Thu, 25 Mar 2021 14:07:24 GMT, Jeanette Winzenburg wrote: >> I see. I recommend that they be improved in this PR. I don't know if this will need to be part of the CSR, though. > > @nlisker and @Kevin so we agree, thanks :) > > my plan: > > - will work on the exact doc along the lines of Nir's suggestion for the un-/registerInvalidationListener methods > - once that's basically agreed upon, will c&p the spec (with adjustments) to the methods for the other listener types > - at a last step, create the csr draft (that would be a patch for the changeListener methods and simply added spec for the new methods, I assume?) hmm ... failing checks, why? ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Mar 30 10:09:33 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 10:09:33 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v4] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 17:17:30 GMT, Nir Lisker wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed trailing whitespace > > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 246: > >> 244: /** >> 245: * Registers an operation to perform when the given {@code Observable} sends an invalidation event. >> 246: * Does nothing if observable or operation is {@code null}. > > I would write "Does nothing if either {@code observable} or {@code operation} are {@code null}" Done. Also changed leading upper-case of observable in first sentence to lower-case - for consistency because I don't see a difference between both, blind me? ;) > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 265: > >> 263: * Unregisters all operations that have been registered using >> 264: * {@link #registerInvalidationListener(Observable, Consumer)} >> 265: * for the given observable. > > If the parameter can be `null`, mention what happens like in `registerInvalidationListener`. done > modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 270: > >> 268: * may be {@code null} >> 269: * @return a composed consumer that performs all removed operations or >> 270: * {@code null} if none has been registered or the observable is {@null} > > * Comma before the first "or" > * "none *have* been" thanks :) Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Mar 30 10:19:39 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 10:19:39 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6] In-Reply-To: References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> <7ivK8A9fCK-8XRFBlGkBkoWRP5xuwDDy_P8tNSKHxYE=.c81f3909-bc9c-4d85-a837-8ade6afc27d9@github.com> Message-ID: On Mon, 29 Mar 2021 22:19:08 GMT, Jonathan Vusich wrote: > > > @kleopatra @kevinrushforth Are the system tests that I have provided sufficient for this PR to move forward or do they need to be rewritten as unit tests? good question :) Personally, I would also add a unit test (even though it requires that hacky bit), it's more likely to be "seen". But also fine as-is, that is having system tests, IMO. Didn't run them, though .. *cough ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From fastegal at openjdk.java.net Tue Mar 30 10:31:26 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 10:31:26 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 12:35:23 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 556: >> >>> 554: } >>> 555: getChildren().removeAll(toRemove); >>> 556: } else if (resetChildren || cellsEmpty) { >> >> just curious : any idea why fixedCellSize was special-cased here? Not to clean them up sounds (and is) very much wrong, so there must have been a reason? > > The '!fixedCellSizeEnabled' check is not needed, as we already check for fixedCellSizeEnabled in the main if condition. > `if (fixedCellSizeEnabled) {...}` > > So before, it was like: > `if (fixedCellSizeEnabled) {...} ` > `else if (!fixedCellSizeEnabled && (resetChildren || cellsEmpty)) {...}` > > So we only execute the else condition, if fixedCellSizeEnabled is not true -> !fixedCellSizeEnabled. -> The check is not necessary, as fixedCellSizeEnabled must be false, when we come to the else condition. > The variable fixedCellSizeEnabled is also a primitive boolean, so it can't be null, making this check obsolete. > > Edit: If you mean the special handling for fixed cell size in general, I have no idea. This was added in a commit from Jonathan Giles stating, that he fixed a performance problem with fixed cell size. So maybe instead of resetting all the cells, only the affected are removed/added by this, leading to a performance boost? yeah, was curious about the stuff in your "edit" paragraph. And thanks for the explanation of the if-block, didn't see the whole .. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Tue Mar 30 12:46:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Mar 2021 12:46:10 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> Message-ID: <7ehPxSdqty46PURLEnA7iR3vqyK--zzz0maQK_osOG0=.323f728c-d30f-46da-8697-16d9c43f1db1@github.com> On Tue, 30 Mar 2021 10:06:58 GMT, Jeanette Winzenburg wrote: > hmm ... failing checks, why? The failure on Windows is because your branch isn't up-to-date with `master`, and is missing a recent fix to the Window build. You can either `git merge master` (after updating your `master` branch from the upstream repo) or ignore the error. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From fastegal at openjdk.java.net Tue Mar 30 13:30:10 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 13:30:10 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed In-Reply-To: References: Message-ID: On Sun, 28 Mar 2021 23:13:22 GMT, Marius Hanl wrote: > This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. > This bug only occurs, when a fixed cell size is set to the table. > > I also added 3 more tests beside the mandatory test, which tests my fix. > 1 alternative test, which tests the same with no fixed cell size set. > The other 2 tests are testing the same, but the table columns are set invisible instead. > > -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. > Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). > See also: TableRowSkinBase#updateCells(boolean) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 132: > 130: // We save the first table row to check it later. > 131: AtomicReference> tableRowRef = new AtomicReference<>(); > 132: wondering a bit about this complicated test setup .. are you aware of the VirtualFlowTestUtils (in test.something.infrastructure)? Using it, a test would shrink down to something like: @Test public void testRemoveColumnsFixed() { tableView.setFixedCellSize(20); tableView.getColumns().remove(0, 2); Toolkit.getToolkit().firePulse(); assertEquals(tableView.getVisibleLeafColumns().size(), VirtualFlowTestUtils.getCell(tableView, 0).getChildrenUnmodifiable().size()); } Or what am I missing? ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From fastegal at openjdk.java.net Tue Mar 30 13:34:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Mar 2021 13:34:11 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <7ehPxSdqty46PURLEnA7iR3vqyK--zzz0maQK_osOG0=.323f728c-d30f-46da-8697-16d9c43f1db1@github.com> References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> <7ehPxSdqty46PURLEnA7iR3vqyK--zzz0maQK_osOG0=.323f728c-d30f-46da-8697-16d9c43f1db1@github.com> Message-ID: On Tue, 30 Mar 2021 12:43:41 GMT, Kevin Rushforth wrote: > > The failure on Windows is because your branch isn't up-to-date with `master`, and is missing a recent fix to the Window build. You can either `git merge master` (after updating your `master` branch from the upstream repo) or ignore the error. thanks for the info - will ignore for now, the merge/rebase will happen after approval anyway :) ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kevin.rushforth at oracle.com Tue Mar 30 14:28:50 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Mar 2021 07:28:50 -0700 Subject: Proposed schedule for JavaFX 17 Message-ID: ?Here is the proposed schedule for JavaFX 17. RDP1: Jul 8, 2021 (aka ?feature freeze?) RDP2: Jul 29, 2021 Freeze: Aug 19, 2021 GA: Sep 7, 2021 We plan to fork a jfx16 stabilization branch at RDP1. The GA date is expected to be one week ahead of JDK 17, matching what we did for 16. As was done for the previous release, the start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From kevin.rushforth at oracle.com Tue Mar 30 14:30:37 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Mar 2021 07:30:37 -0700 Subject: Proposed schedule for JavaFX 17 In-Reply-To: References: Message-ID: <88e02367-1438-57e5-b243-578feb74ad8e@oracle.com> I just noticed a copy/paste error: > We plan to fork a jfx16 stabilization branch at RDP1. That should be a "jfx17" branch. -- Kevin On 3/30/2021 7:28 AM, Kevin Rushforth wrote: > ?Here is the proposed schedule for JavaFX 17. > > RDP1: Jul 8, 2021 (aka ?feature freeze?) > RDP2: Jul 29, 2021 > Freeze: Aug 19, 2021 > GA: Sep 7, 2021 > > We plan to fork a jfx16 stabilization branch at RDP1. The GA date is > expected to be one week ahead of JDK 17, matching what we did for 16. > > As was done for the previous release, the start of RDP1, the start of > RDP2, and the code freeze will be 16:00 UTC on the respective dates. > > Please let Johan or me know if you have any questions. > > -- Kevin > From github.com+66004280+maran23 at openjdk.java.net Tue Mar 30 15:54:37 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 30 Mar 2021 15:54:37 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: > This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. > This bug only occurs, when a fixed cell size is set to the table. > > I also added 3 more tests beside the mandatory test, which tests my fix. > 1 alternative test, which tests the same with no fixed cell size set. > The other 2 tests are testing the same, but the table columns are set invisible instead. > > -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. > Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). > See also: TableRowSkinBase#updateCells(boolean) Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8258663: Using VirtualFlowTestUtils in tests now instead of own solution -> cleaner code ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/444/files - new: https://git.openjdk.java.net/jfx/pull/444/files/acc19ee4..a2a331a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=444&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=444&range=00-01 Stats: 55 lines in 1 file changed: 4 ins; 37 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/444.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/444/head:pull/444 PR: https://git.openjdk.java.net/jfx/pull/444 From github.com+66004280+maran23 at openjdk.java.net Tue Mar 30 15:54:38 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 30 Mar 2021 15:54:38 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:27:21 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258663: Using VirtualFlowTestUtils in tests now instead of own solution -> cleaner code > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 132: > >> 130: // We save the first table row to check it later. >> 131: AtomicReference> tableRowRef = new AtomicReference<>(); >> 132: > > wondering a bit about this complicated test setup .. are you aware of the VirtualFlowTestUtils (in test.something.infrastructure)? Using it, a test would shrink down to something like: > > @Test > public void testRemoveColumnsFixed() { > tableView.setFixedCellSize(20); > tableView.getColumns().remove(0, 2); > Toolkit.getToolkit().firePulse(); > assertEquals(tableView.getVisibleLeafColumns().size(), > VirtualFlowTestUtils.getCell(tableView, 0).getChildrenUnmodifiable().size()); > } > > Or what am I missing? Nice catch! I tried it out and it works! And indeed the code looks much better now. To be fair, I had a brief look at VirtualFlowTestUtils, as other table/cell tests uses it. Next time I should take a closer look. :P I pushed your suggested change. ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From jgneff at openjdk.java.net Tue Mar 30 16:24:34 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Mar 2021 16:24:34 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH Message-ID: This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) $ bash gradlew sdk jmods javadoc $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod The three commands: 1. set the build timestamp to the date of the latest source code change, 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and 3. recreate the JMOD files with stable file modification times and ordering. The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. #### Fixes There are at least four sources of non-determinism in the JavaFX builds: 1. Build timestamp The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. 2. Modification times The JAR, JMOD, and ZIP archives store the modification time of each file. 3. File ordering The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. 4. Build path The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. [1]: https://reproducible-builds.org/docs/source-date-epoch/ [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism ------------- Commit messages: - Enable reproducible builds with SOURCE_DATE_EPOCH - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Changes: https://git.openjdk.java.net/jfx/pull/446/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264449 Stats: 36 lines in 3 files changed: 22 ins; 10 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/446.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/446/head:pull/446 PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Tue Mar 30 16:33:16 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Mar 2021 16:33:16 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: Message-ID: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> On Tue, 30 Mar 2021 16:20:21 GMT, John Neffenger wrote: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism I think there might be a Skara bug. The pre-submit builds on Linux, macOS, and Windows completed immediately. I think that's because the first of the two commits in this pull request includes the Java Bug ID from [another pending pull request][1], because this pull request is a continuation of that one. I can squash the two commits and force-push the changes, if that would help. [1]: https://github.com/openjdk/jfx/pull/422 ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Tue Mar 30 16:44:15 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Mar 2021 16:44:15 GMT Subject: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH In-Reply-To: References: <-6Tu_Q1VN3A5ZURtTigsIOT6Q2vgllZo2mYIuw5cmZA=.14408107-1821-4255-b1b3-67d94f63642b@github.com> Message-ID: On Thu, 25 Mar 2021 02:35:24 GMT, John Neffenger wrote: >>> @jgneff Could not parse `bmwiedemann` as a valid contributor. >> >> You might retry the "contributor" command with the `@` before their GitHub username (I'm not 100% sure that will work, though). > >> You might retry the "contributor" command with the `@` before their GitHub username. > > Thanks. I'll try that now. I checked and Bernhard is on the list of "OCAs submitted prior to 2021," but not on the OpenJDK Census list, in case that matters. > > By the way, should I be adding my own name, too? It looks as if sometimes people do that and sometimes not. That would put me as "Author" and also on a line with "Co-authored-by" in the commit message. > This is a simple enough change by itself, but since it is intended as the start of a larger effort, I'd like @johanvos (or someone else he designates from Gluon) to be a second reviewer. I jumped the gun and created the [follow-up pull request][1]. I thought it might help when reviewing this pull request to have a full picture of that larger effort. Although these two changes are part of a huge undertaking in the open-source community, it turns out that the changes required on our part are quite small. [1]: https://github.com/openjdk/jfx/pull/446 ------------- PR: https://git.openjdk.java.net/jfx/pull/422 From john at status6.com Tue Mar 30 18:16:15 2021 From: john at status6.com (John Neffenger) Date: Tue, 30 Mar 2021 11:16:15 -0700 Subject: issues on javafxports/openjdk-jfx In-Reply-To: References: Message-ID: <98f3f1a7-812b-46fb-2d91-2168ec348027@status6.com> On 3/28/21 5:24 AM, Johan Vos wrote: > I'm still in favor of closing it though. It would be nice if there were a way in GitHub to close the repository to new issues but keep the old ones public and editable. For example, I'm still getting good information on the old closed issues, even as recently as last week: mgroth0 commented 8 days ago https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-804546080 That doesn't seem possible, though. I can find only a checkbox to enable or disable issues. John From kevin.rushforth at oracle.com Tue Mar 30 18:27:12 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Mar 2021 11:27:12 -0700 Subject: issues on javafxports/openjdk-jfx In-Reply-To: <98f3f1a7-812b-46fb-2d91-2168ec348027@status6.com> References: <98f3f1a7-812b-46fb-2d91-2168ec348027@status6.com> Message-ID: <1c2aa991-7d4a-e0ec-0caf-a9b0be7ccc51@oracle.com> Would archiving the repository work for this? [1] -- Kevin [1] https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository On 3/30/2021 11:16 AM, John Neffenger wrote: > On 3/28/21 5:24 AM, Johan Vos wrote: >> I'm still in favor of closing it though. > > It would be nice if there were a way in GitHub to close the repository > to new issues but keep the old ones public and editable. For example, > I'm still getting good information on the old closed issues, even as > recently as last week: > > mgroth0 commented 8 days ago > https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-804546080 > > > That doesn't seem possible, though. I can find only a checkbox to > enable or disable issues. > > John From john at status6.com Tue Mar 30 18:49:18 2021 From: john at status6.com (John Neffenger) Date: Tue, 30 Mar 2021 11:49:18 -0700 Subject: E-mail addresses at openjdk.org In-Reply-To: References: <20b61f7d-1f55-f4f9-8a63-bba981c1c2d5@status6.com> Message-ID: <4033db16-7f75-bdf4-0e48-76f2aff0f2d9@status6.com> On 3/25/21 4:12 AM, Kevin Rushforth wrote: > Until then, adding the email address as an unverified additional email > address in your GitHub profile is the way to go. And the first GitHub user to claim the address wins! There are a large number of unclaimed commits in our repository that are up for grabs, as far as GitHub is concerned. Worse yet, the GitHub website masks the real name and e-mail address in the commit with the name of the GitHub user who claimed it. It's not a security issue for the project or any of its contributors, but I suppose it could be used as a form of identify theft. It takes just a few seconds to add your openjdk.org address, if you have one, to your GitHub profile. John From jgneff at openjdk.java.net Tue Mar 30 19:12:23 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Mar 2021 19:12:23 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Tue, 30 Mar 2021 16:30:25 GMT, John Neffenger wrote: > I think there might be a Skara bug. No, no bug. Sorry about that. I just don't know how GitHub works. :frowning_face: The pre-submit tests ran two days ago when I pushed the branch to GitHub, so by the time I submitted the pull request, they had finished long ago. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From nlisker at openjdk.java.net Tue Mar 30 19:28:10 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 30 Mar 2021 19:28:10 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: References: <_GY-A0UoA5OFIlVIpArONMnxD4obCTZpeDvL7UBEq6A=.00854931-56c3-43fb-9f74-66f722301e93@github.com> <8xrwbg4m1A6mrWRATKhUJLadf3_1kwK7E5nMesVv9g8=.2381bde0-22c5-4f17-b5b8-afece7566067@github.com> <7ehPxSdqty46PURLEnA7iR3vqyK--zzz0maQK_osOG0=.323f728c-d30f-46da-8697-16d9c43f1db1@github.com> Message-ID: On Tue, 30 Mar 2021 13:31:36 GMT, Jeanette Winzenburg wrote: >>> hmm ... failing checks, why? >> >> The failure on Windows is because your branch isn't up-to-date with `master`, and is missing a recent fix to the Window build. You can either `git merge master` (after updating your `master` branch from the upstream repo) or ignore the error. > >> >> The failure on Windows is because your branch isn't up-to-date with `master`, and is missing a recent fix to the Window build. You can either `git merge master` (after updating your `master` branch from the upstream repo) or ignore the error. > > thanks for the info - will ignore for now, the merge/rebase will happen after approval anyway :) I think that the docs are ready for the CSR now. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From kcr at openjdk.java.net Tue Mar 30 19:54:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Mar 2021 19:54:13 GMT Subject: RFR: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners [v2] In-Reply-To: <_h-cNm6vO3zxqEU-H23VfE4HPvOxHucS3-zBJRucYhE=.8eda533a-d4ab-421d-a414-ab0052ac293b@github.com> References: <_h-cNm6vO3zxqEU-H23VfE4HPvOxHucS3-zBJRucYhE=.8eda533a-d4ab-421d-a414-ab0052ac293b@github.com> Message-ID: <27_EOvST9gK-UUEFu927mhSWZChYJWaSIbuJJHy_n5I=.cd1547bb-39f2-476c-a995-52d90a683b41@github.com> On Mon, 29 Mar 2021 15:39:58 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java line 268: >> >>> 266: * >>> 267: * @param observable The observable for which all listeners should be removed. >>> 268: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through >> >> 1. There's no need for a `@link` on a class that is in the arguments or return of the method since they are linked there anyway, and it is recommended to use `@link` only the first time the class appears. >> >> 2. You might want to clarify that by "chained" you mean that they were composed using `Consumer#andThen`, either using `@plainlink` on "chained", or explicitly by "chained using Consumer#andThen`. Then again, it might be obvious. > > - kept only the link to the registerXX method (to clarify the scope of the removal) > - replaced "chained" by "composed" > - concentrated on what that composed consumer does (performs all removed operations) > > Not entirely certain whether it's clear enough now > > - should the description have an additional sentence `Returns a composed [same-as-in-returns]` Undecided. > - should the `same-as-in-returns` contain the specification of the sequence of performing (from the register method)? Tend to no (because it's getting too long), but then .. I haven't gone back and done a detailed review yet, but I like the overall changes. The one thing I did notice is that the language used to describe the return value of `unregisterInvalidationListeners` and `unregisterListChangeListeners` is different: unregisterInvalidationListeners: * @return a composed consumer that performs all removed operations, or * {@code null} if none have been registered or the observable is {@code null} unregisterListChangeListeners: * @return A single chained {@link Consumer} consisting of all {@link Consumer consumers} registered through * {@link #registerListChangeListener(ObservableList, Consumer)}. If no consumers have been registered on this * list, null will be returned. I find it confusing to say that the returned list "performs all removed operations", so I like the language in the latter method better. Some might interpret the former to mean that is is somehow necessary to call the returned chained consumer as part of the removal, which isn't what you meant to say. ------------- PR: https://git.openjdk.java.net/jfx/pull/409 From jgneff at openjdk.java.net Tue Mar 30 22:19:16 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Mar 2021 22:19:16 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 22:58:57 GMT, Kevin Rushforth wrote: > Build fails on my system with `FAIL: WINSDK_DIR not defined` @palexdev I hit that error, too. You may have already found this, but you can work around the problem by using the sample [`windows_tools.properties`][1] file on the Building OpenJFX page (click "Expand source"). You just have to adjust the `WINDOWS_VS_PATH` and remember to copy the file to `build/windows_tools.properties` after running `gradle clean` and before running a build. [1]: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Missingpathsissue ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From almatvee at openjdk.java.net Wed Mar 31 05:21:48 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 31 Mar 2021 05:21:48 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 Message-ID: - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. ------------- Commit messages: - 8262366: Update glib to version 2.66.7 Changes: https://git.openjdk.java.net/jfx/pull/447/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=447&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262366 Stats: 39553 lines in 439 files changed: 23426 ins; 5427 del; 10700 mod Patch: https://git.openjdk.java.net/jfx/pull/447.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/447/head:pull/447 PR: https://git.openjdk.java.net/jfx/pull/447 From jhendrikx at openjdk.java.net Wed Mar 31 05:44:20 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 05:44:20 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes Message-ID: Small fix to clear a reference to a removed node left by Scene$MouseHandler. ------------- Commit messages: - 8264330: Scene MouseHandler is referencing removed nodes Changes: https://git.openjdk.java.net/jfx/pull/448/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=448&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264330 Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/448.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/448/head:pull/448 PR: https://git.openjdk.java.net/jfx/pull/448 From fkirmaier at openjdk.java.net Wed Mar 31 09:28:09 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 31 Mar 2021 09:28:09 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: Message-ID: <4sMuGaAW87f-lxLMt-13WyjuGsEZpuv3SAtgZnKd-VI=.17ae6bc1-b071-46eb-80c1-6216909d0642@github.com> On Fri, 26 Mar 2021 12:26:53 GMT, Jeanette Winzenburg wrote: >> To clarify, this with happening with ListViews in production code. >> In some conditions, the status of a single cell doesn't update. The effect is, that a Cell is stuck in the Editing mode. >> If I remember correctly, it was irreversible stuck. It happened rarely, it might be connected to cells with variable sizes. >> >> Handling the logic from the ListView seems wrong to me, I think the ListCell should update its state automatically dependent of the properties. But I wouldn't know where to add it in the ListView. If that's how it's done in the other cell-based components, then it would make sense and the code more linear. I'm not really opinionated on how to solve it, just went for the simplest fix I've found. > >> >> Handling the logic from the ListView seems wrong to me, > > looks like I was unclear, because that's a 100% me-too :) > > Reformulating my second sentence in test snippets: > > A: > cell.updateIndex(1); > list.edit(1); > cell.updateIndex(0); > // failing/passing before/after fix > assertFalse("cell re-use must update cell editing state" , cell.isEditing()); > > B: > List events = new ArrayList(); > list.setOnEditCancel(e -> { > events.add(e); > }); > .... setup test state as in A > // passing/failing before/after fix > assertTrue("cell re-use must not trigger edit events", events.isEmpty()); > > C: > .... setup test state as in A > // passing/passing before/after fix > assertEquals("cell re-use must not change list editing state", 1, list.getEditingIndex); > > My question was, whether we agree on B. My wondering was about C passing in the light of B failing. I don't think B is right. I would expect a editCancel event when the index of an editing cell is changed. If there would be another cell, which will get the index 1 (which isn't the case in this artifical test) then i would expect another editStart event. On the perspective of the ListView, the index never changes, but it's more relevant that some of the cells cancel/start the editing. If one would want to avoid the cancelEdit, when the index is not changing, then the solution should be to make sure, the index of editing cells never changes, which isn't the scope of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From github.com+66004280+maran23 at openjdk.java.net Wed Mar 31 10:32:18 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 31 Mar 2021 10:32:18 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:36:06 GMT, John Hendrikx wrote: > Small fix to clear a reference to a removed node left by Scene$MouseHandler. modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line 978: > 976: > 977: @Test public void testNoReferencesRemainToRemovedNodeAfterBeingClicked() { > 978: StubToolkit toolkit = (StubToolkit) Toolkit.getToolkit(); This cast isn't necessary, is it? ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From jpereda at openjdk.java.net Wed Mar 31 11:02:17 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 31 Mar 2021 11:02:17 GMT Subject: RFR: 8264501: UIWebView for iOS is deprecated Message-ID: This PR replaces the deprecated iOS native view for web (UIWebView) with WKWebView. While most of the native API can be easily replaced from one to the other, there are some changes that affect the scripts execution, and therefore some minor changes in WebEngine/JS2JavaBridge are required. There is also a side effect if named members of JS objects are used via JSObject::setMember. The Java callbacks to JavaScript are now async, and the return value will be ignored. A workaround is to use JSObject::call instead to pass that value. This should be dealt with in a follow-up issue. Also, a peer is provided to allow having a JavaFX node that can be resized and relocated. This PR has been tested on iOS, loading URLs and local html files with JS scripts. ------------- Commit messages: - Replace UIWebView with WKWebView Changes: https://git.openjdk.java.net/jfx/pull/449/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=449&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264501 Stats: 264 lines in 9 files changed: 175 ins; 17 del; 72 mod Patch: https://git.openjdk.java.net/jfx/pull/449.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/449/head:pull/449 PR: https://git.openjdk.java.net/jfx/pull/449 From ed at kennard.net Wed Mar 31 11:29:49 2021 From: ed at kennard.net (Ed Kennard) Date: Wed, 31 Mar 2021 11:29:49 +0000 Subject: Fully custom theme vs overriding Modena Message-ID: <23A56B2A-93CB-4424-8EA5-C24BE9243529@kennard.net> Hi all, I?m about to embark on some work which will remove our dependency on the Modena theme. We currently import Modena then override it wherever necessary, but now I want to replace that with our own custom CSS built from the ground up. The new custom CSS will be simpler and flatter than Modena, using a lot less insets, borders etc on the controls, and will only target the specific controls we need styling for in the app, so the expectation is to have a significantly smaller amount of CSS loading into JavaFX than we currently have. My questions for the list are: - Given the CSS styling of controls will be simpler than Modena, and there'll be a reduced amount of CSS that JavaFX will need to load as well as process throughout the app while it's running, I'm expecting to see less CSS churn while profiling the app, and perhaps even some visibly noticeable performance improvements, too. Is this a reasonable expectation, or is that unlikely in reality? - To anyone who has experience implementing custom themes, do you have any wisdom to impart, or links to any such advice, to help me prepare for this, design my CSS in the most JavaFX-optimal way possible, or avoid any common mistakes? Thanks! Ed From tbee at tbee.org Wed Mar 31 12:13:30 2021 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 31 Mar 2021 14:13:30 +0200 Subject: Fully custom theme vs overriding Modena In-Reply-To: <23A56B2A-93CB-4424-8EA5-C24BE9243529@kennard.net> References: <23A56B2A-93CB-4424-8EA5-C24BE9243529@kennard.net> Message-ID: <915815c0-3ffd-e760-5daa-2107b2a4fcb4@tbee.org> Pedro has done something like this with JMetro, maybe you can contact him. https://pixelduke.com/java-javafx-theme-jmetro/ https://github.com/JFXtras/jfxtras-styles On 2021-03-31 13:29, Ed Kennard wrote: > Hi all, > > I?m about to embark on some work which will remove our dependency on the Modena theme. We currently import Modena then override it wherever necessary, but now I want to replace that with our own custom CSS built from the ground up. The new custom CSS will be simpler and flatter than Modena, using a lot less insets, borders etc on the controls, and will only target the specific controls we need styling for in the app, so the expectation is to have a significantly smaller amount of CSS loading into JavaFX than we currently have. > > My questions for the list are: > > - Given the CSS styling of controls will be simpler than Modena, and there'll be a reduced amount of CSS that JavaFX will need to load as well as process throughout the app while it's running, I'm expecting to see less CSS churn while profiling the app, and perhaps even some visibly noticeable performance improvements, too. Is this a reasonable expectation, or is that unlikely in reality? > > - To anyone who has experience implementing custom themes, do you have any wisdom to impart, or links to any such advice, to help me prepare for this, design my CSS in the most JavaFX-optimal way possible, or avoid any common mistakes? > > Thanks! > > Ed > > From kcr at openjdk.java.net Wed Mar 31 12:23:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 12:23:14 GMT Subject: RFR: 8264501: UIWebView for iOS is deprecated In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:58:27 GMT, Jose Pereda wrote: > This PR replaces the deprecated iOS native view for web (UIWebView) with WKWebView. > > While most of the native API can be easily replaced from one to the other, there are some changes that affect the scripts execution, and therefore some minor changes in WebEngine/JS2JavaBridge are required. > > There is also a side effect if named members of JS objects are used via JSObject::setMember. The Java callbacks to JavaScript are now async, and the return value will be ignored. A workaround is to use JSObject::call instead to pass that value. This should be dealt with in a follow-up issue. > > Also, a peer is provided to allow having a JavaFX node that can be resized and relocated. > > This PR has been tested on iOS, loading URLs and local html files with JS scripts. I'll defer to @johanvos for the review. I noted one minor formatting issue that you might want to fix. modules/javafx.web/src/ios/java/com/sun/javafx/sg/prism/web/NGWebView.java line 80: > 78: return true; > 79: } > 80: } Minor: missing newline at end of file. ------------- PR: https://git.openjdk.java.net/jfx/pull/449 From jpereda at openjdk.java.net Wed Mar 31 12:29:35 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 31 Mar 2021 12:29:35 GMT Subject: RFR: 8264501: UIWebView for iOS is deprecated [v2] In-Reply-To: References: Message-ID: > This PR replaces the deprecated iOS native view for web (UIWebView) with WKWebView. > > While most of the native API can be easily replaced from one to the other, there are some changes that affect the scripts execution, and therefore some minor changes in WebEngine/JS2JavaBridge are required. > > There is also a side effect if named members of JS objects are used via JSObject::setMember. The Java callbacks to JavaScript are now async, and the return value will be ignored. A workaround is to use JSObject::call instead to pass that value. This should be dealt with in a follow-up issue. > > Also, a peer is provided to allow having a JavaFX node that can be resized and relocated. > > This PR has been tested on iOS, loading URLs and local html files with JS scripts. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add new line at the end of file ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/449/files - new: https://git.openjdk.java.net/jfx/pull/449/files/c7586db4..73d11608 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=449&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=449&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/449.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/449/head:pull/449 PR: https://git.openjdk.java.net/jfx/pull/449 From jvos at openjdk.java.net Wed Mar 31 12:29:36 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 31 Mar 2021 12:29:36 GMT Subject: RFR: 8264501: UIWebView for iOS is deprecated [v2] In-Reply-To: References: Message-ID: <5DxwRTtOC0qtzIgDnctX1KNU-1lqW4A8B9QVueo7f5Y=.9265df8d-f672-4323-ac89-5f87fb6351ed@github.com> On Wed, 31 Mar 2021 12:26:17 GMT, Jose Pereda wrote: >> This PR replaces the deprecated iOS native view for web (UIWebView) with WKWebView. >> >> While most of the native API can be easily replaced from one to the other, there are some changes that affect the scripts execution, and therefore some minor changes in WebEngine/JS2JavaBridge are required. >> >> There is also a side effect if named members of JS objects are used via JSObject::setMember. The Java callbacks to JavaScript are now async, and the return value will be ignored. A workaround is to use JSObject::call instead to pass that value. This should be dealt with in a follow-up issue. >> >> Also, a peer is provided to allow having a JavaFX node that can be resized and relocated. >> >> This PR has been tested on iOS, loading URLs and local html files with JS scripts. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add new line at the end of file Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/449 From jpereda at openjdk.java.net Wed Mar 31 12:29:37 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 31 Mar 2021 12:29:37 GMT Subject: RFR: 8264501: UIWebView for iOS is deprecated [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:19:10 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Add new line at the end of file > > modules/javafx.web/src/ios/java/com/sun/javafx/sg/prism/web/NGWebView.java line 80: > >> 78: return true; >> 79: } >> 80: } > > Minor: missing newline at end of file. Fixed ------------- PR: https://git.openjdk.java.net/jfx/pull/449 From fastegal at openjdk.java.net Wed Mar 31 12:35:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 31 Mar 2021 12:35:11 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 15:54:37 GMT, Marius Hanl wrote: >> This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. >> This bug only occurs, when a fixed cell size is set to the table. >> >> I also added 3 more tests beside the mandatory test, which tests my fix. >> 1 alternative test, which tests the same with no fixed cell size set. >> The other 2 tests are testing the same, but the table columns are set invisible instead. >> >> -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. >> Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). >> See also: TableRowSkinBase#updateCells(boolean) > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8258663: Using VirtualFlowTestUtils in tests now instead of own solution -> cleaner code Fix looks good, verified failing/passing test before/after fix. Left minor comments inline. As to the test - good to increase test coverage by including tests for invisible columns, IMO :) Two thingies you might consider (your decision, I'm fine either way) - test TreeTable also? Which doesn't seem to have the issue, so would be okay not to .. just for sanity. - parameterize the test in fixedSize false/true modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 551: > 549: if (!(cell instanceof IndexedCell)) continue; > 550: TableColumnBase tableColumn = getTableColumn((R) cell); > 551: if (!getVisibleLeafColumns().contains(tableColumn) || !tableColumn.isVisible()) { coming back, now that I understand the overall logic :) checking column.isVisible is not necessary: not being contained in the visibleLeafColumns implies that it is either not visible or not in the column hierarchy of table's columns. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 42: > 40: > 41: import static junit.framework.Assert.assertEquals; > 42: shouldn't that be `org.junit.Assert.*` ? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 116: > 114: private void removedColumnsShouldRemoveCorrespondingCellsInRowImpl() { > 115: // Remove the last 2 columns. > 116: tableView.getColumns().remove(tableView.getColumns().size() - 2, tableView.getColumns().size() - 1); code comment is not correct - the last parameter of `remove(int, int)` is exclusive. While it doesn't change the outcome (failing/passing before/after fix), it might confuse future readers :) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 122: > 120: // We removed 2 columns, so the cell count should be decremented by 2 as well. > 121: assertEquals(tableView.getColumns().size(), > 122: VirtualFlowTestUtils.getCell(tableView, 0).getChildrenUnmodifiable().size()); same incorrect code comment, see above ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/444 From jpereda at openjdk.java.net Wed Mar 31 12:45:14 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 31 Mar 2021 12:45:14 GMT Subject: Integrated: 8264501: UIWebView for iOS is deprecated In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:58:27 GMT, Jose Pereda wrote: > This PR replaces the deprecated iOS native view for web (UIWebView) with WKWebView. > > While most of the native API can be easily replaced from one to the other, there are some changes that affect the scripts execution, and therefore some minor changes in WebEngine/JS2JavaBridge are required. > > There is also a side effect if named members of JS objects are used via JSObject::setMember. The Java callbacks to JavaScript are now async, and the return value will be ignored. A workaround is to use JSObject::call instead to pass that value. This should be dealt with in a follow-up issue. > > Also, a peer is provided to allow having a JavaFX node that can be resized and relocated. > > This PR has been tested on iOS, loading URLs and local html files with JS scripts. This pull request has now been integrated. Changeset: d80b8ada Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/d80b8ada Stats: 264 lines in 9 files changed: 175 ins; 17 del; 72 mod 8264501: UIWebView for iOS is deprecated Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/449 From jvos at openjdk.java.net Wed Mar 31 13:00:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 31 Mar 2021 13:00:12 GMT Subject: RFR: 8264162: PickResult.toString() is missing the closing square bracket [v2] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 22:08:36 GMT, Kevin Rushforth wrote: >> Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback: fix indentation in PickResult::toString, add comment to the test Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From kcr at openjdk.java.net Wed Mar 31 13:00:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 13:00:13 GMT Subject: Integrated: 8264162: PickResult.toString() is missing the closing square bracket In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 12:29:38 GMT, Kevin Rushforth wrote: > Simple fix to add a missing closing bracket to `PickResult::toString`. This includes a unit test that fails without the fix and passes with the fix. This pull request has now been integrated. Changeset: f3e27a08 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f3e27a08 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod 8264162: PickResult.toString() is missing the closing square bracket Reviewed-by: jvos, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/443 From kcr at openjdk.java.net Wed Mar 31 13:04:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 13:04:14 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:29:03 GMT, Marius Hanl wrote: >> Small fix to clear a reference to a removed node left by Scene$MouseHandler. > > modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line 978: > >> 976: >> 977: @Test public void testNoReferencesRemainToRemovedNodeAfterBeingClicked() { >> 978: StubToolkit toolkit = (StubToolkit) Toolkit.getToolkit(); > > This cast isn't necessary, is it? Yes, it is necessary, since it won't compile otherwise. ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From kcr at openjdk.java.net Wed Mar 31 13:16:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 13:16:09 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:36:06 GMT, John Hendrikx wrote: > Small fix to clear a reference to a removed node left by Scene$MouseHandler. The fix looks good to me. I haven't run the test yet, but it seems OK except for the handling of GC to check for the leak (I left an inline comment). modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3633: > 3631: ? currentEventTargets.get(0) : null; > 3632: pdrEventTarget.clear(); > 3633: pdrEventTargets.clear(); // clear to remove potentially removed nodes, see JDK-8264330 We generally don't refer to the bug ID unless there is something particularly tricky about the fix (which isn't the case here). modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line 1019: > 1017: pane = null; > 1018: > 1019: System.gc(); It is not sufficient to call `System.gc()` only once, since it will make for a fragile test. I recommend using the `JMemoryBuddy::assertCollectable` for this, which is what we are using for new tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From github.com+66004280+maran23 at openjdk.java.net Wed Mar 31 13:16:13 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 31 Mar 2021 13:16:13 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: <7hTz1wgrF7pELv23RtwNJbw-tLchQFXGR053U5yISoc=.4b089d18-1d2d-46a5-8e83-d0ae1d99a062@github.com> On Wed, 31 Mar 2021 12:00:39 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258663: Using VirtualFlowTestUtils in tests now instead of own solution -> cleaner code > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 551: > >> 549: if (!(cell instanceof IndexedCell)) continue; >> 550: TableColumnBase tableColumn = getTableColumn((R) cell); >> 551: if (!getVisibleLeafColumns().contains(tableColumn) || !tableColumn.isVisible()) { > > coming back, now that I understand the overall logic :) > > checking column.isVisible is not necessary: not being contained in the visibleLeafColumns implies that it is either not visible or not in the column hierarchy of table's columns. oh, right. It's called getVisibleLeafColumns() for a reason. ?? I will remove the visibility check. > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 42: > >> 40: >> 41: import static junit.framework.Assert.assertEquals; >> 42: > > shouldn't that be `org.junit.Assert.*` ? Don't know, is there any kind of convention for that? Or is a static import fine? > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 116: > >> 114: private void removedColumnsShouldRemoveCorrespondingCellsInRowImpl() { >> 115: // Remove the last 2 columns. >> 116: tableView.getColumns().remove(tableView.getColumns().size() - 2, tableView.getColumns().size() - 1); > > code comment is not correct - the last parameter of `remove(int, int)` is exclusive. While it doesn't change the outcome (failing/passing before/after fix), it might confuse future readers :) Thanks, didn't recognized that. I will change it so that **really** the last 2 columns are removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Wed Mar 31 13:23:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 13:23:15 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:18:54 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258663: Using VirtualFlowTestUtils in tests now instead of own solution -> cleaner code > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 42: > >> 40: >> 41: import static junit.framework.Assert.assertEquals; >> 42: > > shouldn't that be `org.junit.Assert.*` ? I don't think @kleopatra was referring to whether or not to use a wild-card import, but rather that the `Assert` class should be imported from the `org.junit` package instead of `junit.framework`. We are inconsistent in our usage in some of the older tests, but yes, we should use `org.junit`. ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Wed Mar 31 13:39:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 13:39:15 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 23:23:56 GMT, Florian Kirmaier wrote: >> Marked as reviewed by arapte (Reviewer). > > The CSR is now in the proposed state! I reviewed the CSR, and it is now ready for you to Finalize. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From fkirmaier at openjdk.java.net Wed Mar 31 13:56:15 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 31 Mar 2021 13:56:15 GMT Subject: RFR: 8263322: Calling Application.launch on FX thread should throw IllegalStateException, but causes deadlock [v9] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:36:48 GMT, Kevin Rushforth wrote: >> The CSR is now in the proposed state! > > I reviewed the CSR, and it is now ready for you to Finalize. I've clicked now the finalize button. ------------- PR: https://git.openjdk.java.net/jfx/pull/421 From kcr at openjdk.java.net Wed Mar 31 14:02:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 14:02:19 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Tue, 30 Mar 2021 19:07:31 GMT, John Neffenger wrote: >> I think there might be a Skara bug. The pre-submit builds on Linux, macOS, and Windows completed immediately. I think that's because the first of the two commits in this pull request includes the Java Bug ID from [another pending pull request][1], because this pull request is a continuation of that one. I can squash the two commits and force-push the changes, if that would help. >> >> [1]: https://github.com/openjdk/jfx/pull/422 > >> I think there might be a Skara bug. > > No, no bug. Sorry about that. I just don't know how GitHub works. :frowning_face: The pre-submit tests ran two days ago when I pushed the branch to GitHub, so by the time I submitted the pull request, they had finished long ago. I recommend trying this with the following gradle flags, to match the settings for production builds: -PCONF=Release -PPROMOTED_BUILD_NUMBER=NNN -PHUDSON_BUILD_NUMBER=MMM -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true where `NNN` is the promoted build number that is being built (usually taken from the repo tag) and `MMM` is the CI build number. You can just pick any two positive numbers for your test builds. Note that this will build the native media libraries and the native webkit library. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From github.com+66004280+maran23 at openjdk.java.net Wed Mar 31 14:04:42 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 31 Mar 2021 14:04:42 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v3] In-Reply-To: References: Message-ID: > This PR fixes an issue, where table cells are not removed from the table row when the corresponding table column got removed. This will lead to empty "ghost" cells laying around in the table. > This bug only occurs, when a fixed cell size is set to the table. > > I also added 3 more tests beside the mandatory test, which tests my fix. > 1 alternative test, which tests the same with no fixed cell size set. > The other 2 tests are testing the same, but the table columns are set invisible instead. > > -> Either the removal or setVisible(false) of a column should both do the same: Remove the corresponding cells, so that there are no empty cells. > Therefore, the additional tests make sure, that the other use cases (still) works and won't break in future (at least, without red tests ;)). > See also: TableRowSkinBase#updateCells(boolean) Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8258663: Changes based of the code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/444/files - new: https://git.openjdk.java.net/jfx/pull/444/files/a2a331a2..dbdfbdc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=444&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=444&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/444.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/444/head:pull/444 PR: https://git.openjdk.java.net/jfx/pull/444 From github.com+66004280+maran23 at openjdk.java.net Wed Mar 31 14:04:42 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 31 Mar 2021 14:04:42 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:32:02 GMT, Jeanette Winzenburg wrote: > > > Fix looks good, verified failing/passing test before/after fix. Left minor comments inline. > > As to the test - good to increase test coverage by including tests for invisible columns, IMO :) > > Two thingies you might consider (your decision, I'm fine either way) > > * test TreeTable also? Which doesn't seem to have the issue, so would be okay not to .. just for sanity. > > * parameterize the test in fixedSize false/true I didn't wrote tests for TreeTableView, as they have no issue (and I'm lazy :P). But it might be a good idea to do so in future. I chose not to make the tests parameterized so other people can add tests as well (without the parameterized 'dependency'). As far as I saw, you can't just define some tests to be parameterized (only the whole class is). I know that his is possible in JUnit5 with @MethodSource, but unfortunatly we run on JUnit4. ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From github.com+66004280+maran23 at openjdk.java.net Wed Mar 31 14:04:43 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 31 Mar 2021 14:04:43 GMT Subject: RFR: 8258663: Fixed size TableCells are not removed from sene graph when column is removed [v2] In-Reply-To: References: Message-ID: <6w736c2RBRr5nDs7fJCq8O_p3a2D_HfZ-BCI-nipIyw=.333d8868-ba74-4077-b387-6a12cffebf98@github.com> On Wed, 31 Mar 2021 13:20:09 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 42: >> >>> 40: >>> 41: import static junit.framework.Assert.assertEquals; >>> 42: >> >> shouldn't that be `org.junit.Assert.*` ? > > I don't think @kleopatra was referring to whether or not to use a wild-card import, but rather that the `Assert` class should be imported from the `org.junit` package instead of `junit.framework`. We are inconsistent in our usage in some of the older tests, but yes, we should use `org.junit`. Oh, alright, didn't saw that. I will change it. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/444 From kcr at openjdk.java.net Wed Mar 31 14:12:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 14:12:15 GMT Subject: RFR: 8264010: Add Gradle dependency verification In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> <0pTwcgPkfC85twUGPosYGtYrI6AhVfx1qJtgAngS7HE=.fe8e3c95-29ec-4fef-9da1-a791f78ce467@github.com> <-7QZhxw0nWsGq1AwS1iADnjwI7FULDyNTaL7cegDywE=.6fc33209-c23f-4116-9ebb-5f588edf029f@github.com> Message-ID: On Thu, 25 Mar 2021 18:53:41 GMT, John Neffenger wrote: >> Thanks, Kevin. I added a README file and updated the Lucene instructions, as you suggested. I'm open to any other suggestions on the wording or formatting, no matter how minor. >> >>> Some of the files listed are not used directly. I presume that you added them because they are used indirectly by other components? Are all of them actually needed? >> >> The Gradle command, now documented in the `gradle/README.txt` file, adds entries to the dependency verification file for all dependencies, including transitive ones. I think that's the list of everything downloaded during the builds on Linux, macOS, and Windows. I'll clear the Gradle cache and double-check it now. I'll let you know if I find anything unexpected. > >> Are all of them actually needed? > > Just to follow up on that question, all of them are in fact downloaded during the build, at least. I removed the Gradle directory `$HOME/.gradle` and ran the build as follows. Then I compared the list of downloaded artifacts with the ones listed in the dependency verification file. > > $ rm -r $HOME/.gradle > $ bash gradlew sdk jmods javadoc apps test -x :web:test > ... > $ find ~/.gradle/caches/modules-2 ( -name "*.jar" -o -name "*.pom" ) \ > -exec basename {} ; | sort > downloaded.log > $ grep '/\1/' \ > | sort > verified.log > $ diff downloaded.log verified.log > 31a32 >> org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512-.jar > 32a34 >> org.eclipse.swt.win32.win32.x86_64_3.105.3.v20170228-0512-.jar > > A total of 36 artifacts (14 JAR files and 22 POM files) are downloaded during the build. The SWT libraries for macOS and Windows were not downloaded because I ran the build on Linux. We have a few in-flight or imminent updates that will impact this PR. There is a tight deadline on one of them (an ICU data file dependency), so I'd prefer to wait on integrating this until after they are done. It's still worth continuing the review in the mean time. I noticed that the libav bundles are missing on Linux. To ensure that you aren't missing any dependencies, can you add the following gradle flags to your build? -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true This will build the native media libraries, including the libav stubs (the latter is Linux only). Eventually, you will need to include WebKit, but that's not needed for now. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From jvos at openjdk.java.net Wed Mar 31 18:00:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 31 Mar 2021 18:00:26 GMT Subject: RFR: 8264536: Building OpenJFX on Apple AARCH64 not possible Message-ID: don't bail when building on Apple M1 systems Fix for JDK-8264536 ------------- Commit messages: - don't bail when building on Apple M1 systems Changes: https://git.openjdk.java.net/jfx/pull/451/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=451&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264536 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/451.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/451/head:pull/451 PR: https://git.openjdk.java.net/jfx/pull/451 From kcr at openjdk.java.net Wed Mar 31 18:26:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 18:26:19 GMT Subject: RFR: 8264536: Building OpenJFX on Apple AARCH64 not possible In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 17:54:49 GMT, Johan Vos wrote: > don't bail when building on Apple M1 systems > Fix for JDK-8264536 Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/451 From jvos at openjdk.java.net Wed Mar 31 18:43:09 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 31 Mar 2021 18:43:09 GMT Subject: Integrated: 8264536: Building OpenJFX on Apple AARCH64 not possible In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 17:54:49 GMT, Johan Vos wrote: > don't bail when building on Apple M1 systems > Fix for JDK-8264536 This pull request has now been integrated. Changeset: eec2f394 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/eec2f394 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264536: Building OpenJFX on Apple AARCH64 not possible Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/451 From kcr at openjdk.java.net Wed Mar 31 19:28:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 19:28:14 GMT Subject: RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 05:15:20 GMT, Alexander Matveev wrote: > - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 > - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. I get a compilation error on Linux: ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c: In function 'gst_audio_buffer_map': ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: error: implicit declaration of function 'memset' [-Werror=implicit-function-declaration] 158 | memset (buffer->map_infos, 0, | ^~~~~~ ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: warning: incompatible implicit declaration of built-in function 'memset' ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:26:1: note: include '' or provide a declaration of 'memset' ... cc1: some warnings being treated as errors Makefile:270: recipe for target 'modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o' failed make: *** [modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o] Error 1 This is with the gcc 10.2 compiler used for production builds. ------------- PR: https://git.openjdk.java.net/jfx/pull/447 From jhendrikx at openjdk.java.net Wed Mar 31 21:19:15 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:19:15 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:07:06 GMT, Kevin Rushforth wrote: >> Small fix to clear a reference to a removed node left by Scene$MouseHandler. > > modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line 1019: > >> 1017: pane = null; >> 1018: >> 1019: System.gc(); > > It is not sufficient to call `System.gc()` only once, since it will make for a fragile test. I recommend using the `JMemoryBuddy::assertCollectable` for this, which is what we are using for new tests. This tool is in javafx.base's test folder, and it is not allowing me to reference it. I'm not quite sure how to change the project to allow this. ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From kcr at openjdk.java.net Wed Mar 31 21:27:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 21:27:15 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:13:01 GMT, Kevin Rushforth wrote: >> Small fix to clear a reference to a removed node left by Scene$MouseHandler. > > The fix looks good to me. I haven't run the test yet, but it seems OK except for the handling of GC to check for the leak (I left an inline comment). Oh, I thought that `javafx.graphics` already referenced it. The following should be sufficient: --- a/build.gradle +++ b/build.gradle @@ -2089,6 +2089,7 @@ project(":graphics") { stubCompile group: "junit", name: "junit", version: "4.8.2" antlr group: "org.antlr", name: "antlr4", version: "4.7.2", classifier: "complete" + testCompile project(":base").sourceSets.test.output compile project(':base') } ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From jhendrikx at openjdk.java.net Wed Mar 31 21:42:38 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:42:38 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v2] In-Reply-To: References: Message-ID: > Small fix to clear a reference to a removed node left by Scene$MouseHandler. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/448/files - new: https://git.openjdk.java.net/jfx/pull/448/files/26cdfe1f..371ede22 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=448&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=448&range=00-01 Stats: 10 lines in 2 files changed: 1 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/448.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/448/head:pull/448 PR: https://git.openjdk.java.net/jfx/pull/448 From jhendrikx at openjdk.java.net Wed Mar 31 21:42:39 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:42:39 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:11:23 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix review comments > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3633: > >> 3631: ? currentEventTargets.get(0) : null; >> 3632: pdrEventTarget.clear(); >> 3633: pdrEventTargets.clear(); // clear to remove potentially removed nodes, see JDK-8264330 > > We generally don't refer to the bug ID unless there is something particularly tricky about the fix (which isn't the case here). Removed this ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From jhendrikx at openjdk.java.net Wed Mar 31 21:42:40 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:42:40 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:16:29 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/SceneTest.java line 1019: >> >>> 1017: pane = null; >>> 1018: >>> 1019: System.gc(); >> >> It is not sufficient to call `System.gc()` only once, since it will make for a fragile test. I recommend using the `JMemoryBuddy::assertCollectable` for this, which is what we are using for new tests. > > This tool is in javafx.base's test folder, and it is not allowing me to reference it. I'm not quite sure how to change the project to allow this. Added reference in build.gradle and used the tool as suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From jhendrikx at openjdk.java.net Wed Mar 31 21:49:21 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:49:21 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v3] In-Reply-To: References: Message-ID: > Small fix to clear a reference to a removed node left by Scene$MouseHandler. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add test compile dependency on :base for :graphics ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/448/files - new: https://git.openjdk.java.net/jfx/pull/448/files/371ede22..0be3b899 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=448&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=448&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/448.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/448/head:pull/448 PR: https://git.openjdk.java.net/jfx/pull/448 From kcr at openjdk.java.net Wed Mar 31 21:49:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 31 Mar 2021 21:49:21 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:24:18 GMT, Kevin Rushforth wrote: >> The fix looks good to me. I haven't run the test yet, but it seems OK except for the handling of GC to check for the leak (I left an inline comment). > > Oh, I thought that `javafx.graphics` already referenced it. The following should be sufficient: > > --- a/build.gradle > +++ b/build.gradle > @@ -2089,6 +2089,7 @@ project(":graphics") { > stubCompile group: "junit", name: "junit", version: "4.8.2" > > antlr group: "org.antlr", name: "antlr4", version: "4.7.2", classifier: "complete" > + testCompile project(":base").sourceSets.test.output > compile project(':base') > } Did you find that it worked without the addition of the dependency to `build.gradle`? You didn't commit that change. I guess we'll see what the GitHub actions build shows. ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From jhendrikx at openjdk.java.net Wed Mar 31 21:49:22 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 31 Mar 2021 21:49:22 GMT Subject: RFR: 8264330: Scene MouseHandler is referencing removed nodes [v3] In-Reply-To: References: Message-ID: <_JnzkJayGqW8dLsH3Bl7BtvMda70Ck7hCB5irSrYJTQ=.e345055d-4e91-4083-a246-7a9e9321f5c8@github.com> On Wed, 31 Mar 2021 21:43:02 GMT, Kevin Rushforth wrote: > Did you find that it worked without the addition of the dependency to `build.gradle`? You didn't commit that change. I guess we'll see what the GitHub actions build shows. I forgot to add the change I did in build.gradle, it didn't work without it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/448 From hjohn at xs4all.nl Wed Mar 31 21:54:37 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 31 Mar 2021 23:54:37 +0200 Subject: Fully custom theme vs overriding Modena In-Reply-To: <23A56B2A-93CB-4424-8EA5-C24BE9243529@kennard.net> References: <23A56B2A-93CB-4424-8EA5-C24BE9243529@kennard.net> Message-ID: I've found that building controls in such a way to limit the addition/removal of child Nodes as much as possible (for example by making them invisible/unmanaged instead of adding/removing) has a huge impact on performance. If you are seeing a lot of CSS churn, this could be one of the causes. --John On 31/03/2021 13:29, Ed Kennard wrote: > Hi all, > > I?m about to embark on some work which will remove our dependency on the Modena theme. We currently import Modena then override it wherever necessary, but now I want to replace that with our own custom CSS built from the ground up. The new custom CSS will be simpler and flatter than Modena, using a lot less insets, borders etc on the controls, and will only target the specific controls we need styling for in the app, so the expectation is to have a significantly smaller amount of CSS loading into JavaFX than we currently have. > > My questions for the list are: > > - Given the CSS styling of controls will be simpler than Modena, and there'll be a reduced amount of CSS that JavaFX will need to load as well as process throughout the app while it's running, I'm expecting to see less CSS churn while profiling the app, and perhaps even some visibly noticeable performance improvements, too. Is this a reasonable expectation, or is that unlikely in reality? > > - To anyone who has experience implementing custom themes, do you have any wisdom to impart, or links to any such advice, to help me prepare for this, design my CSS in the most JavaFX-optimal way possible, or avoid any common mistakes? > > Thanks! > > Ed > > From jgneff at openjdk.java.net Wed Mar 31 23:11:16 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Wed, 31 Mar 2021 23:11:16 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH In-Reply-To: References: <-dwqSwPAoYtQOVn0IUzAGybT7nNFRzKTACwc-g0gth8=.4a123912-538e-4fec-9077-92a30361c797@github.com> Message-ID: On Wed, 31 Mar 2021 13:59:12 GMT, Kevin Rushforth wrote: > I recommend trying this with the following gradle flags, to match the settings for production builds: Thanks, Kevin. Good news so far. I'm posting the Linux results while I run the macOS and Windows builds. #### Linux I ran the following commands twice, moving the `build` directory to `build1` and then `build2` to save their output: $ bash gradlew clean $ bash gradlew -PCONF=Release -PPROMOTED_BUILD_NUMBER=5 \ -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx \ -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true \ -PBUILD_LIBAV_STUBS=true sdk jmods javadoc Then I changed the Hudson job number with `-PHUDSON_BUILD_NUMBER=102`, ran the build a third time, and moved `build` to `build3`. I also ran `strip-nondeterminism` as shown in the first comment of this pull request. The first result is as hoped, and the second result is as expected: $ diff -qr build1 build2 $ diff -qr build2 build3 Files build2/jmods/javafx.base.jmod and build3/jmods/javafx.base.jmod differ Files build2/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class and build3/modular-sdk/modules/javafx.base/com/sun/javafx/runtime/VersionInfo.class differ Files build2/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java and build3/modular-sdk/modules_src/javafx.base/com/sun/javafx/runtime/VersionInfo.java differ Files build2/publications/javafx.base-linux.jar and build3/publications/javafx.base-linux.jar differ Files build2/sdk/lib/javafx.base.jar and build3/sdk/lib/javafx.base.jar differ Files build2/sdk/lib/src.zip and build3/sdk/lib/src.zip differ You have to appreciate the irony of adding all this information to the build ? the time, the path, even the job number ? so that we can uniquely identify a build by its output. Meanwhile, if we didn't add this information, our builds could be uniquely identified by a single Git tag. ------------- PR: https://git.openjdk.java.net/jfx/pull/446