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