From aghaisas at openjdk.java.net Wed Dec 1 09:49:29 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Dec 2021 09:49:29 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height In-Reply-To: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: On Tue, 2 Nov 2021 10:49:45 GMT, Michael Strau? wrote: > This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. > This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java line 896: > 894: double vPixelValue; > 895: if (nodeHeight > 0.0) { > 896: vPixelValue = vRange / (nodeHeight - contentHeight); This may result in divide by 0. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java line 928: > 926: double hPixelValue; > 927: if (nodeWidth > 0.0) { > 928: hPixelValue = hRange / (nodeWidth - contentWidth); This may result in divide by 0. ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From aghaisas at openjdk.java.net Wed Dec 1 11:45:29 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Dec 2021 11:45:29 GMT Subject: RFR: 8272118: ListViewSkin et al: must not cancel edit on scrolling In-Reply-To: References: Message-ID: On Thu, 25 Nov 2021 15:46:01 GMT, Jeanette Winzenburg wrote: > Issue was that mouse pressed on the scrollbars of all virtualized controls cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel, programmatic). Fixed by removing the cancel. > > Added tests that failed/passed before/after the fix. Also added tests that passed both before/after to guarantee that required functionality of the mouse pressed (= requesting focus on the control if needed) is still working. Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/682 From kcr at openjdk.java.net Wed Dec 1 13:03:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Dec 2021 13:03:26 GMT Subject: Integrated: 8277475: Update JDK_DOCS property to point to JDK 17 docs In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 15:58:17 GMT, Kevin Rushforth wrote: > We are still pointing to the JDK 12 API docs when building the JavaFX docs. This PR updates the build to point to the JDK 17 API docs. This pull request has now been integrated. Changeset: 3d572135 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3d572135d44b41945b87c297b33b3527814b7e51 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8277475: Update JDK_DOCS property to point to JDK 17 docs Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/686 From mstrauss at openjdk.java.net Wed Dec 1 14:00:06 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Dec 2021 14:00:06 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v2] In-Reply-To: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: > This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. > This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Handle division by zero ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/660/files - new: https://git.openjdk.java.net/jfx/pull/660/files/1605eec4..147858d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=660&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=660&range=00-01 Stats: 19 lines in 1 file changed: 4 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/660/head:pull/660 PR: https://git.openjdk.java.net/jfx/pull/660 From mstrauss at openjdk.java.net Wed Dec 1 14:03:32 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 1 Dec 2021 14:03:32 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v2] In-Reply-To: References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: <4W2fiU0xk5IWQLAh_CS-chahjwHVcr2QBSUbC7zb0Fg=.37e6e24d-5706-4124-8d59-26c2d9b1eb98@github.com> On Wed, 1 Dec 2021 09:45:40 GMT, Ajit Ghaisas wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle division by zero > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java line 896: > >> 894: double vPixelValue; >> 895: if (nodeHeight > 0.0) { >> 896: vPixelValue = vRange / (nodeHeight - contentHeight); > > This may result in divide by 0. Good catch! I've also fixed a few similar issues in other places. ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From aghaisas at openjdk.java.net Wed Dec 1 15:22:30 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Dec 2021 15:22:30 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") [v2] In-Reply-To: References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: On Thu, 25 Nov 2021 00:29:36 GMT, Kevin Rushforth wrote: >> As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. >> >> I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback: use method reference instead of lambda Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/681 From kcr at openjdk.java.net Wed Dec 1 15:48:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Dec 2021 15:48:29 GMT Subject: Integrated: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") In-Reply-To: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: On Wed, 24 Nov 2021 23:05:05 GMT, Kevin Rushforth wrote: > As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. > > I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. This pull request has now been integrated. Changeset: 5bd72a7c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5bd72a7c991d5182f4fd2cff67174cf7fa3fde85 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Reviewed-by: jpereda, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/681 From duke at openjdk.java.net Wed Dec 1 17:49:46 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 1 Dec 2021 17:49:46 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors Message-ID: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. ------------- Commit messages: - Mac Glass treats errors as warnings except for deprecated declarations Changes: https://git.openjdk.java.net/jfx/pull/687/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=687&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278021 Stats: 20 lines in 8 files changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/687.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/687/head:pull/687 PR: https://git.openjdk.java.net/jfx/pull/687 From kcr at openjdk.java.net Thu Dec 2 00:23:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Dec 2021 00:23:27 GMT Subject: RFR: 8272118: ListViewSkin et al: must not cancel edit on scrolling In-Reply-To: References: Message-ID: On Thu, 25 Nov 2021 15:46:01 GMT, Jeanette Winzenburg wrote: > Issue was that mouse pressed on the scrollbars of all virtualized controls cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel, programmatic). Fixed by removing the cancel. > > Added tests that failed/passed before/after the fix. Also added tests that passed both before/after to guarantee that required functionality of the mouse pressed (= requesting focus on the control if needed) is still working. Looks good. Thanks for adding all the tests! modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/EditAndScrollTest.java line 408: > 406: > 407: > 408: //----------------- Utility methods (TODO: move into infrastructure) Can you file a follow-up issue for this? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/682 From tom.schindl at bestsolution.at Thu Dec 2 10:35:01 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 2 Dec 2021 11:35:01 +0100 Subject: Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale Message-ID: <3165f71a-9b54-4ae6-bbd7-0434ce3941b3@bestsolution.at> Hi, I'm try to get a HiDPI-Image produced by an external application into JavaFX using WritableImage. In the end the situation is comparable to what you get today when loading an image from an URL (eg sample at 2.png) where JavaFX sets the appropriate image pixelScale on "com.sun.prism.Image". If I'm not completely mistaken I would need an new API on PixelBuffer to containing the pixelScale who is used QuantumImage to create an appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 because I fed in a HiDPI-Image already. Before filing an ehancement I wanted to bring this up here because maybe I'm missing something obvious or maybe my proposal makes totally no sense. Tom From fastegal at openjdk.java.net Thu Dec 2 11:06:22 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Dec 2021 11:06:22 GMT Subject: RFR: 8272118: ListViewSkin et al: must not cancel edit on scrolling In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 00:18:37 GMT, Kevin Rushforth wrote: >> Issue was that mouse pressed on the scrollbars of all virtualized controls cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel, programmatic). Fixed by removing the cancel. >> >> Added tests that failed/passed before/after the fix. Also added tests that passed both before/after to guarantee that required functionality of the mouse pressed (= requesting focus on the control if needed) is still working. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/EditAndScrollTest.java line 408: > >> 406: >> 407: >> 408: //----------------- Utility methods (TODO: move into infrastructure) > > Can you file a follow-up issue for this? yeah, sure - was undecided whether to do it here or later (locally, there are more that will be added for fixing related issues) - [JDK-8278134](https://bugs.openjdk.java.net/browse/JDK-8278134) ------------- PR: https://git.openjdk.java.net/jfx/pull/682 From fastegal at openjdk.java.net Thu Dec 2 11:06:23 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Dec 2021 11:06:23 GMT Subject: Integrated: 8272118: ListViewSkin et al: must not cancel edit on scrolling In-Reply-To: References: Message-ID: <6M6OqRPFjKVDnibWYdWWvP_6PUJaY7bLFMLv5s1x1K4=.62c2d773-ba22-444b-9b75-68f501912701@github.com> On Thu, 25 Nov 2021 15:46:01 GMT, Jeanette Winzenburg wrote: > Issue was that mouse pressed on the scrollbars of all virtualized controls cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel, programmatic). Fixed by removing the cancel. > > Added tests that failed/passed before/after the fix. Also added tests that passed both before/after to guarantee that required functionality of the mouse pressed (= requesting focus on the control if needed) is still working. This pull request has now been integrated. Changeset: aa045c5e Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/aa045c5e60f9566748b55d745d162d0c94ba5e59 Stats: 594 lines in 6 files changed: 566 ins; 28 del; 0 mod 8272118: ListViewSkin et al: must not cancel edit on scrolling Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/682 From duke at openjdk.java.net Thu Dec 2 21:12:41 2021 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 2 Dec 2021 21:12:41 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven Message-ID: Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. ------------- Commit messages: - 8276170: Remove trailing whitespaces - JDK-8276170: Create Sources when publishing to Maven Changes: https://git.openjdk.java.net/jfx/pull/657/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=657&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276170 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/657.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/657/head:pull/657 PR: https://git.openjdk.java.net/jfx/pull/657 From fkirmaier at openjdk.java.net Thu Dec 2 21:12:42 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 2 Dec 2021 21:12:42 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. I wonder how the sources for the official maven release are generated? https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/17/ The official release contains all the sources, but when we build it from source, these files are missing. ------------- PR: https://git.openjdk.java.net/jfx/pull/657 From duke at openjdk.java.net Thu Dec 2 21:12:50 2021 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 2 Dec 2021 21:12:50 GMT Subject: RFR: 8276167: fixing VirtualFlow.scrollToTop(int) In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. We already had a OCA for our company. I wrote Oracle to add me to our company OCA (Carlzeissmeditecag). ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Thu Dec 2 21:12:49 2021 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 2 Dec 2021 21:12:49 GMT Subject: RFR: 8276167: fixing VirtualFlow.scrollToTop(int) Message-ID: Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. ------------- Commit messages: - JDK-8276167: fixing VirtualFlow.scrollToTop(int) Changes: https://git.openjdk.java.net/jfx/pull/656/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276167 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/656/head:pull/656 PR: https://git.openjdk.java.net/jfx/pull/656 From robilad at openjdk.java.net Thu Dec 2 21:12:50 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Thu, 2 Dec 2021 21:12:50 GMT Subject: RFR: 8276167: fixing VirtualFlow.scrollToTop(int) In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. Hi, please send me an e-Mail at Dalibor.topic at oracle.com and I can help with the verification process. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From kcr at openjdk.java.net Thu Dec 2 21:19:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Dec 2021 21:19:18 GMT Subject: RFR: 8276170: Create Sources when publishing to Maven In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. As discussed in the bug report, it isn't at all clear that we should do this. @johanvos can make the call on this. ------------- PR: https://git.openjdk.java.net/jfx/pull/657 From kcr at openjdk.java.net Thu Dec 2 21:55:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Dec 2021 21:55:19 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v2] In-Reply-To: References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: <1SL5WaSuYj5_o6kiOKA7bQXl_m4I_1eQOOvXrYFRuKI=.e82bc7c9-19b0-4148-82a0-99584f381b6c@github.com> On Wed, 1 Dec 2021 14:00:06 GMT, Michael Strau? wrote: >> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. >> This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Handle division by zero modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java line 895: > 893: double vRange = getSkinnable().getVmax()-getSkinnable().getVmin(); > 894: double vPixelValue = vRange / (nodeHeight - contentHeight); > 895: vPixelValue = Double.isFinite(vPixelValue) ? vPixelValue : 0.0; I liked the previous logic better and would have just changed the comparison to check `(nodeHeight - contentHeight) > 0.0` (possibly saving the adjusted width or height in a local various to avoid doing it twice). As it is, this is replacing an explicit check on the source values with an out of range check on the result, which seems less intuitive. Also, the previous code did a `> 0` test and the new code effectively does a `!= 0` test. ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From mstrauss at openjdk.java.net Thu Dec 2 22:49:45 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Dec 2021 22:49:45 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3] In-Reply-To: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> > This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. > This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Changes per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/660/files - new: https://git.openjdk.java.net/jfx/pull/660/files/147858d7..6b8985f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=660&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=660&range=01-02 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/660/head:pull/660 PR: https://git.openjdk.java.net/jfx/pull/660 From mstrauss at openjdk.java.net Thu Dec 2 22:49:48 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 2 Dec 2021 22:49:48 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v2] In-Reply-To: <1SL5WaSuYj5_o6kiOKA7bQXl_m4I_1eQOOvXrYFRuKI=.e82bc7c9-19b0-4148-82a0-99584f381b6c@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> <1SL5WaSuYj5_o6kiOKA7bQXl_m4I_1eQOOvXrYFRuKI=.e82bc7c9-19b0-4148-82a0-99584f381b6c@github.com> Message-ID: On Thu, 2 Dec 2021 21:51:59 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle division by zero > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java line 895: > >> 893: double vRange = getSkinnable().getVmax()-getSkinnable().getVmin(); >> 894: double vPixelValue = vRange / (nodeHeight - contentHeight); >> 895: vPixelValue = Double.isFinite(vPixelValue) ? vPixelValue : 0.0; > > I liked the previous logic better and would have just changed the comparison to check `(nodeHeight - contentHeight) > 0.0` (possibly saving the adjusted width or height in a local various to avoid doing it twice). As it is, this is replacing an explicit check on the source values with an out of range check on the result, which seems less intuitive. Also, the previous code did a `> 0` test and the new code effectively does a `!= 0` test. I changed it to check the denominator values instead. ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From tom.schindl at bestsolution.at Thu Dec 2 23:40:33 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 3 Dec 2021 00:40:33 +0100 Subject: Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale In-Reply-To: <3165f71a-9b54-4ae6-bbd7-0434ce3941b3@bestsolution.at> References: <3165f71a-9b54-4ae6-bbd7-0434ce3941b3@bestsolution.at> Message-ID: <43c17ef0-0867-fd64-16b0-f1c104f28954@bestsolution.at> ok answering my own question it is quite simple using setFitWidth/setFitHeight already today. ImageView renderingView .... renderingView.setFitWidth(width / scaleFactor); renderingView.setFitHeight(height / scaleFactor); I already tested that before sending out this mail but unfortunately it did not work because I had a reflection effect on the parent node and it took the whole day to track down that I run a bug with the Reflection-Effect I documented at [1]. Tom [1] https://bugs.openjdk.java.net/browse/JDK-8278170 Am 02.12.21 um 11:35 schrieb Tom Schindl: > Hi, > > I'm try to get a HiDPI-Image produced by an external application into > JavaFX using WritableImage. > > In the end the situation is comparable to what you get today when > loading an image from an URL (eg sample at 2.png) where JavaFX sets the > appropriate image pixelScale on "com.sun.prism.Image". > > If I'm not completely mistaken I would need an new API on PixelBuffer to > containing the pixelScale who is used QuantumImage to create an > appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 > because I fed in a HiDPI-Image already. > > Before filing an ehancement I wanted to bring this up here because maybe > I'm missing something obvious or maybe my proposal makes totally no sense. > > Tom From aghaisas at openjdk.java.net Fri Dec 3 10:28:20 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 3 Dec 2021 10:28:20 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Tue, 30 Nov 2021 11:02:41 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Move functionality in the setCellCount() to the invalidated block. > Some hard numbers used in tests (counters for evaluations) were changed because of this. > Instead of relying on hard values, I modified the failing was into relative ones. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 860: > 858: int cellCount = get(); > 859: resetSizeEstimates(); > 860: recalculateAndImproveEstimatedSize(2); We can use recalculateEstimatedSize() instead of this method. The effect is the same improvement with a size of 2. modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1124: > 1122: Platform.runLater(() -> { > 1123: Toolkit.getToolkit().firePulse(); > 1124: assertTrue(rt_35395_counter < 7); I see that you have modified assertions to use "lesser than" some expected value. This may hide some incorrect test outcomes. Along with "lesser than" assertion, do you think we should add a "greater than" assertion as well? This will have a range bounded expected value. This is applicable for all assertion changes in this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 11:19:21 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 11:19:21 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 10:20:43 GMT, Ajit Ghaisas wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Move functionality in the setCellCount() to the invalidated block. >> Some hard numbers used in tests (counters for evaluations) were changed because of this. >> Instead of relying on hard values, I modified the failing was into relative ones. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 1124: > >> 1122: Platform.runLater(() -> { >> 1123: Toolkit.getToolkit().firePulse(); >> 1124: assertTrue(rt_35395_counter < 7); > > I see that you have modified assertions to use "lesser than" some expected value. This may hide some incorrect test outcomes. > Along with "lesser than" assertion, do you think we should add a "greater than" assertion as well? This will have a range bounded expected value. > This is applicable for all assertion changes in this PR. The hard values have been changed a number of times, and I believe it is not really a good metric. What we want to ensure is that there is no functional regression and no performance penalty. The tests calculate the number of updateItem invocations and require those to be a strict number. With JDK-8089589, we fixed a number of issues that are related to the fact that the total size of the view (in case all cells are rendered with their preferred height) is not known. This is done by using an estimate of the total size. The estimate is 100% correct if we call updateItem for every item, but that would lead to a huge performance penalty in case the list contains a large amount of items with equal height. Hence, there is a balance between minimizing the updateItem calls but still have a fair estimate of the total dimensions. Rather than requiring that the amount of calls should be a fixed number, I think it makes more sense to ensure that the amount of calls stays within reasonable boundaries, and is not growing exponentially when we add linearly more items, for example. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 11:25:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 11:25:43 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: > After (re)setting the number of elements, make sure to do at least some estimation of the total size. > Added a testcase for this scenario. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comment (simplify call) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/683/files - new: https://git.openjdk.java.net/jfx/pull/683/files/b3fe2756..1a25a6d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/683.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/683/head:pull/683 PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 11:25:50 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 11:25:50 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: <2MHqi_GlXJXG9RmyJOunk2ZfEjfBOPXPNBbR20bzC2E=.ddd0bfea-5299-4c83-9226-47e895304e3c@github.com> On Fri, 3 Dec 2021 10:24:52 GMT, Ajit Ghaisas wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Move functionality in the setCellCount() to the invalidated block. >> Some hard numbers used in tests (counters for evaluations) were changed because of this. >> Instead of relying on hard values, I modified the failing was into relative ones. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 860: > >> 858: int cellCount = get(); >> 859: resetSizeEstimates(); >> 860: recalculateAndImproveEstimatedSize(2); > > We can use recalculateEstimatedSize() instead of this method. > The effect is the same improvement with a size of 2. True, good suggestion. I pushed that change. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 14:39:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 14:39:18 GMT Subject: RFR: 8276167: fixing VirtualFlow.scrollToTop(int) In-Reply-To: References: Message-ID: <-T9jR5OLFncKo2BcwuT6f_yO2Olyiw151yONJFH-ct0=.530d42bf-c64b-4570-ad04-8e9dc6a644d9@github.com> On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. This might be related to [JDK-8276553](https://bugs.openjdk.java.net/browse/JDK-8276553) / PR #683. After that one is reviewed and integrated, this bug needs to be retested to see if it is still a problem. If it is, then the fix may need to be adjusted. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From aghaisas at openjdk.java.net Fri Dec 3 14:44:12 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 3 Dec 2021 14:44:12 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 11:16:28 GMT, Johan Vos wrote: > The hard values have been changed a number of times, and I believe it is not really a good metric. I agree completely. > Rather than requiring that the amount of calls should be a fixed number, I think it makes more sense to ensure that the amount of calls stays within reasonable boundaries, and is not growing exponentially when we add linearly more items, for example. My point is exactly this. I see that as part of this PR, you have added the upper boundary (rather than a fixed number) for assertions. I am asking whether we need a lower boundary as well? ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 15:08:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 15:08:19 GMT Subject: RFR: 8276167: fixing VirtualFlow.scrollToTop(int) In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. Two global comments on this review: 1. Can you enable GitHub Actions testing for your repo as [described here](https://github.com/openjdk/jfx/pull/656/checks?check_run_id=4046432049)? 2. You need to change the title of this PR to match that of the JBS issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Fri Dec 3 15:13:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 15:13:16 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 14:41:11 GMT, Ajit Ghaisas wrote: >> The hard values have been changed a number of times, and I believe it is not really a good metric. >> What we want to ensure is that there is no functional regression and no performance penalty. The tests calculate the number of updateItem invocations and require those to be a strict number. With JDK-8089589, we fixed a number of issues that are related to the fact that the total size of the view (in case all cells are rendered with their preferred height) is not known. This is done by using an estimate of the total size. The estimate is 100% correct if we call updateItem for every item, but that would lead to a huge performance penalty in case the list contains a large amount of items with equal height. >> Hence, there is a balance between minimizing the updateItem calls but still have a fair estimate of the total dimensions. Rather than requiring that the amount of calls should be a fixed number, I think it makes more sense to ensure that the amount of calls stays within reasonable boundaries, and is not growing exponentially when we add linearly more items, for example. > >> The hard values have been changed a number of times, and I believe it is not really a good metric. > > I agree completely. > >> Rather than requiring that the amount of calls should be a fixed number, I think it makes more sense to ensure that the amount of calls stays within reasonable boundaries, and is not growing exponentially when we add linearly more items, for example. > > My point is exactly this. I see that as part of this PR, you have added the upper boundary (rather than a fixed number) for assertions. I am asking whether we need a lower boundary as well? I don't think we need a lower boundary. A value of 0 is not a bad thing, as long as the functional tests are ok. The lowest possible value is implicitly determined by the usecase, which is covered by the functional tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 18:50:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 18:50:14 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 11:25:43 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comment (simplify call) The fix and new test looks fine. I added one comment/question regarding the existing tests that check a count, but I'm OK with either answer. Approved. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 18:50:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 18:50:15 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: <5G83lHZL64OG7HwpTvhlLvoG83fJXEUOivwCXevcyl8=.43f6bfa5-601c-457e-a9b5-ad1001ee60d9@github.com> On Fri, 3 Dec 2021 15:10:35 GMT, Johan Vos wrote: >>> The hard values have been changed a number of times, and I believe it is not really a good metric. >> >> I agree completely. >> >>> Rather than requiring that the amount of calls should be a fixed number, I think it makes more sense to ensure that the amount of calls stays within reasonable boundaries, and is not growing exponentially when we add linearly more items, for example. >> >> My point is exactly this. I see that as part of this PR, you have added the upper boundary (rather than a fixed number) for assertions. I am asking whether we need a lower boundary as well? > > I don't think we need a lower boundary. A value of 0 is not a bad thing, as long as the functional tests are ok. > The lowest possible value is implicitly determined by the usecase, which is covered by the functional tests. And in this case, since the value used to be 0 before this fix, I think that's fine. For the other cases would it make sense to have a `> 0` check? Or are those cases for which 0 would be an OK value? ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From mstrauss at openjdk.java.net Fri Dec 3 18:58:12 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Dec 2021 18:58:12 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 11:25:43 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comment (simplify call) Would it be a good idea to fix the implementation of the `position` property as part of this PR (it has the same problem as `cellCount` before the fix)? If not, a follow-up ticket should be filed. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 19:30:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 19:30:16 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 18:55:29 GMT, Michael Strau? wrote: > Would it be a good idea to fix the implementation of the `position` property as part of this PR (it has the same problem as `cellCount` before the fix)? If not, a follow-up ticket should be filed. A follow-up issue, [JDK-8278064](https://bugs.openjdk.java.net/browse/JDK-8278064), was filed a couple days ago. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 19:36:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 19:36:11 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3] In-Reply-To: <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> Message-ID: On Thu, 2 Dec 2021 22:49:45 GMT, Michael Strau? wrote: >> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. >> This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Changes per review Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/660 From mstrauss at openjdk.java.net Fri Dec 3 20:16:13 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Dec 2021 20:16:13 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: <-L9NoJ2HLO8MrsKUWSJN07BdXxhHS21blZUrvFVZQNU=.2ed6e3bd-1555-4fed-9246-a93d34d337fe@github.com> On Fri, 3 Dec 2021 11:25:43 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comment (simplify call) Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 20:46:46 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 20:46:46 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v4] In-Reply-To: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: > After (re)setting the number of elements, make sure to do at least some estimation of the total size. > Added a testcase for this scenario. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: add checks on positive values on counters ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/683/files - new: https://git.openjdk.java.net/jfx/pull/683/files/1a25a6d5..35713395 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=02-03 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/683.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/683/head:pull/683 PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 20:46:48 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 20:46:48 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v3] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 18:47:24 GMT, Kevin Rushforth wrote: > The fix and new test looks fine. I added one comment/question regarding the existing tests that check a count, but I'm OK with either answer. The suggestion to test for positive values of the counters is a good idea. The lower this counter the better, but if the counter is 0, this means there has been no evaluation of updateItem. This should cause other tests to fail, but it helps if it would trigger a failure in this test as well. I added these asserts on the places where previously the expected value was not 0. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From mstrauss at openjdk.java.net Fri Dec 3 20:59:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Dec 2021 20:59:17 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v4] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 20:46:46 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add checks on positive values on counters Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Fri Dec 3 21:15:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 21:15:11 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v4] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Fri, 3 Dec 2021 20:46:46 GMT, Johan Vos wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > add checks on positive values on counters Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Fri Dec 3 21:34:14 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 3 Dec 2021 21:34:14 GMT Subject: Integrated: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 11:56:45 GMT, Johan Vos wrote: > After (re)setting the number of elements, make sure to do at least some estimation of the total size. > Added a testcase for this scenario. This pull request has now been integrated. Changeset: d3fbb516 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/d3fbb516c428876bd2389bbfd40f95a811ea6af8 Stats: 29 lines in 5 files changed: 19 ins; 2 del; 8 mod 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Reviewed-by: kcr, mstrauss ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From pbansal at openjdk.java.net Sat Dec 4 19:41:12 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 4 Dec 2021 19:41:12 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> References: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> Message-ID: On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Minimize changes I ran the full systemTest and this test is not introducing any regression. Also, the manual test attached in JBS works fine with this change. modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 448: > 446: > 447: if (ctx != NULL) { > 448: You can probably remove this unnecessary change as this is only one change in the file. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From pbansal at openjdk.java.net Sun Dec 5 06:16:20 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 5 Dec 2021 06:16:20 GMT Subject: RFR: 8273089: Deprecate JavaFX GTK 2 library for removal In-Reply-To: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> References: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> Message-ID: On Tue, 30 Nov 2021 13:26:30 GMT, Kevin Rushforth wrote: > This PR deprecates the JavaFX glass GTK 2 library for removal. Since there isn't an associated API, the mechanism for doing this is to print a "deprecated for removal" warning message when the `glassgtk2` library it is loaded. A message is printed regardless of why the GTK 2 library was loaded, which can happen for one of the following reasons: > > 1. The application or end user has explicitly requested GTK 2 using the `jdk.gtk.version` system property. > 2. Another native library has already loaded the GTK 2 library (an application cannot load both the GTK 2 and GTK 3 libraries in the same process) > 3. As a fallback if the gtk3 libraries are not available on the system. > > The warning messages are patterned after the security manager deprecation messages added as part of [JEP 411](https://openjdk.java.net/jeps/411). > > I added two system tests, one that sets the `jdk.gtk.version` system property to `2` and verifies that the warning message is printed, and one that doesn't set `jdk.gtk.version` and verifies that no warning message is printed. The changes look good to me. I can see that the warning is issued when the gtk version 2 is specified and not done otherwise. ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/685 From pbansal at openjdk.java.net Sun Dec 5 08:23:21 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 5 Dec 2021 08:23:21 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: On Wed, 10 Nov 2021 18:48:04 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. >> >> In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. >> >> I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case >> [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) >> . > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Remove extraneous whitespace The changes look fine. I ran the full system test and I do not see any regression being introduced because of this change. The manual test attached fails for all keys before the change. With the change, the test passes for most of the keys, but fails for following 3 keys * Failed: key code Comma did not match Shift+< * Failed: key code Comma did not match Shift+< * Failed: key code Comma did not match Shift+< * Failed: key code Comma did not match Shift+< * Failed: key code 0 did not match Shift+) * Failed: key code 0 did not match Shift+) * Failed: key code 0 did not match Shift+) * Failed: key code 9 did not match Shift+( * Failed: key code 9 did not match Shift+( * Failed: key code 9 did not match Shift+( ------------- PR: https://git.openjdk.java.net/jfx/pull/635 From duke at openjdk.java.net Mon Dec 6 01:38:09 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 6 Dec 2021 01:38:09 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: On Wed, 10 Nov 2021 18:48:04 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. >> >> In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. >> >> I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case >> [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) >> . > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Remove extraneous whitespace Gdk is finding these three characters (comma, left paren, right paren) on the main keyboard using the Shift modifier and on the keypad without Shift. Presumably there are keyboards out there which have some or all of these characters on the keypad and those keys were incorporated into the US keymap (but not French, Russian, or German). Most keys on the keypad have distinct keyvals but not these, they share the same keyvals as the keys on the main keyboard. I'll continue to investigate but this just reinforces my conviction that `KeyCharacterCombination` should be re-engineered. The current approach requires mapping backward from a character to a key which is difficult to do on every platform except Windows (where it's still tricky, see #672) and the requirement that each character maps to just one key is inherently limiting. ------------- PR: https://git.openjdk.java.net/jfx/pull/635 From aghaisas at openjdk.java.net Mon Dec 6 06:12:15 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 6 Dec 2021 06:12:15 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3] In-Reply-To: <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> Message-ID: On Thu, 2 Dec 2021 22:49:45 GMT, Michael Strau? wrote: >> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. >> This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Changes per review Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From jvos at openjdk.java.net Mon Dec 6 07:27:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 6 Dec 2021 07:27:08 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3] In-Reply-To: <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> Message-ID: <27wPvNDlzjOLtEwI1EbgW5MCuunBw6RAlSSO_UZx93M=.178c0647-d0d5-41e1-ac16-e18a496842e1@github.com> On Thu, 2 Dec 2021 22:49:45 GMT, Michael Strau? wrote: >> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. >> This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Changes per review I'll review in the next hours. ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From jvos at openjdk.java.net Mon Dec 6 08:09:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 6 Dec 2021 08:09:18 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3] In-Reply-To: <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> <1X_Txgsx-XGCEJzCNHkLziOiv7Yb3SwHfLWsLPscTX4=.f3938263-ad49-4a02-bcfa-07910bcfed0d@github.com> Message-ID: <6SE7pe_0H5lxDZF4Oh1lVX2-ROLlA6JkhB1kSj_Gu8A=.ab7dc4d8-c2e2-4eb3-8d3f-0c1192aeb56c@github.com> On Thu, 2 Dec 2021 22:49:45 GMT, Michael Strau? wrote: >> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. >> This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Changes per review This looks good to me. This new approach is based on the delta between the total height and the visible height, instead of only the total height. It might be good to capture this idea somehow in the commit message, but since it is clear from the code, I am totally ok with not changing the commit message. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/660 From duke at openjdk.java.net Mon Dec 6 08:22:37 2021 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 6 Dec 2021 08:22:37 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v2] In-Reply-To: References: Message-ID: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. eduardsdv has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into bugfix/JDK-8276167-VirtualFlow-scrollToTop - JDK-8276167: fixing VirtualFlow.scrollToTop(int) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/656/files - new: https://git.openjdk.java.net/jfx/pull/656/files/087e11d3..a7820448 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=00-01 Stats: 4192 lines in 92 files changed: 3532 ins; 274 del; 386 mod Patch: https://git.openjdk.java.net/jfx/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/656/head:pull/656 PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Mon Dec 6 09:27:18 2021 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 6 Dec 2021 09:27:18 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v2] In-Reply-To: References: Message-ID: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> On Mon, 6 Dec 2021 08:22:37 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into bugfix/JDK-8276167-VirtualFlow-scrollToTop > - JDK-8276167: fixing VirtualFlow.scrollToTop(int) I tested it again. Without the changes in this PR the bug is still there. If the item is larger than the viewport, the VirtualFlow.scrollToTop(int) scrolls to the end instead of to top of the item. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From mstrauss at openjdk.java.net Mon Dec 6 10:31:20 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 6 Dec 2021 10:31:20 GMT Subject: Integrated: 8276313: ScrollPane scroll delta incorrectly depends on content height In-Reply-To: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> References: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> Message-ID: <5RzrIACfr4jAge_xbZWJA64rnp53J1DRXZ4_rGccuDU=.aeb946b3-b975-4714-806b-f8ce82b9af3f@github.com> On Tue, 2 Nov 2021 10:49:45 GMT, Michael Strau? wrote: > This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. > This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. This pull request has now been integrated. Changeset: 5805bf8e Author: Michael Strau? Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/5805bf8e5de90427a68164e52c1fbbd08bfd0aa4 Stats: 73 lines in 2 files changed: 53 ins; 11 del; 9 mod 8276313: ScrollPane scroll delta incorrectly depends on content height Reviewed-by: kcr, aghaisas, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/660 From fastegal at openjdk.java.net Mon Dec 6 11:29:09 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 6 Dec 2021 11:29:09 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v2] In-Reply-To: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> References: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> Message-ID: <1oDZewgJZWrXD2XJLGJBiBZWvuYYEChc6lOo6BvCamA=.58738b11-f3b6-47df-a99a-1471454bffe2@github.com> On Mon, 6 Dec 2021 09:23:53 GMT, eduardsdv wrote: > I tested it again. Without the changes in this PR the bug is still there. **If the item is larger than the viewport**, the VirtualFlow.scrollToTop(int) scrolls to the end instead of to top of the item. ahhh .. finally I understand what you mean - bolding of the quote ;) Might be obvious for everybody except me .. but the bug report is missing that crucial information ... ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Mon Dec 6 12:43:17 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 6 Dec 2021 12:43:17 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v2] In-Reply-To: <1oDZewgJZWrXD2XJLGJBiBZWvuYYEChc6lOo6BvCamA=.58738b11-f3b6-47df-a99a-1471454bffe2@github.com> References: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> <1oDZewgJZWrXD2XJLGJBiBZWvuYYEChc6lOo6BvCamA=.58738b11-f3b6-47df-a99a-1471454bffe2@github.com> Message-ID: On Mon, 6 Dec 2021 11:26:24 GMT, Jeanette Winzenburg wrote: >> I tested it again. Without the changes in this PR the bug is still there. >> If the item is larger than the viewport, the VirtualFlow.scrollToTop(int) scrolls to the end instead of to top of the item. > >> I tested it again. Without the changes in this PR the bug is still there. **If the item is larger than the viewport**, the VirtualFlow.scrollToTop(int) scrolls to the end instead of to top of the item. > > ahhh .. finally I understand what you mean - bolding of the quote ;) Might be obvious for everybody except me .. but the bug report is missing that crucial information ... I agree with @kleopatra . It would be good to have this info in JBS, as well as with a small sample app. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Mon Dec 6 12:43:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 6 Dec 2021 12:43:18 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v2] In-Reply-To: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> References: <7SwQTEsufqH5kvRE8IJ7kqFAlEOB7JhuX67Uk5N56hU=.c6974e69-bb21-4d51-9b82-27ce25e445b0@github.com> Message-ID: On Mon, 6 Dec 2021 09:23:53 GMT, eduardsdv wrote: >> eduardsdv has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into bugfix/JDK-8276167-VirtualFlow-scrollToTop >> - JDK-8276167: fixing VirtualFlow.scrollToTop(int) > > I tested it again. Without the changes in this PR the bug is still there. > If the item is larger than the viewport, the VirtualFlow.scrollToTop(int) scrolls to the end instead of to top of the item. @eduardsdv This would be a good fix, but can you add a test that fails before and succeeds after this patch? Let me know if you need help with that. Thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From fastegal at openjdk.java.net Mon Dec 6 13:10:16 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 6 Dec 2021 13:10:16 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: On Mon, 2 Aug 2021 13:20:29 GMT, Michael Strau? wrote: > > 3. I think the way you are propagating `focusWithin` might not work if nodes are added or removed from the scene graph. > > I've added a test for this case: `FocusTest.testFocusStatesAreClearedFromFormerParentsOfFocusedNode`. might also need a test that verifies the focusWithin of a parent added somewhere above the focused node? hmm .. or maybe not, that would require to re-arrange a complete subtree .. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From fastegal at openjdk.java.net Mon Dec 6 13:49:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 6 Dec 2021 13:49:15 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed undeterministic test failures Just some musings (slightly overwhelmed by the magnitude of the suggested change ;) On first look it sounds like this has 2 separated (though related) parts: - focus-visible: that's visual sugar (*ducking) - focus-within: that might be a game changer (or enhancer) for both internal and external usage >From my current focus - *haha - on cell editing, the latter feels very promising for allowing fine-grained control of defining, implementing and configuring the required, much debated and (until now) unsuccessful tries on "commit-on-focusLost" semantics. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From duke at openjdk.java.net Mon Dec 6 14:58:52 2021 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 6 Dec 2021 14:58:52 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. eduardsdv has updated the pull request incrementally with one additional commit since the last revision: 8276170: Add junit for VirtualFlow.scrollToTop(int) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/656/files - new: https://git.openjdk.java.net/jfx/pull/656/files/a7820448..588a7e41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=01-02 Stats: 37 lines in 1 file changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/656/head:pull/656 PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Mon Dec 6 15:04:14 2021 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 6 Dec 2021 15:04:14 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 14:58:52 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276170: Add junit for VirtualFlow.scrollToTop(int) I added a junit which fails without patch and succeeds with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From mstrauss at openjdk.java.net Mon Dec 6 20:58:14 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 6 Dec 2021 20:58:14 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v2] In-Reply-To: References: Message-ID: <9vK-vU1-qWBN_i7oCVTT29r0fDRCcdNIwuJgiJhv8nQ=.98fe7f21-6acb-45a0-a66f-106dd3187236@github.com> On Mon, 6 Dec 2021 13:05:16 GMT, Jeanette Winzenburg wrote: > might also need a test that verifies the focusWithin of a parent added somewhere above the focused node? hmm .. or maybe not, that would require to re-arrange a complete subtree .. Inserting a parent into a scene graph such that the existing subtree at that position becomes a subtree of the newly inserted parent can't be done as an atomic operation. First, you'll need to remove the subtree at the insertion point from the existing scene graph (otherwise you'll get an exception saying that a node can only appear once in a scene graph). Then you can add the new parent with the removed subtree as its child. But what happens if the removed subtree contains a focused node? Since we can't know whether the removed subtree will ever be re-attached to the scene graph, we probably shouldn't keep its focus flags set. Moreover, `Scene.focusOwner` probably also should not refer to a node that is not part of the scene graph anymore. But that's not what happens: // Create a focusable rect var rect = new Rectangle(); rect.setFocusTraversable(true); // Add the rect to a group and requestFocus on the rect var root = new Group(rect); scene.setRoot(root); rect.requestFocus(); // Now, the rect is focused and it is the focus owner of the scene assertTrue(rect.isFocused()); assertSame(rect, scene.getFocusOwner()); // Remove the rect from the scene graph root.getChildren().clear(); // This is what I would now assume to be true (but isn't): assertFalse(rect.isFocused()); // FAILED: rect.isFocused() == true assertNotSame(rect, scene.getFocusOwner()); // FAILED: rect == scene.getFocusOwner() I'm inclined to think that this behavior is a bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From jvos at openjdk.java.net Tue Dec 7 08:41:33 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 08:41:33 GMT Subject: [jfx11u] RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Message-ID: Clean backport for 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver ------------- Commit messages: - 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Changes: https://git.openjdk.java.net/jfx11u/pull/65/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=65&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276847 Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/65.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/65/head:pull/65 PR: https://git.openjdk.java.net/jfx11u/pull/65 From jvos at openjdk.java.net Tue Dec 7 08:43:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 08:43:42 GMT Subject: [jfx17u] RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Message-ID: <_Uhhs6U2RdjXD5SKTt5zpNF-LRoN3UXQutxF_ZxUsKM=.673f03c5-279e-4f3c-9eb5-852970bad2d7@github.com> Clean backport (18->17) for 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver ------------- Commit messages: - 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Changes: https://git.openjdk.java.net/jfx17u/pull/24/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=24&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276847 Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx17u/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/24/head:pull/24 PR: https://git.openjdk.java.net/jfx17u/pull/24 From jvos at openjdk.java.net Tue Dec 7 08:46:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 08:46:39 GMT Subject: [jfx11u] RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Message-ID: backport (18->11) for 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound ------------- Commit messages: - 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Changes: https://git.openjdk.java.net/jfx11u/pull/66/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=66&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276490 Stats: 592 lines in 3 files changed: 581 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jfx11u/pull/66.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/66/head:pull/66 PR: https://git.openjdk.java.net/jfx11u/pull/66 From jvos at openjdk.java.net Tue Dec 7 08:47:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 08:47:42 GMT Subject: [jfx17u] RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Message-ID: backport (18->11) for 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound ------------- Commit messages: - 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Changes: https://git.openjdk.java.net/jfx17u/pull/25/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=25&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276490 Stats: 592 lines in 3 files changed: 581 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jfx17u/pull/25.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/25/head:pull/25 PR: https://git.openjdk.java.net/jfx17u/pull/25 From jvos at openjdk.java.net Tue Dec 7 09:26:21 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 09:26:21 GMT Subject: [jfx11u] Integrated: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 08:33:36 GMT, Johan Vos wrote: > Clean backport for 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver This pull request has now been integrated. Changeset: 04f5bc98 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/04f5bc983212fa49798162a2ef805855177996a2 Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Backport-of: b257647eb6011782b414e17c33a024ab95af7263 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/65 From jvos at openjdk.java.net Tue Dec 7 10:00:21 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 10:00:21 GMT Subject: [jfx11u] Integrated: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 08:39:20 GMT, Johan Vos wrote: > backport (18->11) for 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound This pull request has now been integrated. Changeset: 095c2c34 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/095c2c3482b8ca2118e35188fd71a45b419076cb Stats: 592 lines in 3 files changed: 581 ins; 1 del; 10 mod 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Backport-of: 0dbdec4af97063248758d917434d09242af42729 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/66 From jvos at openjdk.java.net Tue Dec 7 10:01:21 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 10:01:21 GMT Subject: [jfx17u] Integrated: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: <_Uhhs6U2RdjXD5SKTt5zpNF-LRoN3UXQutxF_ZxUsKM=.673f03c5-279e-4f3c-9eb5-852970bad2d7@github.com> References: <_Uhhs6U2RdjXD5SKTt5zpNF-LRoN3UXQutxF_ZxUsKM=.673f03c5-279e-4f3c-9eb5-852970bad2d7@github.com> Message-ID: On Tue, 7 Dec 2021 08:37:15 GMT, Johan Vos wrote: > Clean backport (18->17) for 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver This pull request has now been integrated. Changeset: 25abe09e Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/25abe09eba261127c27f486c82a384fc98bda27a Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Backport-of: b257647eb6011782b414e17c33a024ab95af7263 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/24 From jvos at openjdk.java.net Tue Dec 7 10:49:14 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Dec 2021 10:49:14 GMT Subject: [jfx17u] Integrated: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 08:39:43 GMT, Johan Vos wrote: > backport (18->11) for 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound This pull request has now been integrated. Changeset: 227afc85 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/227afc857c326afbdbf75fc4271ed3758a73006c Stats: 592 lines in 3 files changed: 581 ins; 1 del; 10 mod 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Backport-of: 0dbdec4af97063248758d917434d09242af42729 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/25 From fastegal at openjdk.java.net Tue Dec 7 12:25:12 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Dec 2021 12:25:12 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed undeterministic test failures thanks for taking a closer look :) > > might also need a test that verifies the focusWithin of a parent added somewhere above the focused node? hmm .. or maybe not, that would require to re-arrange a complete subtree .. > > Inserting a parent into a scene graph such that the existing subtree at that position becomes a subtree of the newly inserted parent can't be done as an atomic operation. First, you'll need to remove the subtree at the insertion point from the existing scene graph (otherwise you'll get an exception saying that a node can only appear once in a scene graph). Then you can add the new parent with the removed subtree as its child. yeah that's true, but might happen behind the scenes - we can move a focused node from one parent to another by simply adding it the new. So I'm not sure I would agree: > I'm inclined to think that this behavior is a bug. arguable, though :) Below is an example of moving a focused node (button "Moving", the other is just for having something else that might get the focus) between 2 parents by F1: the button keeps its focused state in its new parent (and scene's focusOwner doesn't change) - I think that's what a user would expect also when dragging a focused node around (s/he might not even be aware of the hierarchy). I suspect that changing the behavior would break existing applications - except if it could be done completely transparently. The example: private Parent createContent() { first = new VBox(); first.setBackground(new Background(new BackgroundFill(Color.ALICEBLUE, null, null))); first.getChildren().add(new Label("label on first")); second = new VBox(); second.setBackground(new Background(new BackgroundFill(Color.LAVENDER, null, null))); second.getChildren().add(new Label("label on second")); moving = new Button("moving"); first.getChildren().add(moving); Button move = new Button("move"); move.setOnAction(e -> { move(); }); move.setDefaultButton(true); HBox content = new HBox(10, first, second, move); content.addEventFilter(KeyEvent.KEY_PRESSED, e -> { if (e.getCode() == KeyCode.F1) { move(); } }); return content; } private void move() { Parent parent = moving.getParent(); Pane target = parent == first ? second : first; target.getChildren().add(moving); } @Override public void start(Stage stage) throws Exception { Scene scene = new Scene(createContent(), 300, 300); scene.focusOwnerProperty().addListener((scr, ov, nv) -> { System.out.println("focusOwner: " + nv); }); stage.setScene(scene); stage.show(); } private VBox first; private VBox second; private Button moving; ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From kcr at openjdk.java.net Tue Dec 7 13:11:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 13:11:18 GMT Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > This PR fixes an issue where the `DatePicker` is not committing his text as value when the focus is lost. > As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by this refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) > > The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. > > Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) > -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). Looks good. I've also "Reviewed" the CSR, so it can be finalized. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/679 From kcr at openjdk.java.net Tue Dec 7 13:37:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 13:37:36 GMT Subject: [jfx17u] RFR: 8272638: Update copyright header for files modified in 2021 Message-ID: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> Backport fix to update copyright changes. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. ------------- Commit messages: - 8272638: Update copyright header for files modified in 2021 Changes: https://git.openjdk.java.net/jfx17u/pull/26/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=26&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272638 Stats: 31 lines in 31 files changed: 0 ins; 0 del; 31 mod Patch: https://git.openjdk.java.net/jfx17u/pull/26.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/26/head:pull/26 PR: https://git.openjdk.java.net/jfx17u/pull/26 From kcr at openjdk.java.net Tue Dec 7 13:38:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 13:38:37 GMT Subject: [jfx11u] RFR: 8272638: Update copyright header for files modified in 2021 Message-ID: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> Backport fix to update copyright headers. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. ------------- Commit messages: - 8272638: Update copyright header for files modified in 2021 Changes: https://git.openjdk.java.net/jfx11u/pull/67/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=67&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272638 Stats: 202 lines in 202 files changed: 0 ins; 0 del; 202 mod Patch: https://git.openjdk.java.net/jfx11u/pull/67.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/67/head:pull/67 PR: https://git.openjdk.java.net/jfx11u/pull/67 From kcr at openjdk.java.net Tue Dec 7 13:43:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 13:43:14 GMT Subject: [jfx11u] RFR: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> References: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> Message-ID: On Tue, 7 Dec 2021 13:31:38 GMT, Kevin Rushforth wrote: > Backport fix to update copyright headers. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. @arapte or @johanvos can one of you review this? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/67 From kcr at openjdk.java.net Tue Dec 7 13:43:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 13:43:12 GMT Subject: [jfx17u] RFR: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> References: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> Message-ID: On Tue, 7 Dec 2021 13:30:44 GMT, Kevin Rushforth wrote: > Backport fix to update copyright changes. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. @arapte or @johanvos can one of you review this? ------------- PR: https://git.openjdk.java.net/jfx17u/pull/26 From fkirmaier at openjdk.java.net Tue Dec 7 15:02:43 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 7 Dec 2021 15:02:43 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak Message-ID: Making the initial listener of the ListProperty weak fixes the problem. The same is fixed for Set and Map. Due to a smart implementation, this is done without any performance drawback. (The trick is to have an object, which is both the WeakReference and the Changelistener) By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. ------------- Commit messages: - JDK-8277848 Changes: https://git.openjdk.java.net/jfx/pull/689/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277848 Stats: 157 lines in 6 files changed: 122 ins; 12 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/689/head:pull/689 PR: https://git.openjdk.java.net/jfx/pull/689 From mhanl at openjdk.java.net Fri Dec 10 00:29:44 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 10 Dec 2021 00:29:44 GMT Subject: RFR: 8278425: TreeTableCellStartEditTest uses deprecated TreeTableCell methods Message-ID: <0NpLmWZ77DVeqpmHLL1m8ypHU7hTMks91rszfPdMBLU=.daf85787-e0b7-44ee-b521-8ca9aefe9e22@github.com> This PR replaces 2 deprecations which were added in https://bugs.openjdk.java.net/browse/JDK-8188026 ------------- Commit messages: - 8278425: TreeTableCellStartEditTest uses deprecated TreeTableCell methods Changes: https://git.openjdk.java.net/jfx/pull/692/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=692&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278425 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/692.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/692/head:pull/692 PR: https://git.openjdk.java.net/jfx/pull/692 From aghaisas at openjdk.java.net Fri Dec 10 09:42:14 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 10 Dec 2021 09:42:14 GMT Subject: RFR: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> Message-ID: <5XyOsDruJnLcBnzMG1sr4q-HYKQQcmBV7lesjndez-c=.7ef90470-bf0c-4bc5-9b3d-e9bac2046402@github.com> On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth wrote: > This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. > > ## Notes to reviewers: > > The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. > > ### Shared Code > > The following were removed from the shared code. > > #### Removed Java classes > > > com.sun.javafx.tk.AppletWindow > com.sun.javafx.tk.quantum.GlassAppletWindow > > > #### Removed methods > > The following methods were removed in the parent class and all subclasses. > > > com.sun.glass.ui.Application: > public abstract Window createWindow(long parent) > > com.sun.glass.ui.Window: > public boolean getAppletMode() > public void setAppletMode(boolean appletMode) > public void dispatchNpapiEvent(Map eventInfo) > protected abstract long _createChildWindow(long parent) > protected Window(long parent) > protected abstract int _getEmbeddedX(long ptr) > protected abstract int _getEmbeddedY(long ptr) > > com.sun.javafx.tk.Toolkit: > public abstract AppletWindow createAppletWindow(...) > public abstract void closeAppletWindow() > > com.sun.javafx.tk.quantum.WindowStage: > static void setAppletWindow(GlassAppletWindow aw) > static GlassAppletWindow getAppletWindow() > > > > ### Linux (Gtk) Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.gtk.GtkChildWindow (class removed) > > com.sun.glass.ui.gtk.GtkWindow: > protected GtkWindow(long parent) > > > ### Linux (Gtk) native glass: > > The following native classes were removed: > > > WindowContextChild > WindowContextPlug > > > ### macOS Java code > > The following classes or methods were removed: > > > com.sun.glass.events.mac.NpapiEvent (class removed) > > com.sun.glass.ui.mac.MacApplication: > native protected String _getRemoteLayerServerName() > > com.sun.glass.ui.View: > public int getNativeRemoteLayerId(String serverName) > > com.sun.glass.ui.mac.MacView: > native protected int _getNativeRemoteLayerId(long ptr, String serverName) > native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) > > com.sun.glass.ui.mac.MacWindow: > protected MacWindow(long parent) > > > ### macOS native code > > The following native classes were removed: > > > GlassEmbeddedWindow* > GlassNSEvent > GlassView3D+Remote > RemoteLayerSupport > > > I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: > > > - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle > screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild > > > This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. > > ### Windows Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.win.WinChildWindow (class removed) > > com.sun.glass.ui.win.WinWindow: > protected WinWindow(long parent) > > > ### Windows native code > > After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: > > > GlassApplication::InstallMouseLLHook > GlassApplication::UninstallMouseLLHook > > > ### iOS Java code > > > com.sun.glass.ui.ios.IosWindow: > protected IosWindow(long parent) > > > ### iOS native code > > With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: > > > Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) > > > As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. Changes look good. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/615 From pbansal at openjdk.java.net Fri Dec 10 10:06:19 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 10 Dec 2021 10:06:19 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 20:13:11 GMT, Martin Fox wrote: > The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable punctuation and symbols in ways which vary across layouts and even keyboards. To determine the correct Java key code you have to query the layout to determine the character the key would generate without modifiers and map that character to the key code. `ViewContainer::HandleViewKeyEvent` did this, `getKeyCodeForChar` did not. This PR copies a few snippets of code from `ViewContainer::HandleViewKeyEvent` to make the two algorithms match. I tested the testcase attached in JBS and I see some issues with some of the keys with German Keyboard layout * Failed: key code Dead Acute did not match ? * Failed: key code Dead Acute did not match ? * Failed: key code Dead Acute did not match Shift+` * Failed: key code Dead Acute did not match Shift+` ------------- PR: https://git.openjdk.java.net/jfx/pull/672 From aghaisas at openjdk.java.net Fri Dec 10 10:16:15 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 10 Dec 2021 10:16:15 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 14:58:52 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276170: Add junit for VirtualFlow.scrollToTop(int) Fix looks good. I verified that the tests fail without fix and pass with it. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Fri Dec 10 12:36:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 10 Dec 2021 12:36:16 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 14:58:52 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276170: Add junit for VirtualFlow.scrollToTop(int) modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1584: > 1582: boolean posSet = false; > 1583: > 1584: if (index > getCellCount() - 1) { I agree that the previous code violates the contract that the flow should show the specified cell aligned to the top. I wonder though if this test is needed at all. What is the goal of providing an index that is larger than getCellCount() -1? modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1844: > 1842: } > 1843: listView.setPrefHeight(130); // roughly room for four rows > 1844: Toolkit.getToolkit().firePulse(); Why is this needed here? ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From kcr at openjdk.java.net Fri Dec 10 13:33:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 13:33:13 GMT Subject: RFR: 8278425: TreeTableCellStartEditTest uses deprecated TreeTableCell methods In-Reply-To: <0NpLmWZ77DVeqpmHLL1m8ypHU7hTMks91rszfPdMBLU=.daf85787-e0b7-44ee-b521-8ca9aefe9e22@github.com> References: <0NpLmWZ77DVeqpmHLL1m8ypHU7hTMks91rszfPdMBLU=.daf85787-e0b7-44ee-b521-8ca9aefe9e22@github.com> Message-ID: On Fri, 10 Dec 2021 00:12:20 GMT, Marius Hanl wrote: > This PR replaces 2 deprecations which were added in https://bugs.openjdk.java.net/browse/JDK-8188026 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/692 From duke at openjdk.java.net Fri Dec 10 13:38:20 2021 From: duke at openjdk.java.net (eduardsdv) Date: Fri, 10 Dec 2021 13:38:20 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 12:33:19 GMT, Johan Vos wrote: >> eduardsdv has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276170: Add junit for VirtualFlow.scrollToTop(int) > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1584: > >> 1582: boolean posSet = false; >> 1583: >> 1584: if (index > getCellCount() - 1) { > > I agree that the previous code violates the contract that the flow should show the specified cell aligned to the top. > > I wonder though if this test is needed at all. What is the goal of providing an index that is larger than getCellCount() -1? This part was originally copied from the 'VirtualContainerBase'. There was this comment: _special-case the 'greater than row count' condition to have it be perfectly at position 1_. Maybe to avoid throwing the IndexOutOfBoundsException or simply to scroll to the end. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Fri Dec 10 13:49:19 2021 From: duke at openjdk.java.net (eduardsdv) Date: Fri, 10 Dec 2021 13:49:19 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 12:33:29 GMT, Johan Vos wrote: >> eduardsdv has updated the pull request incrementally with one additional commit since the last revision: >> >> 8276170: Add junit for VirtualFlow.scrollToTop(int) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1844: > >> 1842: } >> 1843: listView.setPrefHeight(130); // roughly room for four rows >> 1844: Toolkit.getToolkit().firePulse(); > > Why is this needed here? Without this line the test fails in the line 1865 with the message 'expected:<7> but was:<8>'. I think this is because in the line 1850 'listView.scrollTo(99)' is executed, which now does not set the position to 1. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From mhanl at openjdk.java.net Fri Dec 10 13:50:15 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 10 Dec 2021 13:50:15 GMT Subject: Integrated: 8278425: TreeTableCellStartEditTest uses deprecated TreeTableCell methods In-Reply-To: <0NpLmWZ77DVeqpmHLL1m8ypHU7hTMks91rszfPdMBLU=.daf85787-e0b7-44ee-b521-8ca9aefe9e22@github.com> References: <0NpLmWZ77DVeqpmHLL1m8ypHU7hTMks91rszfPdMBLU=.daf85787-e0b7-44ee-b521-8ca9aefe9e22@github.com> Message-ID: On Fri, 10 Dec 2021 00:12:20 GMT, Marius Hanl wrote: > This PR replaces 2 deprecations which were added in https://bugs.openjdk.java.net/browse/JDK-8188026 This pull request has now been integrated. Changeset: 79151937 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/79151937b68ff4684f09b44979da67cf6c9ade0b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8278425: TreeTableCellStartEditTest uses deprecated TreeTableCell methods Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/692 From kcr at openjdk.java.net Fri Dec 10 14:03:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 14:03:11 GMT Subject: RFR: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> Message-ID: On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth wrote: > This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. > > ## Notes to reviewers: > > The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. > > ### Shared Code > > The following were removed from the shared code. > > #### Removed Java classes > > > com.sun.javafx.tk.AppletWindow > com.sun.javafx.tk.quantum.GlassAppletWindow > > > #### Removed methods > > The following methods were removed in the parent class and all subclasses. > > > com.sun.glass.ui.Application: > public abstract Window createWindow(long parent) > > com.sun.glass.ui.Window: > public boolean getAppletMode() > public void setAppletMode(boolean appletMode) > public void dispatchNpapiEvent(Map eventInfo) > protected abstract long _createChildWindow(long parent) > protected Window(long parent) > protected abstract int _getEmbeddedX(long ptr) > protected abstract int _getEmbeddedY(long ptr) > > com.sun.javafx.tk.Toolkit: > public abstract AppletWindow createAppletWindow(...) > public abstract void closeAppletWindow() > > com.sun.javafx.tk.quantum.WindowStage: > static void setAppletWindow(GlassAppletWindow aw) > static GlassAppletWindow getAppletWindow() > > > > ### Linux (Gtk) Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.gtk.GtkChildWindow (class removed) > > com.sun.glass.ui.gtk.GtkWindow: > protected GtkWindow(long parent) > > > ### Linux (Gtk) native glass: > > The following native classes were removed: > > > WindowContextChild > WindowContextPlug > > > ### macOS Java code > > The following classes or methods were removed: > > > com.sun.glass.events.mac.NpapiEvent (class removed) > > com.sun.glass.ui.mac.MacApplication: > native protected String _getRemoteLayerServerName() > > com.sun.glass.ui.View: > public int getNativeRemoteLayerId(String serverName) > > com.sun.glass.ui.mac.MacView: > native protected int _getNativeRemoteLayerId(long ptr, String serverName) > native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) > > com.sun.glass.ui.mac.MacWindow: > protected MacWindow(long parent) > > > ### macOS native code > > The following native classes were removed: > > > GlassEmbeddedWindow* > GlassNSEvent > GlassView3D+Remote > RemoteLayerSupport > > > I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: > > > - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle > screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild > > > This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. > > ### Windows Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.win.WinChildWindow (class removed) > > com.sun.glass.ui.win.WinWindow: > protected WinWindow(long parent) > > > ### Windows native code > > After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: > > > GlassApplication::InstallMouseLLHook > GlassApplication::UninstallMouseLLHook > > > ### iOS Java code > > > com.sun.glass.ui.ios.IosWindow: > protected IosWindow(long parent) > > > ### iOS native code > > With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: > > > Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) > > > As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. @johanvos or @jperedadnr -- before I integrate this do you want to take a look at the iOS changes here? The changes look trivially correct to me, but since I don't have the ability to build the iOS code, I wanted to give you a change to comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/615 From kcr at openjdk.java.net Fri Dec 10 14:08:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 14:08:10 GMT Subject: Integrated: 8278494: Remove .hgtags In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 13:02:32 GMT, Kevin Rushforth wrote: > Trivial fix to remove the obsolete `.hgtags` file from the repo. As mentioned in JBS, this file has (intentionally) not been updated since the switch to git. It will continue to be available in the `jfx17` branch [here](https://github.com/openjdk/jfx/blob/jfx17/.hgtags). The corresponding file was recently removed from the `jdk` repo. This pull request has now been integrated. Changeset: 85b8e96e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/85b8e96eb80dd066b10cd87b598875b7e7d1d511 Stats: 544 lines in 1 file changed: 0 ins; 544 del; 0 mod 8278494: Remove .hgtags Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/691 From jvos at openjdk.java.net Fri Dec 10 14:58:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 10 Dec 2021 14:58:18 GMT Subject: RFR: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> Message-ID: On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth wrote: > This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. > > ## Notes to reviewers: > > The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. > > ### Shared Code > > The following were removed from the shared code. > > #### Removed Java classes > > > com.sun.javafx.tk.AppletWindow > com.sun.javafx.tk.quantum.GlassAppletWindow > > > #### Removed methods > > The following methods were removed in the parent class and all subclasses. > > > com.sun.glass.ui.Application: > public abstract Window createWindow(long parent) > > com.sun.glass.ui.Window: > public boolean getAppletMode() > public void setAppletMode(boolean appletMode) > public void dispatchNpapiEvent(Map eventInfo) > protected abstract long _createChildWindow(long parent) > protected Window(long parent) > protected abstract int _getEmbeddedX(long ptr) > protected abstract int _getEmbeddedY(long ptr) > > com.sun.javafx.tk.Toolkit: > public abstract AppletWindow createAppletWindow(...) > public abstract void closeAppletWindow() > > com.sun.javafx.tk.quantum.WindowStage: > static void setAppletWindow(GlassAppletWindow aw) > static GlassAppletWindow getAppletWindow() > > > > ### Linux (Gtk) Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.gtk.GtkChildWindow (class removed) > > com.sun.glass.ui.gtk.GtkWindow: > protected GtkWindow(long parent) > > > ### Linux (Gtk) native glass: > > The following native classes were removed: > > > WindowContextChild > WindowContextPlug > > > ### macOS Java code > > The following classes or methods were removed: > > > com.sun.glass.events.mac.NpapiEvent (class removed) > > com.sun.glass.ui.mac.MacApplication: > native protected String _getRemoteLayerServerName() > > com.sun.glass.ui.View: > public int getNativeRemoteLayerId(String serverName) > > com.sun.glass.ui.mac.MacView: > native protected int _getNativeRemoteLayerId(long ptr, String serverName) > native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) > > com.sun.glass.ui.mac.MacWindow: > protected MacWindow(long parent) > > > ### macOS native code > > The following native classes were removed: > > > GlassEmbeddedWindow* > GlassNSEvent > GlassView3D+Remote > RemoteLayerSupport > > > I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: > > > - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle > screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild > > > This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. > > ### Windows Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.win.WinChildWindow (class removed) > > com.sun.glass.ui.win.WinWindow: > protected WinWindow(long parent) > > > ### Windows native code > > After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: > > > GlassApplication::InstallMouseLLHook > GlassApplication::UninstallMouseLLHook > > > ### iOS Java code > > > com.sun.glass.ui.ios.IosWindow: > protected IosWindow(long parent) > > > ### iOS native code > > With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: > > > Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) > > > As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. I did a build and sanity check for iOS, and it looks good. The removed code should indeed not be referenced. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/615 From jvos at openjdk.java.net Fri Dec 10 15:04:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 10 Dec 2021 15:04:18 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 13:34:53 GMT, eduardsdv wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1584: >> >>> 1582: boolean posSet = false; >>> 1583: >>> 1584: if (index > getCellCount() - 1) { >> >> I agree that the previous code violates the contract that the flow should show the specified cell aligned to the top. >> >> I wonder though if this test is needed at all. What is the goal of providing an index that is larger than getCellCount() -1? > > This part was originally copied from the 'VirtualContainerBase'. There was this comment: _special-case the 'greater than row count' condition to have it be perfectly at position 1_. > > Maybe to avoid throwing the IndexOutOfBoundsException or simply to scroll to the end. I am ok with this behavior, but then it should be specified in the javadoc for `@parameter index` that the value can be greater than row count, and that in that case the view will be positioned at the very end. @kevinrushforth do you have an opinion on this? This is unrelated to the current fix, so that should not stop this PR. >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewKeyInputTest.java line 1844: >> >>> 1842: } >>> 1843: listView.setPrefHeight(130); // roughly room for four rows >>> 1844: Toolkit.getToolkit().firePulse(); >> >> Why is this needed here? > > Without this line the test fails in the line 1865 with the message 'expected:<7> but was:<8>'. > I think this is because in the line 1850 'listView.scrollTo(99)' is executed, which now does not set the position to 1. > > It can also be caused by the https://bugs.openjdk.java.net/browse/JDK-8277785. When it is solved, this call will probably no longer be necessary. That is very well possible indeed. Since we estimate the size of the different cells, it is hard to deterministically put values on the counts. Therefor, I changed a number of tests from `equals` to `<` . I would personally suggest not adding the `pulse` here, but rather change the test in line 1865 with `... < 10 ` to make sure that there is no abnormal amount of processing. (and maybe also `> 0 ` to make sure that the updateItem is at least counted once). ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From kcr at openjdk.java.net Fri Dec 10 15:19:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 15:19:17 GMT Subject: Integrated: 8201538: Remove implementation support for applets from JavaFX In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com> Message-ID: <3Eary5hHqNZQkuWwbp6_vH-QrERELRSBXepZgwM7MGI=.f5b4435b-01cd-4cd6-b1bf-086d4715194a@github.com> On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth wrote: > This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed. > > ## Notes to reviewers: > > The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called. > > ### Shared Code > > The following were removed from the shared code. > > #### Removed Java classes > > > com.sun.javafx.tk.AppletWindow > com.sun.javafx.tk.quantum.GlassAppletWindow > > > #### Removed methods > > The following methods were removed in the parent class and all subclasses. > > > com.sun.glass.ui.Application: > public abstract Window createWindow(long parent) > > com.sun.glass.ui.Window: > public boolean getAppletMode() > public void setAppletMode(boolean appletMode) > public void dispatchNpapiEvent(Map eventInfo) > protected abstract long _createChildWindow(long parent) > protected Window(long parent) > protected abstract int _getEmbeddedX(long ptr) > protected abstract int _getEmbeddedY(long ptr) > > com.sun.javafx.tk.Toolkit: > public abstract AppletWindow createAppletWindow(...) > public abstract void closeAppletWindow() > > com.sun.javafx.tk.quantum.WindowStage: > static void setAppletWindow(GlassAppletWindow aw) > static GlassAppletWindow getAppletWindow() > > > > ### Linux (Gtk) Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.gtk.GtkChildWindow (class removed) > > com.sun.glass.ui.gtk.GtkWindow: > protected GtkWindow(long parent) > > > ### Linux (Gtk) native glass: > > The following native classes were removed: > > > WindowContextChild > WindowContextPlug > > > ### macOS Java code > > The following classes or methods were removed: > > > com.sun.glass.events.mac.NpapiEvent (class removed) > > com.sun.glass.ui.mac.MacApplication: > native protected String _getRemoteLayerServerName() > > com.sun.glass.ui.View: > public int getNativeRemoteLayerId(String serverName) > > com.sun.glass.ui.mac.MacView: > native protected int _getNativeRemoteLayerId(long ptr, String serverName) > native protected void _hostRemoteLayerId(long ptr, int nativeLayerId) > > com.sun.glass.ui.mac.MacWindow: > protected MacWindow(long parent) > > > ### macOS native code > > The following native classes were removed: > > > GlassEmbeddedWindow* > GlassNSEvent > GlassView3D+Remote > RemoteLayerSupport > > > I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was: > > > - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle > screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild > > > This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`. > > ### Windows Java code > > The following classes or methods were removed: > > > com.sun.glass.ui.win.WinChildWindow (class removed) > > com.sun.glass.ui.win.WinWindow: > protected WinWindow(long parent) > > > ### Windows native code > > After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following: > > > GlassApplication::InstallMouseLLHook > GlassApplication::UninstallMouseLLHook > > > ### iOS Java code > > > com.sun.glass.ui.ios.IosWindow: > protected IosWindow(long parent) > > > ### iOS native code > > With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed: > > > Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong) > > > As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon. This pull request has now been integrated. Changeset: 4f9b047b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/4f9b047b8301ee3580588dd34ab809f5c6c4c193 Stats: 3424 lines in 64 files changed: 32 ins; 3308 del; 84 mod 8201538: Remove implementation support for applets from JavaFX Reviewed-by: mstrauss, aghaisas, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/615 From duke at openjdk.java.net Fri Dec 10 15:24:44 2021 From: duke at openjdk.java.net (eduardsdv) Date: Fri, 10 Dec 2021 15:24:44 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v4] In-Reply-To: References: Message-ID: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. eduardsdv has updated the pull request incrementally with one additional commit since the last revision: 8276167: Avoid additional Toolkit.getToolkit().firePulse() Avoid using of additional Toolkit.getToolkit().firePulse() in the test, adjust expected values instead. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/656/files - new: https://git.openjdk.java.net/jfx/pull/656/files/588a7e41..73e11f4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=656&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/656/head:pull/656 PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Fri Dec 10 15:24:45 2021 From: duke at openjdk.java.net (eduardsdv) Date: Fri, 10 Dec 2021 15:24:45 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 15:00:56 GMT, Johan Vos wrote: >> Without this line the test fails in the line 1865 with the message 'expected:<7> but was:<8>'. >> I think this is because in the line 1850 'listView.scrollTo(99)' is executed, which now does not set the position to 1. >> >> It can also be caused by the https://bugs.openjdk.java.net/browse/JDK-8277785. When it is solved, this call will probably no longer be necessary. > > That is very well possible indeed. Since we estimate the size of the different cells, it is hard to deterministically put values on the counts. Therefor, I changed a number of tests from `equals` to `<` . I would personally suggest not adding the `pulse` here, but rather change the test in line 1865 with `... < 10 ` to make sure that there is no abnormal amount of processing. (and maybe also `> 0 ` to make sure that the updateItem is at least counted once). I removed the Toolkit.getToolkit().firePulse() and adjusted the expected values in the test. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Fri Dec 10 17:27:18 2021 From: duke at openjdk.java.net (Martin Fox) Date: Fri, 10 Dec 2021 17:27:18 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 20:13:11 GMT, Martin Fox wrote: > The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable punctuation and symbols in ways which vary across layouts and even keyboards. To determine the correct Java key code you have to query the layout to determine the character the key would generate without modifiers and map that character to the key code. `ViewContainer::HandleViewKeyEvent` did this, `getKeyCodeForChar` did not. This PR copies a few snippets of code from `ViewContainer::HandleViewKeyEvent` to make the two algorithms match. Thanks for catching this, I should have investigated dead keys in more detail earlier. The test case code should exclude dead keys since they're not eligible as shortcuts on Windows. If the Control key is down when a dead key is pressed both Windows and JavaFX just ignore it. If some other modifier is down (say, Alt) Windows will treat it as a dead key and JavaFX should not treat it as a shortcut. In a perfect world `getKeyCodeForChar` would return `KeyCode.UNDEFINED` for dead keys to disable shortcut processing. But I can't figure out way of detecting that the key is a dead key. `MapVirtualKeyEx` is supposed to tell me that but doesn't. `ToUnicodeEx` would do the job but has side effects in the global keyboard state so it is off-limits. The best I can do is what the code already does and return a non-dead `KeyCode` that will never match the current `KeyEvent`. ------------- PR: https://git.openjdk.java.net/jfx/pull/672 From kcr at openjdk.java.net Fri Dec 10 22:48:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 22:48:18 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: <26u3-5wk49pxpfnrf7HRJJECrOGSIKLS326Gr-wxzXw=.366cb782-5f69-4b3e-8033-d6d6bde62ddd@github.com> On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] Overall, this looks good. I left a few questions and comments inline. modules/javafx.media/src/main/native/gstreamer/plugins/av/videodecoder.c line 525: > 523: if (decoder->sws_context == NULL || decoder->dest_frame == NULL || > 524: decoder->sws_scale_func == NULL) > 525: return TRUE; Should this be `return FALSE;`? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 313: > 311: default: > 312: break; > 313: } This block is a no-op. Is this intended? (and if so, is it needed?) modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 517: > 515: do > 516: { > 517: hr = decoder->pDecoder->GetOutputAvailableType(0, dwTypeIndex, &pDecoderOutputType); Do you need to check `SUCCEEDED(hr)` here? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 571: > 569: SafeRelease(&pDecoderOutputType); > 570: > 571: } while (hr != MF_E_NO_MORE_TYPES && hr != S_OK); Should this be `FAILED(hr)` instead of `hr != S_OK`? Also, is it guaranteed to get success or `MF_E_NO_MORE_TYPES`? If not, this could lead to an infinite loop. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 577: > 575: do > 576: { > 577: hr = decoder->pColorConvert->GetOutputAvailableType(0, dwTypeIndex, &pConverterOutputType); Same questions for this loop as for the previous. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 684: > 682: return FALSE; > 683: } > 684: else if (hr == MF_E_TRANSFORM_STREAM_CHANGE) Is it OK that this case will return FALSE always? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 723: > 721: > 722: if (SUCCEEDED(hr)) > 723: hr = pMediaBuffer->Lock(&pBuffer, &cbMaxLength, &cbCurrentLength); If this succeeds, but later operations fail, it seems possible that Unlock won't be called in some cases. Might this cause a problem? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 730: > 728: GstMapInfo info; > 729: > 730: if (!gst_buffer_map(pGstBuffer, &info, GST_MAP_WRITE)) Do you need to check for `pGstBuffer == NULL`? My concern is that either `gst_buffer_map` will crash if it is, or else it return NULL and then `gst_buffer_unref` might crash. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 791: > 789: return PO_FLUSHING; > 790: > 791: HRESULT hr = decoder->pDecoder->GetOutputStatus(&dwFlags); Do you not need to check `hr` here? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 811: > 809: do > 810: { > 811: hr = decoder->pDecoder->GetOutputAvailableType(0, dwTypeIndex, &pOutputType); Same question as earlier loops -- do you need to check `hr` (from previous time through loop) here? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 963: > 961: // Ask decoder to produce all remaining data > 962: if (SUCCEEDED(hr)) > 963: hr = decoder->pDecoder->ProcessMessage(MFT_MESSAGE_COMMAND_DRAIN, 0); Does this `hr` need to be checked? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1101: > 1099: > 1100: // Get array count > 1101: arrayCount = *(guint8*)bdata; Should this count be sanity checked? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1114: > 1112: nalUnitsCount = ((guint16)*(guint8*)bdata) << 8; > 1113: bdata++; in_bytes_count++; > 1114: nalUnitsCount |= (guint16)*(guint8*)bdata; Should this count be sanity checked? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1123: > 1121: nalUnitLength = ((guint16)*(guint8*)bdata) << 8; > 1122: bdata++; in_bytes_count++; > 1123: nalUnitLength |= (guint16)*(guint8*)bdata; Same question about count. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1346: > 1344: default: > 1345: break; > 1346: } This is a no-op. Is it intended? ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From duke at openjdk.java.net Thu Dec 9 08:40:58 2021 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 9 Dec 2021 08:40:58 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 14:58:52 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276170: Add junit for VirtualFlow.scrollToTop(int) Please review. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From fkirmaier at openjdk.java.net Thu Dec 9 12:45:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 9 Dec 2021 12:45:32 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v4] In-Reply-To: References: Message-ID: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 Fixed rare bug, causing bounds to be out of sync. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/584/files - new: https://git.openjdk.java.net/jfx/pull/584/files/28b793b5..29b90745 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/584/head:pull/584 PR: https://git.openjdk.java.net/jfx/pull/584 From fastegal at openjdk.java.net Wed Dec 8 10:37:22 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 8 Dec 2021 10:37:22 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 15:44:26 GMT, Michael Strau? wrote: >However, I'd still argue that a node that is not part of the scene graph (non-atomically) should not be the focus owner of the scene graph. I agree :) But that's what seems to happen: in my example, add a handler to remove the focused "moving" button. When removed, the scene's focus owner is either the next focusable (the "move" button) or null if there is none. On re-adding the button, it's either unfocused (if there had been a next focusable) or focused (if there is none). Not sure what happens in your test snippet .. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From fkirmaier at openjdk.java.net Thu Dec 9 12:50:04 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 9 Dec 2021 12:50:04 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v4] In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 12:45:32 GMT, Florian Kirmaier wrote: >> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269907 > Fixed rare bug, causing bounds to be out of sync. If found a bug in the current implementation and fixed it - which took quite long. It seems like, calling synchronizeSceneNodes without calling updateBounds() can cause that the NGNode can get out of sync. Which then caused rendering bugs with disappearing objects. This is now fixed. I've also added a call to the `syncLights` and `synchronizeSceneProperties` methods. I think it's less complex to just sync everything, instead of just syncing a subset - also when making a snapshot. Maybe it would make sense to add a check like the following, to the doUpdatePeer() method? if(txBoundsInvalid) { PlatformLogger logger = Logging.getInputLogger(); if (logger.isLoggable(Level.WARN)) { logger.finer("txBoundsInvalid ot of sync on doUpdatePeer"); } } ------------- PR: https://git.openjdk.java.net/jfx/pull/584 From kcr at openjdk.java.net Tue Dec 7 17:03:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 17:03:16 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: Message-ID: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> On Sat, 14 Aug 2021 13:00:52 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year I tested this on all three platforms and it looks good. There are a couple of copy/paste typos where `SpotLight` should be `DirectionalLight`. I also left a question / suggestion for dealing with the boolean. You can either change it, or leave it and add a comment. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DirectionalLightHelper.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. 2021 modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DirectionalLightHelper.java line 35: > 33: > 34: /** > 35: * Used to access internal methods of SpotLight. Typo: `SpotLight` --> `DirectionalLight`. modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Light.java line 68: > 66: > 67: boolean isDirectionalLight() { > 68: return isAttenuated < 0.5; Minor: you can just test for 0 or not 0 since you only ever set them as constants. It's up to you...I don't object to rounding, which is effectively what you've done. modules/javafx.graphics/src/main/java/javafx/scene/DirectionalLight.java line 43: > 41: * A light that illuminates an object from a specific direction. > 42: * The direction is defined by the {@link #directionProperty() direction} vector property of the light. The direction > 43: * can be rotated by setting a rotation transform on the {@code SpotLight}. For example, if the direction vector is Typo: `SpotLight` --> `DirectionalLight` modules/javafx.graphics/src/main/native-prism-d3d/D3DLight.cc line 54: > 52: > 53: bool D3DLight::isDirectionalLight() { > 54: return attenuation[3] < 0.5; Same comment as for `ES2Light`. modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 106: > 104: > 105: void computeLight(float i, float3 n, float3 refl, float specPower, float3 L, float3 lightDir, in out float3 d, in out float3 s) { > 106: if (gLightAttenuation[i].w < 0.5) { Is there any performance difference between `< 0.5` and `!= 0` ? I suspect not, but in any case, you might consider the latter (as I also mentioned in the java files). The latter is more clear, so if you choose to stick with what you have, I'd like to see a comment added. modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag line 122: > 120: Light light = lights[i]; > 121: vec3 lightDir = lightTangentSpaceDirections[i].xyz; > 122: if (light.attn.w < 0.5) { Same comment as D3D shaders. tests/performance/3DLighting/attenuation/Environment.java line 85: > 83: pointLight2.setTranslateX(-LIGHT_X_DIST); > 84: spotLight2.setTranslateX(-LIGHT_X_DIST); > 85: I recommend setting the direction of `directionalLight1` and `directionalLight2` as follows: directionalLight1.setDirection(new Point3D(-LIGHT_X_DIST, 0, LIGHT_Z_DIST)); directionalLight2.setDirection(new Point3D(LIGHT_X_DIST, 0, LIGHT_Z_DIST)); tests/system/src/test/java/test/javafx/scene/lighting3D/DirectionalLightTest.java line 71: > 69: > 70: @Test > 71: public void testSpotlightAttenuation() { Should be `testDirectionalLight`. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From fkirmaier at openjdk.java.net Tue Dec 7 15:21:56 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 7 Dec 2021 15:21:56 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v2] In-Reply-To: References: Message-ID: > Making the initial listener of the ListProperty weak fixes the problem. > The same is fixed for Set and Map. > Due to a smart implementation, this is done without any performance drawback. > (The trick is to have an object, which is both the WeakReference and the Changelistener) > By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8277848 Added missing change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/689/files - new: https://git.openjdk.java.net/jfx/pull/689/files/675f3bf9..f9b7009b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=689&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/689.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/689/head:pull/689 PR: https://git.openjdk.java.net/jfx/pull/689 From mhanl at openjdk.java.net Tue Dec 7 19:59:11 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 7 Dec 2021 19:59:11 GMT Subject: Integrated: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > This PR fixes an issue where the `DatePicker` is not committing his text as value when the focus is lost. > As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by this refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) > > The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. > > Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) > -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). This pull request has now been integrated. Changeset: 6fd4ab61 Author: Marius Hanl Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6fd4ab6104ebaa97530ea9182466e6c1e346a4f4 Stats: 133 lines in 2 files changed: 133 ins; 0 del; 0 mod 8191995: Regression: DatePicker must commit on focusLost Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/679 From fastegal at openjdk.java.net Thu Dec 9 12:50:28 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 9 Dec 2021 12:50:28 GMT Subject: RFR: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) Message-ID: Extracted static test utility methods from EditAndScrollTest into new VirtualizedControlTestUtils, added rudimentary tests for the methods. ------------- Commit messages: - 8278134: Move static utility methods to infrastructure Changes: https://git.openjdk.java.net/jfx/pull/690/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=690&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278134 Stats: 348 lines in 3 files changed: 290 ins; 57 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/690.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/690/head:pull/690 PR: https://git.openjdk.java.net/jfx/pull/690 From arapte at openjdk.java.net Thu Dec 9 13:21:01 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 9 Dec 2021 13:21:01 GMT Subject: RFR: 8278494: Remove .hgtags In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 13:02:32 GMT, Kevin Rushforth wrote: > Trivial fix to remove the obsolete `.hgtags` file from the repo. As mentioned in JBS, this file has (intentionally) not been updated since the switch to git. It will continue to be available in the `jfx17` branch [here](https://github.com/openjdk/jfx/blob/jfx17/.hgtags). The corresponding file was recently removed from the `jdk` repo. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/691 From kcr at openjdk.java.net Thu Dec 9 13:09:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Dec 2021 13:09:19 GMT Subject: RFR: 8278494: Remove .hgtags Message-ID: Trivial fix to remove the obsolete `.hgtags` file from the repo. As mentioned in JBS, this file has (intentionally) not been updated since the switch to git. It will continue to be available in the `jfx17` branch [here](https://github.com/openjdk/jfx/blob/jfx17/.hgtags). The corresponding file was recently removed from the `jdk` repo. ------------- Commit messages: - 8278494: Remove .hgtags Changes: https://git.openjdk.java.net/jfx/pull/691/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=691&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278494 Stats: 544 lines in 1 file changed: 0 ins; 544 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/691.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/691/head:pull/691 PR: https://git.openjdk.java.net/jfx/pull/691 From kcr at openjdk.java.net Fri Dec 10 23:51:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 23:51:17 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v3] In-Reply-To: References: Message-ID: <2AT11d1W4eAY-15HO-NAF37xnZwXPoOzdZX774TVAFs=.7a9e4745-e8bd-4165-81b7-8c72ec953ef2@github.com> On Fri, 10 Dec 2021 14:58:25 GMT, Johan Vos wrote: >> This part was originally copied from the 'VirtualContainerBase'. There was this comment: _special-case the 'greater than row count' condition to have it be perfectly at position 1_. >> >> Maybe to avoid throwing the IndexOutOfBoundsException or simply to scroll to the end. > > I am ok with this behavior, but then it should be specified in the javadoc for `@parameter index` that the value can be greater than row count, and that in that case the view will be positioned at the very end. > @kevinrushforth do you have an opinion on this? > This is unrelated to the current fix, so that should not stop this PR. This seems reasonable to me, too. And I agree that it should be specified via a follow-up issue, which will need a CSR. ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From kcr at openjdk.java.net Tue Dec 7 17:12:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 17:12:14 GMT Subject: [jfx11u] Integrated: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> References: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> Message-ID: On Tue, 7 Dec 2021 13:31:38 GMT, Kevin Rushforth wrote: > Backport fix to update copyright headers. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. This pull request has now been integrated. Changeset: 4bf7c43e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/4bf7c43eaf799db8a1f62be87cf1e059075e97df Stats: 202 lines in 202 files changed: 0 ins; 0 del; 202 mod 8272638: Update copyright header for files modified in 2021 Reviewed-by: arapte Backport-of: 28e86841412dce99b92b8d75b798a63312aa25cd ------------- PR: https://git.openjdk.java.net/jfx11u/pull/67 From arapte at openjdk.java.net Tue Dec 7 16:18:20 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Dec 2021 16:18:20 GMT Subject: [jfx11u] RFR: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> References: <7MFtlT5qWa3tfisMkan0HjWZf7WAmwie9TcQAxVSZso=.e43f2d16-9374-40b9-9224-b51c3f66b553@github.com> Message-ID: On Tue, 7 Dec 2021 13:31:38 GMT, Kevin Rushforth wrote: > Backport fix to update copyright headers. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/67 From kcr at openjdk.java.net Tue Dec 7 17:11:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 17:11:19 GMT Subject: [jfx17u] Integrated: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> References: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> Message-ID: On Tue, 7 Dec 2021 13:30:44 GMT, Kevin Rushforth wrote: > Backport fix to update copyright changes. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. This pull request has now been integrated. Changeset: deafc408 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/deafc408041af2c4c2ccdec683bc917d73038fb6 Stats: 31 lines in 31 files changed: 0 ins; 0 del; 31 mod 8272638: Update copyright header for files modified in 2021 Reviewed-by: arapte Backport-of: 28e86841412dce99b92b8d75b798a63312aa25cd ------------- PR: https://git.openjdk.java.net/jfx17u/pull/26 From arapte at openjdk.java.net Tue Dec 7 16:38:19 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Dec 2021 16:38:19 GMT Subject: [jfx17u] RFR: 8272638: Update copyright header for files modified in 2021 In-Reply-To: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> References: <_x8RpXlEoMUC31hTQ6J9iMEC_6Yru843sCTScxK6GEc=.30be3ffc-de08-4757-937c-723cabb8f649@github.com> Message-ID: <0EGg95Fa8bsNgXmkwljIqCMwaINWYkraYuQj_habfIo=.796a17ff-438f-4f3d-a658-888dd12227ba@github.com> On Tue, 7 Dec 2021 13:30:44 GMT, Kevin Rushforth wrote: > Backport fix to update copyright changes. This was done by a script that checks the copyright years for all files modified this year and updates the ones that are missing 2021. As such it won't be a clean backport. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/26 From kcr at openjdk.java.net Sat Dec 11 00:35:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 11 Dec 2021 00:35:09 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> References: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> Message-ID: On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Minimize changes On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From almatvee at openjdk.java.net Sat Dec 11 05:24:40 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 11 Dec 2021 05:24:40 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v3] In-Reply-To: References: Message-ID: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/6cb1ac5c..cb1ee6c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=01-02 Stats: 110 lines in 1 file changed: 13 ins; 80 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649 From almatvee at openjdk.java.net Sat Dec 11 05:24:58 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 11 Dec 2021 05:24:58 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: <26u3-5wk49pxpfnrf7HRJJECrOGSIKLS326Gr-wxzXw=.366cb782-5f69-4b3e-8033-d6d6bde62ddd@github.com> References: <26u3-5wk49pxpfnrf7HRJJECrOGSIKLS326Gr-wxzXw=.366cb782-5f69-4b3e-8033-d6d6bde62ddd@github.com> Message-ID: On Fri, 10 Dec 2021 19:34:25 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v3] > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 313: > >> 311: default: >> 312: break; >> 313: } > > This block is a no-op. Is this intended? (and if so, is it needed?) Actually mfwrapper_change_state() is not needed, since it is not used at all. Default handler should be just fine. It was copy-paste from dshowwrapper when I created this element and forgot to remove it. In dshowwrapper it is used. I will remove this function. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 517: > >> 515: do >> 516: { >> 517: hr = decoder->pDecoder->GetOutputAvailableType(0, dwTypeIndex, &pDecoderOutputType); > > Do you need to check `SUCCEEDED(hr)` here? No checks below should handle it in case if it fails. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 571: > >> 569: SafeRelease(&pDecoderOutputType); >> 570: >> 571: } while (hr != MF_E_NO_MORE_TYPES && hr != S_OK); > > Should this be `FAILED(hr)` instead of `hr != S_OK`? Also, is it guaranteed to get success or `MF_E_NO_MORE_TYPES`? If not, this could lead to an infinite loop. Fixed. Yes, it should be FAILED(hr) and it is not guaranteed to get success or MF_E_NO_MORE_TYPES. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 577: > >> 575: do >> 576: { >> 577: hr = decoder->pColorConvert->GetOutputAvailableType(0, dwTypeIndex, &pConverterOutputType); > > Same questions for this loop as for the previous. Fixed as well. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 684: > >> 682: return FALSE; >> 683: } >> 684: else if (hr == MF_E_TRANSFORM_STREAM_CHANGE) > > Is it OK that this case will return FALSE always? Yes, we return TRUE only if we got output from converter which is ready to be delivered. MF_E_TRANSFORM_STREAM_CHANGE is needed to reconfigure converter. I removed MF_E_TRANSFORM_NEED_MORE_INPUT since it is not needed. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 723: > >> 721: >> 722: if (SUCCEEDED(hr)) >> 723: hr = pMediaBuffer->Lock(&pBuffer, &cbMaxLength, &cbCurrentLength); > > If this succeeds, but later operations fail, it seems possible that Unlock won't be called in some cases. Might this cause a problem? It can cause a problem, but it should be called, since nothing will change hr value between Lock/Unlock. I will remove unnecessary check of hr value before unlock. It will only miss unlock if cbCurrentLength == 0, which can happen for empty buffers, but unlikely. I will fix it as well. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 730: > >> 728: GstMapInfo info; >> 729: >> 730: if (!gst_buffer_map(pGstBuffer, &info, GST_MAP_WRITE)) > > Do you need to check for `pGstBuffer == NULL`? My concern is that either `gst_buffer_map` will crash if it is, or else it return NULL and then `gst_buffer_unref` might crash. Yes, we should. I fixed it. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 791: > >> 789: return PO_FLUSHING; >> 790: >> 791: HRESULT hr = decoder->pDecoder->GetOutputStatus(&dwFlags); > > Do you not need to check `hr` here? Yes, fixed. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 811: > >> 809: do >> 810: { >> 811: hr = decoder->pDecoder->GetOutputAvailableType(0, dwTypeIndex, &pOutputType); > > Same question as earlier loops -- do you need to check `hr` (from previous time through loop) here? Fixed as well. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 963: > >> 961: // Ask decoder to produce all remaining data >> 962: if (SUCCEEDED(hr)) >> 963: hr = decoder->pDecoder->ProcessMessage(MFT_MESSAGE_COMMAND_DRAIN, 0); > > Does this `hr` need to be checked? No, I removed it. I think we still need to attempt reading data from decoder, even if it refused DRAIN which asks decoder to produce all output it can possible produce without any additional input. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1101: > >> 1099: >> 1100: // Get array count >> 1101: arrayCount = *(guint8*)bdata; > > Should this count be sanity checked? No, checks for in_bytes_count and out_bytes_count seems to handle any bad values for arrayCount, nalUnitsCount or nalUnitLength just fine. I tested it under debugger by modifying these variables. > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 1346: > >> 1344: default: >> 1345: break; >> 1346: } > > This is a no-op. Is it intended? No, mfwrapper_src_query() is not needed. Removed. Same for mfwrapper_src_event(). ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From almatvee at openjdk.java.net Sat Dec 11 05:25:04 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 11 Dec 2021 05:25:04 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 452: > 450: > 451: if (SUCCEEDED(hr)) > 452: hr = pBuffer->Lock(&pbBuffer, NULL, NULL); I fixed unlock here as well in case if code below fails. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 559: > 557: hr = MFSetAttributeRatio(pInputType, MF_MT_PIXEL_ASPECT_RATIO, unNumerator, unDenominator); > 558: else > 559: hr = S_OK; I fixed get/set MF_MT_PIXEL_ASPECT_RATIO and MF_MT_DEFAULT_STRIDE. We should only set it if we get it and it is ok if aspect ration or stride is not available. In way it is currently written we will overwrite value of hr if it is failed and never exit a loop as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From jvos at openjdk.java.net Sat Dec 11 06:56:14 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Dec 2021 06:56:14 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v4] In-Reply-To: References: Message-ID: <6Ag9yI9AxdNvga2rcukvaeQGlL5khVmkqV3X9FejRp4=.9c404483-f0b1-48bd-9140-560c8f41f7bb@github.com> On Fri, 10 Dec 2021 15:24:44 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276167: Avoid additional Toolkit.getToolkit().firePulse() > > Avoid using of additional Toolkit.getToolkit().firePulse() in the test, > adjust expected values instead. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Sat Dec 11 07:32:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Dec 2021 07:32:16 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:43:34 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove remaining references to old JUnit 4.8.2 > - Upgrade to JUnit 4.13.2 This looks good. I noticed that the fix for 8276142: Update gradle to version 7.3 was not in the branch for this PR, but merging it manually (which will be done when it is merged here) worked and did not cause issues. I'm running a few more tests, and will approve when they are all green. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jvos at openjdk.java.net Sat Dec 11 09:11:18 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Dec 2021 09:11:18 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:43:34 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove remaining references to old JUnit 4.8.2 > - Upgrade to JUnit 4.13.2 Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jvos at openjdk.java.net Sat Dec 11 09:14:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 11 Dec 2021 09:14:12 GMT Subject: RFR: 8273089: Deprecate JavaFX GTK 2 library for removal In-Reply-To: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> References: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> Message-ID: On Tue, 30 Nov 2021 13:26:30 GMT, Kevin Rushforth wrote: > This PR deprecates the JavaFX glass GTK 2 library for removal. Since there isn't an associated API, the mechanism for doing this is to print a "deprecated for removal" warning message when the `glassgtk2` library it is loaded. A message is printed regardless of why the GTK 2 library was loaded, which can happen for one of the following reasons: > > 1. The application or end user has explicitly requested GTK 2 using the `jdk.gtk.version` system property. > 2. Another native library has already loaded the GTK 2 library (an application cannot load both the GTK 2 and GTK 3 libraries in the same process) > 3. As a fallback if the gtk3 libraries are not available on the system. > > The warning messages are patterned after the security manager deprecation messages added as part of [JEP 411](https://openjdk.java.net/jeps/411). > > I added two system tests, one that sets the `jdk.gtk.version` system property to `2` and verifies that the warning message is printed, and one that doesn't set `jdk.gtk.version` and verifies that no warning message is printed. works as intended. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/685 From jhendrikx at openjdk.java.net Sat Dec 11 12:28:16 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 11 Dec 2021 12:28:16 GMT Subject: Integrated: 8274274: Update JUnit to version 5.8.1 In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:05:01 GMT, John Hendrikx wrote: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. This pull request has now been integrated. Changeset: ff6e8d50 Author: John Hendrikx Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ff6e8d50badd57549811391b1380707bb94ac55b Stats: 161 lines in 5 files changed: 151 ins; 3 del; 7 mod 8274274: Update JUnit to version 5.8.1 Reviewed-by: kcr, mstrauss, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From aghaisas at openjdk.java.net Mon Dec 13 06:14:10 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 13 Dec 2021 06:14:10 GMT Subject: RFR: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element [v4] In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 15:24:44 GMT, eduardsdv wrote: >> Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8276167: Avoid additional Toolkit.getToolkit().firePulse() > > Avoid using of additional Toolkit.getToolkit().firePulse() in the test, > adjust expected values instead. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From duke at openjdk.java.net Mon Dec 13 08:31:10 2021 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 13 Dec 2021 08:31:10 GMT Subject: Integrated: 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element In-Reply-To: References: Message-ID: <94sPod1-IQLYFuCGbV2l61xho7s66U-EM1D6XS8GeZk=.73e7fc79-3679-4aba-ad82-1a37dfbe2f2b@github.com> On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. This pull request has now been integrated. Changeset: 11583392 Author: Eduard Sedov Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/115833923a644be8328b8f7a7a6845e5b42a57b3 Stats: 42 lines in 4 files changed: 37 ins; 0 del; 5 mod 8276167: VirtualFlow.scrollToTop doesn't scroll to the top of the last element Reviewed-by: aghaisas, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/656 From jvos at openjdk.java.net Mon Dec 13 11:06:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Dec 2021 11:06:26 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used Message-ID: This PR provides at least some basic information when a pipeline can't be used. There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. ------------- Commit messages: - In case prism.verbose=true, this patch provide some basic information Changes: https://git.openjdk.java.net/jfx/pull/693/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=693&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278595 Stats: 14 lines in 2 files changed: 12 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/693.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/693/head:pull/693 PR: https://git.openjdk.java.net/jfx/pull/693 From kcr at openjdk.java.net Mon Dec 13 13:07:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Dec 2021 13:07:13 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 11:00:02 GMT, Johan Vos wrote: > This PR provides at least some basic information when a pipeline can't be used. > There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. > > The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. Looks fine. I left one minor comment about an extra blank line. You can fix it or not. I'll re-approve if you do. modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2Pipeline.java line 75: > 73: creator = Thread.currentThread(); > 74: > 75: Minor: extra blank line not needed. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/693 From duke at openjdk.java.net Mon Dec 13 15:51:11 2021 From: duke at openjdk.java.net (danielpeintner) Date: Mon, 13 Dec 2021 15:51:11 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 11:00:02 GMT, Johan Vos wrote: > This PR provides at least some basic information when a pipeline can't be used. > There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. > > The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. Note: I don't see what @dlemmermann posted but an _initial_ space seems to be missing "could not be initialized..." --> " could not be initialized..." ------------- PR: https://git.openjdk.java.net/jfx/pull/693 From jvos at openjdk.java.net Mon Dec 13 16:31:46 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Dec 2021 16:31:46 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used [v2] In-Reply-To: References: Message-ID: <4csElhZ4jfVPtK98LQmyGbV4ctRCloEcJx61yOeRHDg=.af762b7b-0e24-4204-bd34-46f7e5b40b5a@github.com> > This PR provides at least some basic information when a pipeline can't be used. > There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. > > The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Fix (minor) formatting issues. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/693/files - new: https://git.openjdk.java.net/jfx/pull/693/files/e3892b2e..fe0efa74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=693&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=693&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/693.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/693/head:pull/693 PR: https://git.openjdk.java.net/jfx/pull/693 From kcr at openjdk.java.net Mon Dec 13 16:46:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Dec 2021 16:46:11 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used [v2] In-Reply-To: <4csElhZ4jfVPtK98LQmyGbV4ctRCloEcJx61yOeRHDg=.af762b7b-0e24-4204-bd34-46f7e5b40b5a@github.com> References: <4csElhZ4jfVPtK98LQmyGbV4ctRCloEcJx61yOeRHDg=.af762b7b-0e24-4204-bd34-46f7e5b40b5a@github.com> Message-ID: On Mon, 13 Dec 2021 16:31:46 GMT, Johan Vos wrote: >> This PR provides at least some basic information when a pipeline can't be used. >> There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. >> >> The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Fix (minor) formatting issues. Marked as reviewed by kcr (Lead). modules/javafx.graphics/src/main/java/com/sun/prism/GraphicsPipeline.java line 239: > 237: if (PrismSettings.verbose) { > 238: System.err.println("GraphicsPipeline.createPipeline: error" + > 239: " initializing pipeline "+ className); Since you fixed one minor preexisting formatting issue with a missing space before the `+`, do you want to fix the one on the next line (239), too? ------------- PR: https://git.openjdk.java.net/jfx/pull/693 From jvos at openjdk.java.net Mon Dec 13 18:00:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Dec 2021 18:00:42 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used [v3] In-Reply-To: References: Message-ID: > This PR provides at least some basic information when a pipeline can't be used. > There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. > > The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: fix one more whitespace issue ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/693/files - new: https://git.openjdk.java.net/jfx/pull/693/files/fe0efa74..c779418b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=693&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=693&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/693.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/693/head:pull/693 PR: https://git.openjdk.java.net/jfx/pull/693 From kcr at openjdk.java.net Mon Dec 13 18:00:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Dec 2021 18:00:45 GMT Subject: RFR: 8278595: Provide more information when a pipeline can't be used [v3] In-Reply-To: References: Message-ID: <09Zq3e2zQdY9uCeOKFjQhhiJgcN9k2fBDInEFx2pNa8=.1675278b-aff7-4e5e-9914-12c26b8fc947@github.com> On Mon, 13 Dec 2021 17:57:21 GMT, Johan Vos wrote: >> This PR provides at least some basic information when a pipeline can't be used. >> There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. >> >> The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > fix one more whitespace issue Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/693 From jvos at openjdk.java.net Mon Dec 13 18:22:09 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 13 Dec 2021 18:22:09 GMT Subject: Integrated: 8278595: Provide more information when a pipeline can't be used In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 11:00:02 GMT, Johan Vos wrote: > This PR provides at least some basic information when a pipeline can't be used. > There are a number of reasons why a candidate pipeline can't be used, and this PR makes it clear at which point the pipeline fails. > > The changes are only applied in case `prism.verbose` is already set to `true`, so there is no unwanted logging. This pull request has now been integrated. Changeset: 1ad11b05 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/1ad11b05c8cbb5f42e29d25377f5737ec80537ee Stats: 15 lines in 2 files changed: 11 ins; 2 del; 2 mod 8278595: Provide more information when a pipeline can't be used Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/693 From kcr at openjdk.java.net Mon Dec 13 19:37:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Dec 2021 19:37:25 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v3] In-Reply-To: References: Message-ID: On Sat, 11 Dec 2021 05:24:40 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v4] Changes look fine with one question. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 698: > 696: { > 697: pMediaBuffer->Unlock(); > 698: gst_buffer_unref(pGstBuffer); // INLINE - gst_buffer_unref() Is it safe to call gst_buffer_unref with `NULL`? ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From duke at openjdk.java.net Mon Dec 13 19:40:47 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 13 Dec 2021 19:40:47 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4] In-Reply-To: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: > There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. > > In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. > > I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Learn-as-they-type approach to implementing getKeyCodeForChar ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/635/files - new: https://git.openjdk.java.net/jfx/pull/635/files/69d46c2e..80606863 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=02-03 Stats: 77 lines in 1 file changed: 77 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/635/head:pull/635 PR: https://git.openjdk.java.net/jfx/pull/635 From duke at openjdk.java.net Mon Dec 13 19:51:42 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 13 Dec 2021 19:51:42 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout Message-ID: The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: View.java GlassViewEventHandler.java TKSceneListener.java Scene.java The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. KeyCharacterCombination.java Toolkit.java QuantumToolkit.java Application.java GtkApplication.java The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. ------------- Commit messages: - New KeyCharacterCombination implementation Changes: https://git.openjdk.java.net/jfx/pull/694/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=694&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273743 Stats: 290 lines in 16 files changed: 243 ins; 10 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/694.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/694/head:pull/694 PR: https://git.openjdk.java.net/jfx/pull/694 From duke at openjdk.java.net Mon Dec 13 20:01:16 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 13 Dec 2021 20:01:16 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4] In-Reply-To: References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: <5awhtsAWrNOsZJf09soJt54Ytz-qH9HjO_BjSeDmIkI=.8273a720-cbbc-49a9-b1e4-20c0e4d93d06@github.com> On Mon, 13 Dec 2021 19:40:47 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. >> >> In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. >> >> I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case >> [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) >> . > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Learn-as-they-type approach to implementing getKeyCodeForChar I can map from a character to a key but I haven?t found any way of verifying that the key is actually on the user?s keyboard. I can?t even filter them out as keypad keys, their `XkbKeyTypeIndex` puts them in the same class as the Space bar. I?ve amended the PR to approach this the same way the Mac does. As the user types we query the key to determine which characters it can generate and stash them in a map. In `getKeyCodeForChar` we consult that map to answer the question. This means both the Mac and Linux would be using the same brute force hack to get around the limitations of `getKeyCodeForChar`. I think it?s time for it to go. I?ve entered an alternate PR #694 that paves the way for retiring that call and replacing it with one that?s much easier to get right on all platforms. I would prefer to close this PR and focus on that one. Life is short. ------------- PR: https://git.openjdk.java.net/jfx/pull/635 From almatvee at openjdk.java.net Tue Dec 14 07:27:50 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Dec 2021 07:27:50 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v5] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/cb1ee6c2..21dffaa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=02-03 Stats: 16 lines in 2 files changed: 4 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649 From almatvee at openjdk.java.net Tue Dec 14 17:37:06 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Dec 2021 17:37:06 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: <26u3-5wk49pxpfnrf7HRJJECrOGSIKLS326Gr-wxzXw=.366cb782-5f69-4b3e-8033-d6d6bde62ddd@github.com> References: <26u3-5wk49pxpfnrf7HRJJECrOGSIKLS326Gr-wxzXw=.366cb782-5f69-4b3e-8033-d6d6bde62ddd@github.com> Message-ID: On Fri, 10 Dec 2021 18:56:43 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v3] > > modules/javafx.media/src/main/native/gstreamer/plugins/av/videodecoder.c line 525: > >> 523: if (decoder->sws_context == NULL || decoder->dest_frame == NULL || >> 524: decoder->sws_scale_func == NULL) >> 525: return TRUE; > > Should this be `return FALSE;`? Not really. videodecoder_init_converter() should fail if we need converter, but did not able to initialize it. videodecoder_convert_frame() return TRUE here, since it assumes that it will never be called if we need converter and fail to initialize it. So, TRUE here means we do not need to convert frame. I modified this logic by checking base->frame->format value to make it clear. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From almatvee at openjdk.java.net Tue Dec 14 17:37:20 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 14 Dec 2021 17:37:20 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v3] In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 19:29:59 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v4] > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 698: > >> 696: { >> 697: pMediaBuffer->Unlock(); >> 698: gst_buffer_unref(pGstBuffer); // INLINE - gst_buffer_unref() > > Is it safe to call gst_buffer_unref with `NULL`? No, it is not safe. I fixed it. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Tue Dec 14 23:35:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Dec 2021 23:35:03 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox wrote: > The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. I see from your comment in PR #635 that you propose to withdraw that PR in favor of this one. Given that, why don't you change that one to "Draft" and we'll focus on this one. As a first pass, it does seem a reasonable approach. I do have a few high level questions: 1. What are the drawbacks of this approach? 2. I see that the new mechanism has a Linux implementation. Do you plan to propose this for the other platforms (particularly macOS)? It seems like you would need to in order to solve [JDK-8090275](https://bugs.openjdk.java.net/browse/JDK-8090275) 3. Would this PR help address any of the other in-flight PRs? (e.g., PR #672) presuming we eventually do this on all platforms)? 4. Can you add the manual test from PR #635 ? ------------- PR: https://git.openjdk.java.net/jfx/pull/694 From kcr at openjdk.java.net Wed Dec 15 00:30:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Dec 2021 00:30:31 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS Message-ID: Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. Here is a before / after size comparison. All sizes in KBytes: ### Linux | Native Library | Current | Stripped | | --------------- | --------- | -------- | | libavplugin-54.so | 52 | 48 | | libavplugin-56.so | 52 | 48 | | libavplugin-57.so | 52 | 48 | | libavplugin-ffmpeg-56.so | 52 | 48 | | libavplugin-ffmpeg-57.so | 52 | 48 | | libavplugin-ffmpeg-58.so | 52 | 48 | | libdecora_sse.so | 76 | 72 | | libfxplugins.so | 56 | 52 | | libglass.so | 16 | 12 | | libglassgtk2.so | 932 | 324 | | libglassgtk3.so | 932 | 324 | | libgstreamer-lite.so | 2,280 | 2,100 | | libjavafx_font.so | 20 | 16 | | libjavafx_font_freetype.so | 28 | 28 | | libjavafx_font_pango.so | 28 | 24 | | libjavafx_iio.so | 148 | 140 | | libjfxmedia.so | 2,048 | 516 | | libjfxwebkit.so | 106,696 | 88,428 | | libprism_common.so | 8 | 8 | | libprism_es2.so | 64 | 64 | | libprism_sw.so | 68 | 64 | ### macOS | Native Library | Current | Stripped | | --------------- | --------- | -------- | | libdecora_sse.dylib | 88 | 88 | | libfxplugins.dylib | 88 | 84 | | libglass.dylib | 360 | 324 | | libglib-lite.dylib | 1,192 | 1,148 | | libgstreamer-lite.dylib | 1,708 | 1584 | | libjavafx_font.dylib | 64 | 64 | | libjavafx_iio.dylib | 308 | 300 | | libjfxmedia.dylib | 212 | 200 | | libjfxmedia_avf.dylib | 100 | 88 | | libjfxwebkit.dylib | 85,896 | 71,636 | | libprism_common.dylib | 20 | 20 | | libprism_es2.dylib | 64 | 64 | | libprism_sw.dylib | 88 | 88 | ------------- Commit messages: - 8278260: JavaFX shared libraries not stripped on Linux or macOS Changes: https://git.openjdk.java.net/jfx/pull/695/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=695&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278260 Stats: 67 lines in 3 files changed: 64 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/695.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/695/head:pull/695 PR: https://git.openjdk.java.net/jfx/pull/695 From duke at openjdk.java.net Wed Dec 15 01:06:58 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 15 Dec 2021 01:06:58 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: References: Message-ID: On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox wrote: > The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. 1. No drawbacks that I can think of. With this approach the platform glass code will have enough information to recreate the original `getKeyCodeForChar` algorithm so it can at least maintain the existing behavior. This PR just gives it enough information to do better. For example, even in the absence of a `hardwareCode` the platform will be able to use the event's `KeyCode` to allow matching on keypad keys. 2. I've written and tested Windows and Mac implementations. They both address [JDK-8090275](https://bugs.openjdk.java.net/browse/JDK-8090275). The Mac implementation requires more testing and uses some code from PR #425. The Windows implementation is just a tweak on the existing code to enable the keypad. 3. I'm not sure what to say about #672. It boils down to how we want to deal with `KeyEvents` that are created using the API vs. a physical keystroke. I'll address that in a follow-up comment. 4. I'll add the test case modified to enable testing on the keypad. It might take a day or two, there's a few other tweaks that would be useful to have. ------------- PR: https://git.openjdk.java.net/jfx/pull/694 From jhendrikx at openjdk.java.net Wed Dec 15 11:36:23 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 15 Dec 2021 11:36:23 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v2] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Initial proposal ------------- Changes: https://git.openjdk.java.net/jfx/pull/675/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=01 Stats: 1501 lines in 11 files changed: 1498 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Wed Dec 15 11:43:36 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 15 Dec 2021 11:43:36 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Upgrade tests to JUnit 5 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/675/files - new: https://git.openjdk.java.net/jfx/pull/675/files/d9bfefe9..312fb506 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=01-02 Stats: 383 lines in 2 files changed: 7 ins; 369 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From jhendrikx at openjdk.java.net Wed Dec 15 11:43:40 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Wed, 15 Dec 2021 11:43:40 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v2] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 15 Dec 2021 11:36:23 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx 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 one additional commit since the last revision: > > Initial proposal I've rebased this PR on the current master to pull in the JUnit 5 upgrade, and I've updated the tests in this PR to use JUnit 5. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From johan.vos at gluonhq.com Wed Dec 15 14:16:14 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 15 Dec 2021 15:16:14 +0100 Subject: Monocle properties in glass and prism Message-ID: Hi, The separation between Glass and Prism is slightly broken by Monocle and that restricts the number of possible combinations. I wonder if there are any known cases where the glass platform is set to Monocle, but where prism is expected to use X11? That sounds like a contradiction, as Monocle is intended for platforms without a window manager, where X11 is afaik almost always bundled with a window manager. The confusing part is that if you want to use prism-es2 with (glass platform) monocle, you need to specify not only -Dglass.platform=Monocle but also -Dembedded=monocle (note the difference in upper/lowercase M/m) The latter is needed because of a check in GLFactory: if (PlatformUtil.isUnix()) { if ("monocle".equals(PlatformUtil.getEmbeddedType())) factoryClassName = "com.sun.prism.es2.MonocleGLFactory"; else factoryClassName = "com.sun.prism.es2.X11GLFactory"; } Hence, on Unix, we always go for the X11GLFactory, unless the system property "embedded" equals "monocle" -- regardless of what glass platform we are using. The PlatformUtil.getEmbeddedType() is used in 1 other place: in ES2Pipeline itself: if ("monocle".equals(eglType)) { isEglfb = true; libName = "prism_es2_monocle"; } I suggest we remove the "embedded" property and the PlatforumUtil.getEmbeddedType() method (note that this is unrelated to PlatformUtil.isEmbedded()), and that we replace the checks on the 2 places mentioned above with a check on glass.platform being monocle. The drawback of this is that it introduces a glass concept in prism. However, this is already happening, as the differences between the X11GLFactory and the MonocleGLFactory are related to querying window information. An alternative approach is to remove the MonocleGLFactory, and make the X11GLFactory slightly more generic so that it can be used with Monocle as well. That sounds a bit silly because of the "X11" in the name, but since this factory also works with WayLand, the name is misleading already. Thoughts? - Johan From kevin.rushforth at oracle.com Wed Dec 15 14:52:17 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Dec 2021 06:52:17 -0800 Subject: Monocle properties in glass and prism In-Reply-To: References: Message-ID: <1a73cd82-db3c-e3f6-e5ab-9ee0d68abf2a@oracle.com> > I wonder if there are any known cases where the glass platform is set to > Monocle, but where prism is expected to use X11? That sounds like a > contradiction Agreed that this seems like a mismatch. > I suggest we remove the "embedded" property and the > PlatforumUtil.getEmbeddedType() method (note that this is unrelated to > PlatformUtil.isEmbedded()), and that we replace the checks on the 2 places > mentioned above with a check on glass.platform being monocle. I think this seems fine. It does seem a little odd to query glass platform in Prism, but I don't see a problem with it as long as Prism doesn't call into glass directly, at least not during initialization (Prism is necessarily initialized before glass). -- Kevin On 12/15/2021 6:16 AM, Johan Vos wrote: > Hi, > > The separation between Glass and Prism is slightly broken by Monocle and > that restricts the number of possible combinations. > I wonder if there are any known cases where the glass platform is set to > Monocle, but where prism is expected to use X11? That sounds like a > contradiction, as Monocle is intended for platforms without a window > manager, where X11 is afaik almost always bundled with a window manager. > > The confusing part is that if you want to use prism-es2 with (glass > platform) monocle, you need to specify not only > -Dglass.platform=Monocle > but also > -Dembedded=monocle > (note the difference in upper/lowercase M/m) > > The latter is needed because of a check in GLFactory: > > if (PlatformUtil.isUnix()) { > if ("monocle".equals(PlatformUtil.getEmbeddedType())) > factoryClassName = "com.sun.prism.es2.MonocleGLFactory"; > else > factoryClassName = "com.sun.prism.es2.X11GLFactory"; > } > > Hence, on Unix, we always go for the X11GLFactory, unless the system > property "embedded" equals "monocle" -- regardless of what glass platform > we are using. > > The PlatformUtil.getEmbeddedType() is used in 1 other place: in > ES2Pipeline itself: > > if ("monocle".equals(eglType)) { > isEglfb = true; > libName = "prism_es2_monocle"; > } > > I suggest we remove the "embedded" property and the > PlatforumUtil.getEmbeddedType() method (note that this is unrelated to > PlatformUtil.isEmbedded()), and that we replace the checks on the 2 places > mentioned above with a check on glass.platform being monocle. > > The drawback of this is that it introduces a glass concept in prism. > However, this is already happening, as the differences between the > X11GLFactory and the MonocleGLFactory are related to querying window > information. > > An alternative approach is to remove the MonocleGLFactory, and make the > X11GLFactory slightly more generic so that it can be used with Monocle as > well. That sounds a bit silly because of the "X11" in the name, but since > this factory also works with WayLand, the name is misleading already. > > Thoughts? > > - Johan From johan.vos at gluonhq.com Wed Dec 15 16:04:51 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 15 Dec 2021 17:04:51 +0100 Subject: Monocle properties in glass and prism In-Reply-To: <1a73cd82-db3c-e3f6-e5ab-9ee0d68abf2a@oracle.com> References: <1a73cd82-db3c-e3f6-e5ab-9ee0d68abf2a@oracle.com> Message-ID: On Wed, Dec 15, 2021 at 3:53 PM Kevin Rushforth wrote: > > > I wonder if there are any known cases where the glass platform is set to > > Monocle, but where prism is expected to use X11? That sounds like a > > contradiction > > Agreed that this seems like a mismatch. > > > I suggest we remove the "embedded" property and the > > PlatforumUtil.getEmbeddedType() method (note that this is unrelated to > > PlatformUtil.isEmbedded()), and that we replace the checks on the 2 > places > > mentioned above with a check on glass.platform being monocle. > > I think this seems fine. It does seem a little odd to query glass > platform in Prism, but I don't see a problem with it as long as Prism > doesn't call into glass directly, at least not during initialization > (Prism is necessarily initialized before glass). Absolutely. There is no call needed into glass at all, it is just the name of the property that has the word "glass" in it. Looking deeper into the semantics, the "issue" is more the naming itself. For other platforms (e.g. Windows, iOS,...) we have checks both in glass and in prism on the OS name. That is a property that has nothing to do with either glass or prism. By using "-Dglass=monocle", we sort of give the (semantic) impression that monocle is related to glass, but it is also slightly related to prism. Short-term, I propose to create a JBS issue to change the check and remove the "-Dembedded=monocle" property. Longer term, I still believe a single ES2Pipeline and GLFactory might be the better approach. - Johan From kevin.rushforth at oracle.com Wed Dec 15 16:06:53 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Dec 2021 08:06:53 -0800 Subject: [External] : Re: Monocle properties in glass and prism In-Reply-To: References: <1a73cd82-db3c-e3f6-e5ab-9ee0d68abf2a@oracle.com> Message-ID: Sounds good. -- Kevin On 12/15/2021 8:04 AM, Johan Vos wrote: > > > On Wed, Dec 15, 2021 at 3:53 PM Kevin Rushforth > wrote: > > > > I wonder if there are any known cases where the glass platform > is set to > > Monocle, but where prism is expected to use X11? That sounds like a > > contradiction > > Agreed that this seems like a mismatch. > > > I suggest we remove the "embedded" property and the > > PlatforumUtil.getEmbeddedType() method (note that this is > unrelated to > > PlatformUtil.isEmbedded()), and that we replace the checks on > the 2 places > > mentioned above with a check on glass.platform being monocle. > > I think this seems fine. It does seem a little odd to query glass > platform in Prism, but I don't see a problem with it as long as Prism > doesn't call into glass directly, at least not during initialization > (Prism is necessarily initialized before glass). > > > Absolutely. There is no call needed into glass at all, it is just the > name of the property that has the word "glass" in it. > Looking deeper into the semantics, the "issue" is more the naming > itself. For other platforms (e.g. Windows, iOS,...) we have checks > both in glass and in prism on the OS name. That is a property that has > nothing to do with either glass or prism. > By using "-Dglass=monocle", we sort of give the (semantic) impression > that monocle is related to glass, but it is also slightly related to > prism. > > Short-term, I propose to create a JBS issue to change the check and > remove the "-Dembedded=monocle" property. Longer term, I still believe > a single ES2Pipeline and GLFactory might be the better approach. > > - Johan From jvos at openjdk.java.net Wed Dec 15 20:46:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Dec 2021 20:46:39 GMT Subject: RFR: 8278860: Streamline properties for Monocle Message-ID: Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. This PR replaces the property `embedded` with the property `glass.platform` . There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". ------------- Commit messages: - Base decisions in prism for embedded cases on the same glass.platform property Changes: https://git.openjdk.java.net/jfx/pull/696/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=696&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278860 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/696.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/696/head:pull/696 PR: https://git.openjdk.java.net/jfx/pull/696 From jvos at openjdk.java.net Wed Dec 15 21:26:03 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Dec 2021 21:26:03 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 00:25:08 GMT, Kevin Rushforth wrote: > Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. > > Here is a before / after size comparison. All sizes in KBytes: > > ### Linux > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libavplugin-54.so | 52 | 48 | > | libavplugin-56.so | 52 | 48 | > | libavplugin-57.so | 52 | 48 | > | libavplugin-ffmpeg-56.so | 52 | 48 | > | libavplugin-ffmpeg-57.so | 52 | 48 | > | libavplugin-ffmpeg-58.so | 52 | 48 | > | libdecora_sse.so | 76 | 72 | > | libfxplugins.so | 56 | 52 | > | libglass.so | 16 | 12 | > | libglassgtk2.so | 932 | 324 | > | libglassgtk3.so | 932 | 324 | > | libgstreamer-lite.so | 2,280 | 2,100 | > | libjavafx_font.so | 20 | 16 | > | libjavafx_font_freetype.so | 28 | 28 | > | libjavafx_font_pango.so | 28 | 24 | > | libjavafx_iio.so | 148 | 140 | > | libjfxmedia.so | 2,048 | 516 | > | libjfxwebkit.so | 106,696 | 88,428 | > | libprism_common.so | 8 | 8 | > | libprism_es2.so | 64 | 64 | > | libprism_sw.so | 68 | 64 | > > ### macOS > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libdecora_sse.dylib | 88 | 88 | > | libfxplugins.dylib | 88 | 84 | > | libglass.dylib | 360 | 324 | > | libglib-lite.dylib | 1,192 | 1,148 | > | libgstreamer-lite.dylib | 1,708 | 1584 | > | libjavafx_font.dylib | 64 | 64 | > | libjavafx_iio.dylib | 308 | 300 | > | libjfxmedia.dylib | 212 | 200 | > | libjfxmedia_avf.dylib | 100 | 88 | > | libjfxwebkit.dylib | 85,896 | 71,636 | > | libprism_common.dylib | 20 | 20 | > | libprism_es2.dylib | 64 | 64 | > | libprism_sw.dylib | 88 | 88 | This looks good and useful. I'll do builds and tests on Linux and Mac. The only question I have for now is if it would make sense to have a new configuration instead of binding this to DEBUG_NATIVE. The impact of building with DEBUG_NATIVE is very big. For most debugging and crash resolutions, DEBUG_NATIVE is not required, but symbols make it easier/faster to debug. But it's doable with stripped libs as well of course -- and I agree stripped libs should be the default for distributions. ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From duke at openjdk.java.net Wed Dec 15 21:34:10 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 15 Dec 2021 21:34:10 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: References: Message-ID: <2EpNJAj2zJpd4lcIznXCkPlP7gkBK1Pvig1ZosIBAnA=.69ce1b16-e1a8-4e1e-ab6f-ca826cc5e0b5@github.com> On Mon, 13 Dec 2021 19:46:27 GMT, Martin Fox wrote: > The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. I've decided that if this PR goes forward we should abandon #672. The changes in #672 would be bypassed for KeyEvents generated by physical keystrokes. For a while I thought it would be useful for handling KeyEvents created via the API but have decided against it. I've been going back and forth on how to handle synthetic events created using the KeyEvent constructor i.e. events that don't have a hardwareCode attached. One option is to just route them through the old `getKeyCodeForChar` machinery to maintain the current level of support. Unfortunately this varies widely, from mostly working on Windows to almost never working on Mac. If we just maintain what we've got I would ditch #672 since it would be fine-tuning a feature on Windows that's largely busted on other platforms. The other option is to dive in and make synthetic events work as well as possible on every platform. In this PR `getKeyCanGenerateCharacter` has a KeyCode in hand and can use the existing Robot code to map that to a physical key. It wouldn't be entirely reliable (particularly on Mac and Linux) but it would be easy and improve support for synthetic events enough to forestall bugs like [JDK-8087486](https://bugs.openjdk.java.net/browse/JDK-8087486). And it would be behavior I could write automated and manual tests for. I don't think synthetic events are all that useful for triggering KeyCharacterCombinations (you have to know the current keyboard layout to accurately target punctuation or symbols) but they exist and it's probably best to get them to a testable state. This means fixing the Robot code which has bugs on every platform but that was already on my to-do list and I've prototyped most of the code. I'll get the Robot bugs entered in the next few days. ------------- PR: https://git.openjdk.java.net/jfx/pull/694 From kcr at openjdk.java.net Wed Dec 15 22:14:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Dec 2021 22:14:59 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: References: Message-ID: <30GWEjLb2or50Vyr_vp4t5xdTyJCoFIyB_hQf4FrWGw=.b9d0dca7-4959-4882-b1af-ae94cf4c8312@github.com> On Wed, 15 Dec 2021 21:23:23 GMT, Johan Vos wrote: > The only question I have for now is if it would make sense to have a new configuration instead of binding this to DEBUG_NATIVE. I had initially thought of only stripping the binaries for production builds, e.g., when `-PCONF=Release` is specified. That seems preferable to creating a new configuration. What do you think? ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From kcr at openjdk.java.net Wed Dec 15 22:35:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Dec 2021 22:35:04 GMT Subject: Integrated: 8273089: Deprecate JavaFX GTK 2 library for removal In-Reply-To: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> References: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> Message-ID: On Tue, 30 Nov 2021 13:26:30 GMT, Kevin Rushforth wrote: > This PR deprecates the JavaFX glass GTK 2 library for removal. Since there isn't an associated API, the mechanism for doing this is to print a "deprecated for removal" warning message when the `glassgtk2` library it is loaded. A message is printed regardless of why the GTK 2 library was loaded, which can happen for one of the following reasons: > > 1. The application or end user has explicitly requested GTK 2 using the `jdk.gtk.version` system property. > 2. Another native library has already loaded the GTK 2 library (an application cannot load both the GTK 2 and GTK 3 libraries in the same process) > 3. As a fallback if the gtk3 libraries are not available on the system. > > The warning messages are patterned after the security manager deprecation messages added as part of [JEP 411](https://openjdk.java.net/jeps/411). > > I added two system tests, one that sets the `jdk.gtk.version` system property to `2` and verifies that the warning message is printed, and one that doesn't set `jdk.gtk.version` and verifies that no warning message is printed. This pull request has now been integrated. Changeset: 27f28102 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/27f281028fde507e5f0fe81247133816db7dc41d Stats: 221 lines in 4 files changed: 221 ins; 0 del; 0 mod 8273089: Deprecate JavaFX GTK 2 library for removal Reviewed-by: pbansal, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/685 From kcr at openjdk.java.net Wed Dec 15 22:57:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Dec 2021 22:57:26 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: References: Message-ID: > Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. > > Here is a before / after size comparison. All sizes in KBytes: > > ### Linux > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libavplugin-54.so | 52 | 48 | > | libavplugin-56.so | 52 | 48 | > | libavplugin-57.so | 52 | 48 | > | libavplugin-ffmpeg-56.so | 52 | 48 | > | libavplugin-ffmpeg-57.so | 52 | 48 | > | libavplugin-ffmpeg-58.so | 52 | 48 | > | libdecora_sse.so | 76 | 72 | > | libfxplugins.so | 56 | 52 | > | libglass.so | 16 | 12 | > | libglassgtk2.so | 932 | 324 | > | libglassgtk3.so | 932 | 324 | > | libgstreamer-lite.so | 2,280 | 2,100 | > | libjavafx_font.so | 20 | 16 | > | libjavafx_font_freetype.so | 28 | 28 | > | libjavafx_font_pango.so | 28 | 24 | > | libjavafx_iio.so | 148 | 140 | > | libjfxmedia.so | 2,048 | 516 | > | libjfxwebkit.so | 106,696 | 88,428 | > | libprism_common.so | 8 | 8 | > | libprism_es2.so | 64 | 64 | > | libprism_sw.so | 68 | 64 | > > ### macOS > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libdecora_sse.dylib | 88 | 88 | > | libfxplugins.dylib | 88 | 84 | > | libglass.dylib | 360 | 324 | > | libglib-lite.dylib | 1,192 | 1,148 | > | libgstreamer-lite.dylib | 1,708 | 1584 | > | libjavafx_font.dylib | 64 | 64 | > | libjavafx_iio.dylib | 308 | 300 | > | libjfxmedia.dylib | 212 | 200 | > | libjfxmedia_avf.dylib | 100 | 88 | > | libjfxwebkit.dylib | 85,896 | 71,636 | > | libprism_common.dylib | 20 | 20 | > | libprism_es2.dylib | 64 | 64 | > | libprism_sw.dylib | 88 | 88 | Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Only strip binaries when doing a production build (`-PCONF=Release`) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/695/files - new: https://git.openjdk.java.net/jfx/pull/695/files/1b48c942..3ab25740 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=695&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=695&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/695.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/695/head:pull/695 PR: https://git.openjdk.java.net/jfx/pull/695 From mstrauss at openjdk.java.net Thu Dec 16 00:21:06 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 16 Dec 2021 00:21:06 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:57:26 GMT, Kevin Rushforth wrote: >> Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. >> >> Here is a before / after size comparison. All sizes in KBytes: >> >> ### Linux >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libavplugin-54.so | 52 | 48 | >> | libavplugin-56.so | 52 | 48 | >> | libavplugin-57.so | 52 | 48 | >> | libavplugin-ffmpeg-56.so | 52 | 48 | >> | libavplugin-ffmpeg-57.so | 52 | 48 | >> | libavplugin-ffmpeg-58.so | 52 | 48 | >> | libdecora_sse.so | 76 | 72 | >> | libfxplugins.so | 56 | 52 | >> | libglass.so | 16 | 12 | >> | libglassgtk2.so | 932 | 324 | >> | libglassgtk3.so | 932 | 324 | >> | libgstreamer-lite.so | 2,280 | 2,100 | >> | libjavafx_font.so | 20 | 16 | >> | libjavafx_font_freetype.so | 28 | 28 | >> | libjavafx_font_pango.so | 28 | 24 | >> | libjavafx_iio.so | 148 | 140 | >> | libjfxmedia.so | 2,048 | 516 | >> | libjfxwebkit.so | 106,696 | 88,428 | >> | libprism_common.so | 8 | 8 | >> | libprism_es2.so | 64 | 64 | >> | libprism_sw.so | 68 | 64 | >> >> ### macOS >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libdecora_sse.dylib | 88 | 88 | >> | libfxplugins.dylib | 88 | 84 | >> | libglass.dylib | 360 | 324 | >> | libglib-lite.dylib | 1,192 | 1,148 | >> | libgstreamer-lite.dylib | 1,708 | 1584 | >> | libjavafx_font.dylib | 64 | 64 | >> | libjavafx_iio.dylib | 308 | 300 | >> | libjfxmedia.dylib | 212 | 200 | >> | libjfxmedia_avf.dylib | 100 | 88 | >> | libjfxwebkit.dylib | 85,896 | 71,636 | >> | libprism_common.dylib | 20 | 20 | >> | libprism_es2.dylib | 64 | 64 | >> | libprism_sw.dylib | 88 | 88 | > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Only strip binaries when doing a production build (`-PCONF=Release`) I don't think that stripping unused symbols is necessary for debug builds, and it's okay to only enable such optimizations for release builds. ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From mstrauss at openjdk.java.net Thu Dec 16 00:22:59 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 16 Dec 2021 00:22:59 GMT Subject: RFR: 8278860: Streamline properties for Monocle In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 20:39:54 GMT, Johan Vos wrote: > Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. > This PR replaces the property `embedded` with the property `glass.platform` . > > There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. > > There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java line 67: > 65: > 66: @SuppressWarnings("removal") > 67: String str2 = AccessController.doPrivileged((PrivilegedAction) () -> System.getProperty("glass.platform","").toLowerCase(Locale.ROOT)); Minor: maybe add a space after the comma ------------- PR: https://git.openjdk.java.net/jfx/pull/696 From mstrauss at openjdk.java.net Thu Dec 16 01:37:58 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 16 Dec 2021 01:37:58 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: References: Message-ID: <4ST6OrTvyKbREQ90Tt-MxGENZqzpjKXfnqlZcdEC4Gg=.8abba461-6c1f-4e2c-bb4a-2ce4852551c9@github.com> On Wed, 15 Dec 2021 22:57:26 GMT, Kevin Rushforth wrote: >> Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. >> >> Here is a before / after size comparison. All sizes in KBytes: >> >> ### Linux >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libavplugin-54.so | 52 | 48 | >> | libavplugin-56.so | 52 | 48 | >> | libavplugin-57.so | 52 | 48 | >> | libavplugin-ffmpeg-56.so | 52 | 48 | >> | libavplugin-ffmpeg-57.so | 52 | 48 | >> | libavplugin-ffmpeg-58.so | 52 | 48 | >> | libdecora_sse.so | 76 | 72 | >> | libfxplugins.so | 56 | 52 | >> | libglass.so | 16 | 12 | >> | libglassgtk2.so | 932 | 324 | >> | libglassgtk3.so | 932 | 324 | >> | libgstreamer-lite.so | 2,280 | 2,100 | >> | libjavafx_font.so | 20 | 16 | >> | libjavafx_font_freetype.so | 28 | 28 | >> | libjavafx_font_pango.so | 28 | 24 | >> | libjavafx_iio.so | 148 | 140 | >> | libjfxmedia.so | 2,048 | 516 | >> | libjfxwebkit.so | 106,696 | 88,428 | >> | libprism_common.so | 8 | 8 | >> | libprism_es2.so | 64 | 64 | >> | libprism_sw.so | 68 | 64 | >> >> ### macOS >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libdecora_sse.dylib | 88 | 88 | >> | libfxplugins.dylib | 88 | 84 | >> | libglass.dylib | 360 | 324 | >> | libglib-lite.dylib | 1,192 | 1,148 | >> | libgstreamer-lite.dylib | 1,708 | 1584 | >> | libjavafx_font.dylib | 64 | 64 | >> | libjavafx_iio.dylib | 308 | 300 | >> | libjfxmedia.dylib | 212 | 200 | >> | libjfxmedia_avf.dylib | 100 | 88 | >> | libjfxwebkit.dylib | 85,896 | 71,636 | >> | libprism_common.dylib | 20 | 20 | >> | libprism_es2.dylib | 64 | 64 | >> | libprism_sw.dylib | 88 | 88 | > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Only strip binaries when doing a production build (`-PCONF=Release`) Here are my results when building with `-PCONF=Release` on macOS 11.6.1: | Native Library | current | kevinrushforth | mstr2 | |-------------------------|---------|----------------|--------| | libdecora_sse.dylib | 88 | 88 | 87 | | libfxplugins.dylib | 88 | 84 | 83 | | libglass.dylib | 360 | 324 | 331 | | libglib-lite.dylib | 1,192 | 1,148 | 1,171 | | libgstreamer-lite.dylib | 1,708 | 1584 | 1,615 | | libjavafx_font.dylib | 64 | 64 | 64 | | libjavafx_iio.dylib | 308 | 300 | 306 | | libjfxmedia.dylib | 212 | 200 | 204 | | libjfxmedia_avf.dylib | 100 | 88 | 89 | | libjfxwebkit.dylib | 85,896 | 71,636 | 72,905 | | libprism_common.dylib | 20 | 20 | 16 | | libprism_es2.dylib | 64 | 64 | 61 | | libprism_sw.dylib | 88 | 88 | 87 | ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From duke at openjdk.java.net Thu Dec 16 03:26:55 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Thu, 16 Dec 2021 03:26:55 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Tue, 23 Nov 2021 17:40:29 GMT, Kevin Rushforth wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > I see that the `/contributor` command didn't work with the original contributor's GitHub username. You can instead take the contributor information from the HEAD commit of the pull request: `Naohiro Yoshimoto yosbits at gmail.com`. @kevinrushforth Is there something I can do to move this PR forward? ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From jvos at openjdk.java.net Thu Dec 16 07:30:03 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Dec 2021 07:30:03 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: <30GWEjLb2or50Vyr_vp4t5xdTyJCoFIyB_hQf4FrWGw=.b9d0dca7-4959-4882-b1af-ae94cf4c8312@github.com> References: <30GWEjLb2or50Vyr_vp4t5xdTyJCoFIyB_hQf4FrWGw=.b9d0dca7-4959-4882-b1af-ae94cf4c8312@github.com> Message-ID: On Wed, 15 Dec 2021 22:12:12 GMT, Kevin Rushforth wrote: > > The only question I have for now is if it would make sense to have a new configuration instead of binding this to DEBUG_NATIVE. > > I had initially thought of only stripping the binaries for production builds, e.g., when `-PCONF=Release` is specified. That seems preferable to creating a new configuration. What do you think? That sounds perfect indeed, and I see you committed that change already -- thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From aghaisas at openjdk.java.net Thu Dec 16 11:07:02 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 16 Dec 2021 11:07:02 GMT Subject: RFR: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 12:43:54 GMT, Jeanette Winzenburg wrote: > Extracted static test utility methods from EditAndScrollTest into new VirtualizedControlTestUtils, added rudimentary tests for the methods. This looks good except for a typo which is not introduced by you! modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualizedControlTestUtils.java line 86: > 84: > 85: /** > 86: * Returns a vertical ScrollBar of the control. I found this typo. I know, you just moved it from one file to another.. but, it would be good to fix in this PR :) Typo : This should be - "Returns a horizontal..." ------------- PR: https://git.openjdk.java.net/jfx/pull/690 From kcr at openjdk.java.net Thu Dec 16 12:05:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 12:05:05 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: <4ST6OrTvyKbREQ90Tt-MxGENZqzpjKXfnqlZcdEC4Gg=.8abba461-6c1f-4e2c-bb4a-2ce4852551c9@github.com> References: <4ST6OrTvyKbREQ90Tt-MxGENZqzpjKXfnqlZcdEC4Gg=.8abba461-6c1f-4e2c-bb4a-2ce4852551c9@github.com> Message-ID: On Thu, 16 Dec 2021 01:33:31 GMT, Michael Strau? wrote: > Here are my results when building with `-PCONF=Release` on macOS 11.6.1: My guess is that the differences are due to either your macOS version or the Xcode you used to build, and that your "current" numbers would also be different from mine. FWIW, mine were generated on macOS 10.15.7 using Xcode 12.4. ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From jvos at openjdk.java.net Thu Dec 16 12:19:57 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Dec 2021 12:19:57 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:57:26 GMT, Kevin Rushforth wrote: >> Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. >> >> Here is a before / after size comparison. All sizes in KBytes: >> >> ### Linux >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libavplugin-54.so | 52 | 48 | >> | libavplugin-56.so | 52 | 48 | >> | libavplugin-57.so | 52 | 48 | >> | libavplugin-ffmpeg-56.so | 52 | 48 | >> | libavplugin-ffmpeg-57.so | 52 | 48 | >> | libavplugin-ffmpeg-58.so | 52 | 48 | >> | libdecora_sse.so | 76 | 72 | >> | libfxplugins.so | 56 | 52 | >> | libglass.so | 16 | 12 | >> | libglassgtk2.so | 932 | 324 | >> | libglassgtk3.so | 932 | 324 | >> | libgstreamer-lite.so | 2,280 | 2,100 | >> | libjavafx_font.so | 20 | 16 | >> | libjavafx_font_freetype.so | 28 | 28 | >> | libjavafx_font_pango.so | 28 | 24 | >> | libjavafx_iio.so | 148 | 140 | >> | libjfxmedia.so | 2,048 | 516 | >> | libjfxwebkit.so | 106,696 | 88,428 | >> | libprism_common.so | 8 | 8 | >> | libprism_es2.so | 64 | 64 | >> | libprism_sw.so | 68 | 64 | >> >> ### macOS >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libdecora_sse.dylib | 88 | 88 | >> | libfxplugins.dylib | 88 | 84 | >> | libglass.dylib | 360 | 324 | >> | libglib-lite.dylib | 1,192 | 1,148 | >> | libgstreamer-lite.dylib | 1,708 | 1584 | >> | libjavafx_font.dylib | 64 | 64 | >> | libjavafx_iio.dylib | 308 | 300 | >> | libjfxmedia.dylib | 212 | 200 | >> | libjfxmedia_avf.dylib | 100 | 88 | >> | libjfxwebkit.dylib | 85,896 | 71,636 | >> | libprism_common.dylib | 20 | 20 | >> | libprism_es2.dylib | 64 | 64 | >> | libprism_sw.dylib | 88 | 88 | > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Only strip binaries when doing a production build (`-PCONF=Release`) Tested on Linux and Mac ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/695 From fastegal at openjdk.java.net Thu Dec 16 12:54:27 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Dec 2021 12:54:27 GMT Subject: RFR: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) [v2] In-Reply-To: References: Message-ID: > Extracted static test utility methods from EditAndScrollTest into new VirtualizedControlTestUtils, added rudimentary tests for the methods. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed c&p error in doc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/690/files - new: https://git.openjdk.java.net/jfx/pull/690/files/c2642bbe..1f2a9815 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=690&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=690&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/690.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/690/head:pull/690 PR: https://git.openjdk.java.net/jfx/pull/690 From fastegal at openjdk.java.net Thu Dec 16 12:54:31 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Dec 2021 12:54:31 GMT Subject: RFR: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) [v2] In-Reply-To: References: Message-ID: <6SsEB7QXxyEli4B0121Q2uCf0C9X_GEpnkpyLFX_yLQ=.9f7c0fa1-3003-49e4-bfd4-9b77d17ca149@github.com> On Thu, 16 Dec 2021 11:00:39 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed c&p error in doc > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/VirtualizedControlTestUtils.java line 86: > >> 84: >> 85: /** >> 86: * Returns a vertical ScrollBar of the control. > > I found this typo. I know, you just moved it from one file to another.. but, it would be good to fix in this PR :) > Typo : This should be - "Returns a horizontal..." actually, it was me who introduced it - in the previous PR ?? Thanks for spotting! ------------- PR: https://git.openjdk.java.net/jfx/pull/690 From aghaisas at openjdk.java.net Thu Dec 16 13:02:07 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 16 Dec 2021 13:02:07 GMT Subject: RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS [v2] In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:57:26 GMT, Kevin Rushforth wrote: >> Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. >> >> Here is a before / after size comparison. All sizes in KBytes: >> >> ### Linux >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libavplugin-54.so | 52 | 48 | >> | libavplugin-56.so | 52 | 48 | >> | libavplugin-57.so | 52 | 48 | >> | libavplugin-ffmpeg-56.so | 52 | 48 | >> | libavplugin-ffmpeg-57.so | 52 | 48 | >> | libavplugin-ffmpeg-58.so | 52 | 48 | >> | libdecora_sse.so | 76 | 72 | >> | libfxplugins.so | 56 | 52 | >> | libglass.so | 16 | 12 | >> | libglassgtk2.so | 932 | 324 | >> | libglassgtk3.so | 932 | 324 | >> | libgstreamer-lite.so | 2,280 | 2,100 | >> | libjavafx_font.so | 20 | 16 | >> | libjavafx_font_freetype.so | 28 | 28 | >> | libjavafx_font_pango.so | 28 | 24 | >> | libjavafx_iio.so | 148 | 140 | >> | libjfxmedia.so | 2,048 | 516 | >> | libjfxwebkit.so | 106,696 | 88,428 | >> | libprism_common.so | 8 | 8 | >> | libprism_es2.so | 64 | 64 | >> | libprism_sw.so | 68 | 64 | >> >> ### macOS >> >> | Native Library | Current | Stripped | >> | --------------- | --------- | -------- | >> | libdecora_sse.dylib | 88 | 88 | >> | libfxplugins.dylib | 88 | 84 | >> | libglass.dylib | 360 | 324 | >> | libglib-lite.dylib | 1,192 | 1,148 | >> | libgstreamer-lite.dylib | 1,708 | 1584 | >> | libjavafx_font.dylib | 64 | 64 | >> | libjavafx_iio.dylib | 308 | 300 | >> | libjfxmedia.dylib | 212 | 200 | >> | libjfxmedia_avf.dylib | 100 | 88 | >> | libjfxwebkit.dylib | 85,896 | 71,636 | >> | libprism_common.dylib | 20 | 20 | >> | libprism_es2.dylib | 64 | 64 | >> | libprism_sw.dylib | 88 | 88 | > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Only strip binaries when doing a production build (`-PCONF=Release`) Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From aghaisas at openjdk.java.net Thu Dec 16 13:05:05 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 16 Dec 2021 13:05:05 GMT Subject: RFR: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 12:54:27 GMT, Jeanette Winzenburg wrote: >> Extracted static test utility methods from EditAndScrollTest into new VirtualizedControlTestUtils, added rudimentary tests for the methods. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > fixed c&p error in doc Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/690 From kcr at openjdk.java.net Thu Dec 16 13:11:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 13:11:00 GMT Subject: Integrated: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 00:25:08 GMT, Kevin Rushforth wrote: > Build change to strip the non-global symbols from native shared libraries on Linux and macOS by running `strip -x`, unless doing a `-PCONF=DebugNative` build. > > Here is a before / after size comparison. All sizes in KBytes: > > ### Linux > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libavplugin-54.so | 52 | 48 | > | libavplugin-56.so | 52 | 48 | > | libavplugin-57.so | 52 | 48 | > | libavplugin-ffmpeg-56.so | 52 | 48 | > | libavplugin-ffmpeg-57.so | 52 | 48 | > | libavplugin-ffmpeg-58.so | 52 | 48 | > | libdecora_sse.so | 76 | 72 | > | libfxplugins.so | 56 | 52 | > | libglass.so | 16 | 12 | > | libglassgtk2.so | 932 | 324 | > | libglassgtk3.so | 932 | 324 | > | libgstreamer-lite.so | 2,280 | 2,100 | > | libjavafx_font.so | 20 | 16 | > | libjavafx_font_freetype.so | 28 | 28 | > | libjavafx_font_pango.so | 28 | 24 | > | libjavafx_iio.so | 148 | 140 | > | libjfxmedia.so | 2,048 | 516 | > | libjfxwebkit.so | 106,696 | 88,428 | > | libprism_common.so | 8 | 8 | > | libprism_es2.so | 64 | 64 | > | libprism_sw.so | 68 | 64 | > > ### macOS > > | Native Library | Current | Stripped | > | --------------- | --------- | -------- | > | libdecora_sse.dylib | 88 | 88 | > | libfxplugins.dylib | 88 | 84 | > | libglass.dylib | 360 | 324 | > | libglib-lite.dylib | 1,192 | 1,148 | > | libgstreamer-lite.dylib | 1,708 | 1584 | > | libjavafx_font.dylib | 64 | 64 | > | libjavafx_iio.dylib | 308 | 300 | > | libjfxmedia.dylib | 212 | 200 | > | libjfxmedia_avf.dylib | 100 | 88 | > | libjfxwebkit.dylib | 85,896 | 71,636 | > | libprism_common.dylib | 20 | 20 | > | libprism_es2.dylib | 64 | 64 | > | libprism_sw.dylib | 88 | 88 | This pull request has now been integrated. Changeset: 1ebf7a24 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1ebf7a24144b198e62b9b343821fdb155b9d703e Stats: 68 lines in 3 files changed: 65 ins; 0 del; 3 mod 8278260: JavaFX shared libraries not stripped on Linux or macOS Reviewed-by: jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/695 From kcr at openjdk.java.net Thu Dec 16 13:35:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 13:35:56 GMT Subject: RFR: 8278860: Streamline properties for Monocle In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 20:39:54 GMT, Johan Vos wrote: > Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. > This PR replaces the property `embedded` with the property `glass.platform` . > > There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. > > There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". Looks good. If you want to add the missing space I'll reapprove. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/696 From fastegal at openjdk.java.net Thu Dec 16 14:04:03 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 16 Dec 2021 14:04:03 GMT Subject: Integrated: 8278134: Move static utility methods to infrastructure (EditAndScrollTest) In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 12:43:54 GMT, Jeanette Winzenburg wrote: > Extracted static test utility methods from EditAndScrollTest into new VirtualizedControlTestUtils, added rudimentary tests for the methods. This pull request has now been integrated. Changeset: 002d4f57 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/002d4f5734b00c598f97a529c924e26c0451de9c Stats: 348 lines in 3 files changed: 290 ins; 57 del; 1 mod 8278134: Move static utility methods to infrastructure (EditAndScrollTest) Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/690 From fkirmaier at openjdk.java.net Thu Dec 16 14:35:13 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 16 Dec 2021 14:35:13 GMT Subject: RFR: 8278905 JavaFX: EnumConverter has a typo in the toString method Message-ID: Fixing typo in EnumConverter ------------- Commit messages: - 8278905 Changes: https://git.openjdk.java.net/jfx/pull/697/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278905 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/697.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/697/head:pull/697 PR: https://git.openjdk.java.net/jfx/pull/697 From kcr at openjdk.java.net Thu Dec 16 15:24:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 15:24:59 GMT Subject: RFR: 8278905 JavaFX: EnumConverter has a typo in the toString method In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 14:29:21 GMT, Florian Kirmaier wrote: > Fixing typo in EnumConverter Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/697 From perini.davide at dpsoftware.org Thu Dec 16 16:01:45 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Thu, 16 Dec 2021 17:01:45 +0100 Subject: Scene builder crash in IntelliJ 2021.3 and JDK 17.0.1 Message-ID: As title. Using IntelliJ 2021.3 and JDK 17.0.1 with JavaFX 17.0.1. As soon as I open an .fxml it ask me to install scene builder, I installed it and now Intellij crashes as soon as I open an fxml. Any idea? Thanks Davide From fkirmaier at openjdk.java.net Thu Dec 16 16:06:02 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 16 Dec 2021 16:06:02 GMT Subject: Integrated: 8278905 JavaFX: EnumConverter has a typo in the toString method In-Reply-To: References: Message-ID: <-gL_JyANgu5RhPqOp1HBvQGfPsxf-vyJ8PxLyXaKPBs=.86bdaa8e-1ab3-4d0e-92f8-38072f076a74@github.com> On Thu, 16 Dec 2021 14:29:21 GMT, Florian Kirmaier wrote: > Fixing typo in EnumConverter This pull request has now been integrated. Changeset: 4c5bf44e Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/4c5bf44e86dadf19bfd2acab65bb9caf46d3edbc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8278905: JavaFX: EnumConverter has a typo in the toString method Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/697 From duke at openjdk.java.net Thu Dec 16 20:39:34 2021 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 16 Dec 2021 20:39:34 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: Message-ID: > The algorithm in `KeyCharacterCombination.match` relies on the call `Toolkit.getKeyCodeForChar` which is difficult to implement correctly. It defies the way most keyboard API?s work and no platform has got it right yet. In particular the Mac and Linux implementations have to resort to a brute-force approach which monitors keystrokes to learn the relationship between keys and characters. > > This PR introduces an alternative mechanism which directly asks the platform whether a given key can generate a specific character. It also allows the platform to attach identifying key information to each KeyEvent to make it easier to answer the question (much, much easier). > > This is mostly dumb plumbing. On the front-end there?s a new call `View.notifyKeyEx` that takes an additional platform-specific `hardwareCode` parameter. It also returns a boolean indicating whether the event was consumed or not so I can fix JDK-8087863. If you want to follow the path visit the files in this order: > > View.java > GlassViewEventHandler.java > TKSceneListener.java > Scene.java > > The `KeyEvent` class has been expanded with an additional `hardwareCode` member that can only be accessed internally. See KeyEvent.java and KeyEventHelper.java. > > On the back-end `KeyCharacterCombination.match` calls a new routine `Toolkit.getKeyCanGenerateCharacter` which unpacks the `KeyEvent` information and sends it on to the Application. The default implementation falls back to the old `getKeyCodeForChar` call but platform specific Applications can send it on to the native glass code. > > KeyCharacterCombination.java > Toolkit.java > QuantumToolkit.java > Application.java > GtkApplication.java > > The glass code can use the `hardwareCode` to answer the question directly. It also has enough information to fall back on the old `getKeyCodeForChar` logic while also enabling the keypad (a common complaint is that Ctrl+?+? only works on the main keyboard and not the keypad, see JDK-8090275). > > This PR improves the situation for key events generated by keystrokes. Manually constructed key events won?t work any better or worse than they already do. Based on the bug database I don't think this is an issue. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Added manual test for KeyCharacterCombination matching ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/694/files - new: https://git.openjdk.java.net/jfx/pull/694/files/9c5dcbcb..7cb6c5bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=694&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=694&range=00-01 Stats: 160 lines in 1 file changed: 160 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/694.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/694/head:pull/694 PR: https://git.openjdk.java.net/jfx/pull/694 From duke at openjdk.java.net Thu Dec 16 21:14:04 2021 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 16 Dec 2021 21:14:04 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 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) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. I can't build this branch anymore, something related to compiling CCTaskGroovy. I think I need to merge or rebase to the latest version of master. Which is preferred, merge or rebase? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Thu Dec 16 21:14:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 21:14:04 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 21:08:49 GMT, Martin Fox wrote: > I can't build this branch anymore, something related to compiling CCTaskGroovy. I think I need to merge or rebase to the latest version of master. Which is preferred, merge or rebase? Merge, please. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Thu Dec 16 21:14:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 21:14:48 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v4] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. 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 8231601-contributing - Address review coments - Fixed URL to WEBKIT-MEDIA-STUBS.md - Address review comments - Address review comments + additional fixes - 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/9ee77cf7..1c41e9c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=02-03 Stats: 762084 lines in 11231 files changed: 387748 ins; 267778 del; 106558 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Thu Dec 16 21:17:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 21:17:59 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v3] In-Reply-To: References: Message-ID: <0o2KiwcIxDq5qyOPpHbAYaiswv2vRpQmgpuPO8M59wY=.aa27f375-cfe8-49ca-96f8-fe5a120742d2@github.com> On Fri, 18 Sep 2020 18:57:16 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review coments This has been dormant for a long time, so I just merged the latest master. I also discovered a couple additional changes I had in a "working" branch that I will push to address a couple minor comments. I still need to get back to this to address the comments from @nlisker about the flow, so that might take a bit more time, but I would like to get this moving to at least fix the fact that several things are wrong or misleading in the current doc. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Thu Dec 16 21:26:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 21:26:29 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v5] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Minor updates to address pending review comments that I did last year, but forgot to push ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/1c41e9c6..47f51a3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From duke at openjdk.java.net Thu Dec 16 21:40:47 2021 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 16 Dec 2021 21:40:47 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5] 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into macshortcut - Fixed whitespace error. - A small number of keyboard layouts require the Option key to reach critical letters like 'Q'. Added a third probe (after Command and Shift+Command) to look for letters that require Option. The keyboards in question are Azeri, Turkmen, and the Sami layouts. - 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. - Mac - generate KeyCodes that match user's active keyboard layout. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/425/files - new: https://git.openjdk.java.net/jfx/pull/425/files/fb449d93..1037be20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=03-04 Stats: 463524 lines in 8239 files changed: 260160 ins; 130671 del; 72693 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 perini.davide at dpsoftware.org Fri Dec 17 10:39:09 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 17 Dec 2021 11:39:09 +0100 Subject: Scene builder crash in IntelliJ 2021.3 and JDK 17.0.1 In-Reply-To: References: Message-ID: <6c4f5f09-4afd-ac93-b879-e6511b7d92d8@dpsoftware.org> PS: I have this problem on both Windows 11 and Linux Ubuntu 20.04. Il 16/12/2021 17:01, Davide Perini ha scritto: > As title. > > Using IntelliJ 2021.3 and JDK 17.0.1 with JavaFX 17.0.1. > > As soon as I open an .fxml it ask me to install scene builder, I > installed it and now Intellij crashes as soon as I open > an fxml. > > Any idea? > > Thanks > Davide From jvos at openjdk.java.net Fri Dec 17 12:24:35 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 12:24:35 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v5] In-Reply-To: References: Message-ID: <9b-SJxpgcrqewUfHNcEgwR5r8yvnKNFjNGgBEP-3y3o=.96de1632-bf9d-416a-8a2b-a9920f6c189b@github.com> On Thu, 16 Dec 2021 21:26:29 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates to address pending review comments that I did last year, but forgot to push CONTRIBUTING.md line 57: > 55: A developer with an active OpenJDK ID can file a bug directly in JBS. > 56: > 57: TIP: A GitHub pull request (PR) should not be the first time we hear about your proposed change to OpenJFX. Unless clearly identified as a Draft or work-in-progress (WIP), we will usually close a pull request that isn't associated with an existing bug report. Reading the policies below will help you in getting your change approved. forward reference to Draft or WIP, so maybe add (as explained later)? CONTRIBUTING.md line 179: > 177: with the environment variable `JAVA_HOME` referencing the path to Java home for > 178: your JDK installation. By default, tests use the same runtime as `JAVA_HOME`. > 179: Currently OpenJFX builds are running on JDK 11 through JDK 15. JDK 14 is recommended. JDK 17 ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From jvos at openjdk.java.net Fri Dec 17 12:30:32 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 12:30:32 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v5] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 21:26:29 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates to address pending review comments that I did last year, but forgot to push CONTRIBUTING.md line 252: > 250: > 251: TIP: a pull request is _not_ the starting point, since that skips the first two important steps and jumps right into > 252: "given this new feature, and an API definition that specifies it, please review my proposed implementation". I wonder if we should add something like "A PR is also not the end point, as code that is included in the repository should be maintained." I don't think that really belongs here, but it is a point I always check when reviewing a PR: what is the estimated maintenance for this PR? It might be better in the "Code Reviews" section on the OpenJFX wiki though. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 12:46:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 12:46:14 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v5] In-Reply-To: <9b-SJxpgcrqewUfHNcEgwR5r8yvnKNFjNGgBEP-3y3o=.96de1632-bf9d-416a-8a2b-a9920f6c189b@github.com> References: <9b-SJxpgcrqewUfHNcEgwR5r8yvnKNFjNGgBEP-3y3o=.96de1632-bf9d-416a-8a2b-a9920f6c189b@github.com> Message-ID: <6DB0ZkgwAZeyfkYUmBcmCDUyexYLoQetPBaEA1KLeFI=.8660dee9-1481-48a4-ad58-3ed63f363d83@github.com> On Fri, 17 Dec 2021 12:21:37 GMT, Johan Vos wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor updates to address pending review comments that I did last year, but forgot to push > > CONTRIBUTING.md line 57: > >> 55: A developer with an active OpenJDK ID can file a bug directly in JBS. >> 56: >> 57: TIP: A GitHub pull request (PR) should not be the first time we hear about your proposed change to OpenJFX. Unless clearly identified as a Draft or work-in-progress (WIP), we will usually close a pull request that isn't associated with an existing bug report. Reading the policies below will help you in getting your change approved. > > forward reference to Draft or WIP, so maybe add (as explained later)? Done. > CONTRIBUTING.md line 179: > >> 177: with the environment variable `JAVA_HOME` referencing the path to Java home for >> 178: your JDK installation. By default, tests use the same runtime as `JAVA_HOME`. >> 179: Currently OpenJFX builds are running on JDK 11 through JDK 15. JDK 14 is recommended. > > JDK 17 Done. > CONTRIBUTING.md line 252: > >> 250: >> 251: TIP: a pull request is _not_ the starting point, since that skips the first two important steps and jumps right into >> 252: "given this new feature, and an API definition that specifies it, please review my proposed implementation". > > I wonder if we should add something like "A PR is also not the end point, as code that is included in the repository should be maintained." I don't think that really belongs here, but it is a point I always check when reviewing a PR: what is the estimated maintenance for this PR? It might be better in the "Code Reviews" section on the OpenJFX wiki though. This is a good idea, and is part of what we mean when asking contributors of features to think about "stewardship". So I think adding it either here or in the code review section of the Wiki is good. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 12:46:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 12:46:07 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v6] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: More review comments 1. Renamed "Contributing to...codebase" section to "Coding style and testing guidelines", and switched that section with the "New features section" 2. Updated recommend JDK 3. Added forward reference for Draft and WIP PRs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/47f51a3c..9d3820a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=04-05 Stats: 85 lines in 1 file changed: 40 ins; 38 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 12:59:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 12:59:27 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v6] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 12:46:07 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > More review comments > > 1. Renamed "Contributing to...codebase" section to "Coding style and testing guidelines", and switched that section with the "New features section" > 2. Updated recommend JDK > 3. Added forward reference for Draft and WIP PRs CONTRIBUTING.md line 176: > 174: > 175: Adding a new feature to OpenJFX requires us to consider what it means to support that API forever; we take compatibility seriously. > 176: The main idea is to think in terms of "stewardship" when evolving the JavaFX API. This will require significant effort on your part. @johanvos to address your point about maintenance, what do you think about adding a sentence here? Something like: This will require significant effort on your part. __It begins before you submit a pull request for review, and continues after the new feature is integrated.__ We can follow this up with more detail in the code review guidelines. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From jvos at openjdk.java.net Fri Dec 17 13:09:23 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 13:09:23 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v6] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 12:56:40 GMT, Kevin Rushforth wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> More review comments >> >> 1. Renamed "Contributing to...codebase" section to "Coding style and testing guidelines", and switched that section with the "New features section" >> 2. Updated recommend JDK >> 3. Added forward reference for Draft and WIP PRs > > CONTRIBUTING.md line 176: > >> 174: >> 175: Adding a new feature to OpenJFX requires us to consider what it means to support that API forever; we take compatibility seriously. >> 176: The main idea is to think in terms of "stewardship" when evolving the JavaFX API. This will require significant effort on your part. > > @johanvos to address your point about maintenance, what do you think about adding a sentence here? Something like: > > This will require significant effort on your part. __It begins before you submit a pull request for review, and continues after the new feature is integrated.__ > > We can follow this up with more detail in the code review guidelines. That's a good sentence. It clearly and concisely tells what it is expected. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 13:14:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 13:14:16 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v7] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address more review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/9d3820a0..200e2f32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 13:33:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 13:33:57 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Minor updates ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/200e2f32..b135ee62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=06-07 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From jvos at openjdk.java.net Fri Dec 17 13:46:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 13:46:26 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: <6dkYKE5-6SjBu3jNR6IPxEQRlh49l2S3cTcaTRbSwz8=.6875ca1c-3067-49a3-9460-c2e51b0a4809@github.com> On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates This PR is a major improvement over the existing status. I therefore recommend to integrate this, and have other issues being discussed in follow-up issues. A contributing guideline document is a moving target. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 13:51:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 13:51:22 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: <6dkYKE5-6SjBu3jNR6IPxEQRlh49l2S3cTcaTRbSwz8=.6875ca1c-3067-49a3-9460-c2e51b0a4809@github.com> References: <6dkYKE5-6SjBu3jNR6IPxEQRlh49l2S3cTcaTRbSwz8=.6875ca1c-3067-49a3-9460-c2e51b0a4809@github.com> Message-ID: On Fri, 17 Dec 2021 13:43:43 GMT, Johan Vos wrote: > I therefore recommend to integrate this, and have other issues being discussed in follow-up issues Agreed. I think I've addressed all comments made in this PR. @aghaisas @arapte @nlisker can one of you be the second reviewer? ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From jvos at openjdk.java.net Fri Dec 17 13:57:58 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 13:57:58 GMT Subject: RFR: 8278860: Streamline properties for Monocle [v2] In-Reply-To: References: Message-ID: > Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. > This PR replaces the property `embedded` with the property `glass.platform` . > > There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. > > There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add space after comma ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/696/files - new: https://git.openjdk.java.net/jfx/pull/696/files/00146dd1..a0af3c6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=696&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=696&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/696.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/696/head:pull/696 PR: https://git.openjdk.java.net/jfx/pull/696 From kcr at openjdk.java.net Fri Dec 17 13:58:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 13:58:02 GMT Subject: RFR: 8278860: Streamline properties for Monocle [v2] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:54:10 GMT, Johan Vos wrote: >> Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. >> This PR replaces the property `embedded` with the property `glass.platform` . >> >> There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. >> >> There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add space after comma Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/696 From jvos at openjdk.java.net Fri Dec 17 13:58:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 13:58:06 GMT Subject: RFR: 8278860: Streamline properties for Monocle [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 00:20:06 GMT, Michael Strau? wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add space after comma > > modules/javafx.base/src/main/java/com/sun/javafx/PlatformUtil.java line 67: > >> 65: >> 66: @SuppressWarnings("removal") >> 67: String str2 = AccessController.doPrivileged((PrivilegedAction) () -> System.getProperty("glass.platform","").toLowerCase(Locale.ROOT)); > > Minor: maybe add a space after the comma done ------------- PR: https://git.openjdk.java.net/jfx/pull/696 From nlisker at openjdk.java.net Fri Dec 17 14:05:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Dec 2021 14:05:27 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates I will review this shortly. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From mstrauss at openjdk.java.net Fri Dec 17 14:11:28 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 17 Dec 2021 14:11:28 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates CONTRIBUTING.md line 18: > 16: ---------------- > 17: > 18: If you find yourself wishing for a feature that doesn't exist in OpenJFX, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that OpenJFX has today have been added because our users saw the need. I think you should restore this sentence. It feels uplifting and encouraging, while the other added sections feel pretty discouraging at first sight for newcomers to the project. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From jvos at openjdk.java.net Fri Dec 17 14:26:27 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 14:26:27 GMT Subject: Integrated: 8278860: Streamline properties for Monocle In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 20:39:54 GMT, Johan Vos wrote: > Base decisions in prism for embedded cases on the same glass.platform property that is also used in glass. > This PR replaces the property `embedded` with the property `glass.platform` . > > There is only 1 place where the property `embedded` was read, which is in the PlatformUtil.java. > > There are only 2 places where the value of that property is used, and in both cases the only check is to detect whether or not that property has a value of "monocle". This pull request has now been integrated. Changeset: 5422a5af Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/5422a5af7df14fe01971980f2b00a107a962d1ab Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8278860: Streamline properties for Monocle Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/696 From nlisker at openjdk.java.net Fri Dec 17 14:27:31 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Dec 2021 14:27:31 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates I added 1 suggestion. CONTRIBUTING.md line 204: > 202: section of the Code Review Policies doc, we also need a [CSR](https://wiki.openjdk.java.net/display/csr/Main), which documents the API change and its approval. > 203: The CSR can be reviewed in parallel. Changes in the API that arise during the review need to be reflected in the CSR, meaning > 204: that the final review / approval of the CSR usually happens late in the review cycle. I would advise contributors to not deal with the CSR until the review is almost done. It just duplicates the places that you need to update. I'm saying this from personal experience :) ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/303 From nlisker at openjdk.java.net Fri Dec 17 14:27:32 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Dec 2021 14:27:32 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:08:23 GMT, Michael Strau? wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor updates > > CONTRIBUTING.md line 18: > >> 16: ---------------- >> 17: >> 18: If you find yourself wishing for a feature that doesn't exist in OpenJFX, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that OpenJFX has today have been added because our users saw the need. > > I think you should restore this sentence. It feels uplifting and encouraging, while the other added sections feel pretty discouraging at first sight for newcomers to the project. Fair point. I don't mind restoring it. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 15:02:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 15:02:27 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:24:01 GMT, Nir Lisker wrote: >> CONTRIBUTING.md line 18: >> >>> 16: ---------------- >>> 17: >>> 18: If you find yourself wishing for a feature that doesn't exist in OpenJFX, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that OpenJFX has today have been added because our users saw the need. >> >> I think you should restore this sentence. It feels uplifting and encouraging, while the other added sections feel pretty discouraging at first sight for newcomers to the project. > > Fair point. I don't mind restoring it. OK, I can add this back, although I might reword it slightly. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 15:02:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 15:02:28 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v8] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 14:15:32 GMT, Nir Lisker wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor updates > > CONTRIBUTING.md line 204: > >> 202: section of the Code Review Policies doc, we also need a [CSR](https://wiki.openjdk.java.net/display/csr/Main), which documents the API change and its approval. >> 203: The CSR can be reviewed in parallel. Changes in the API that arise during the review need to be reflected in the CSR, meaning >> 204: that the final review / approval of the CSR usually happens late in the review cycle. > > I would advise contributors to not deal with the CSR until the review is almost done. It just duplicates the places that you need to update. I'm saying this from personal experience :) Good idea. ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 15:18:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 15:18:51 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v9] In-Reply-To: References: Message-ID: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/303/files - new: https://git.openjdk.java.net/jfx/pull/303/files/b135ee62..5bd52041 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=303&range=07-08 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/303.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303 PR: https://git.openjdk.java.net/jfx/pull/303 From nlisker at openjdk.java.net Fri Dec 17 15:26:34 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 17 Dec 2021 15:26:34 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v9] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 15:18:51 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From mstrauss at openjdk.java.net Fri Dec 17 16:35:23 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 17 Dec 2021 16:35:23 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v9] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 15:18:51 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Fri Dec 17 17:26:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 17:26:25 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 07:27:50 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v5] Latest code changes look good with one question (in two places). @johanvos @tiainen Can one of you be the second reviewer? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 646: > 644: > 645: if (SUCCEEDED(hr) && dwFlags != MFT_OUTPUT_STATUS_SAMPLE_READY) > 646: return FALSE; If the previous call failed, should you really continue with the following call to `ProcessOutput`? modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 760: > 758: > 759: HRESULT hr = decoder->pDecoder->GetOutputStatus(&dwFlags); > 760: if (SUCCEEDED(hr) && dwFlags != MFT_OUTPUT_STATUS_SAMPLE_READY) If the previous call failed, should you really continue with the following call to `ProcessOutput`? ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Fri Dec 17 17:26:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 17:26:26 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: <9bNXTPVLTrm4KVFEK3W2u98FXM3Go0moOKycL3a-jCo=.c220e268-28a3-4b5e-8d15-061353f3eafe@github.com> On Sat, 11 Dec 2021 03:20:54 GMT, Alexander Matveev wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v3] > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 559: > >> 557: hr = MFSetAttributeRatio(pInputType, MF_MT_PIXEL_ASPECT_RATIO, unNumerator, unDenominator); >> 558: else >> 559: hr = S_OK; > > I fixed get/set MF_MT_PIXEL_ASPECT_RATIO and MF_MT_DEFAULT_STRIDE. We should only set it if we get it and it is ok if aspect ration or stride is not available. In way it is currently written we will overwrite value of hr if it is failed and never exit a loop as well. ok ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From jvos at openjdk.java.net Fri Dec 17 17:57:28 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 17:57:28 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 07:27:50 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v5] We're building it now, and will do additional tests once building works fine (we might need a small change in the CI due to the additional Linux dependency) ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From duke at openjdk.java.net Fri Dec 17 18:29:22 2021 From: duke at openjdk.java.net (Martin Fox) Date: Fri, 17 Dec 2021 18:29:22 GMT Subject: RFR: DRAFT 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 20:13:11 GMT, Martin Fox wrote: > The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable punctuation and symbols in ways which vary across layouts and even keyboards. To determine the correct Java key code you have to query the layout to determine the character the key would generate without modifiers and map that character to the key code. `ViewContainer::HandleViewKeyEvent` did this, `getKeyCodeForChar` did not. This PR copies a few snippets of code from `ViewContainer::HandleViewKeyEvent` to make the two algorithms match. Marking this as DRAFT since this code could be superseded by #694. The review cycles weren't wasted since similar code will re-appear in the PR for [JDK-8278938](https://bugs.openjdk.java.net/browse/JDK-8278938) which fixes the way the Robot code resolves JavaFX KeyCodes. (And I was wrong when I wrote that `MapVirtualKeyEx` doesn't inform me of dead keys. I must have fumbled my testing. Mea culpa.) ------------- PR: https://git.openjdk.java.net/jfx/pull/672 From duke at openjdk.java.net Fri Dec 17 18:36:22 2021 From: duke at openjdk.java.net (Martin Fox) Date: Fri, 17 Dec 2021 18:36:22 GMT Subject: RFR: DRAFT 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v4] In-Reply-To: References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: On Mon, 13 Dec 2021 19:40:47 GMT, Martin Fox wrote: >> There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. >> >> In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. >> >> I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case >> [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) >> . > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Learn-as-they-type approach to implementing getKeyCodeForChar I marked this as draft in hopes that #694 goes through instead. The review cycles were useful as very similar code is in #694 and will be needed to address [JDK-8278924](https://bugs.openjdk.java.net/browse/JDK-8278924). ------------- PR: https://git.openjdk.java.net/jfx/pull/635 From kcr at openjdk.java.net Fri Dec 17 20:46:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 20:46:26 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 26 Nov 2021 19:49:37 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Update ROW_COUNT to 700_000 The fix looks good to me. I did leave a couple questions about the implementation. The new manual tests need a copyright header, and I noted a few of the code formatting issues. modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 877: > 875: if (size >= 0) { > 876: return size; > 877: } Using lazy evaluation means that you need to be extra careful that the size is invalidated in all the right places. One method that needs to be checked is the `set(int index, int... indices)` method. How carefully have you checked to make sure that nothing that could change the size fails to update the `size` field? Related to this, are you satisfied that the current set of unit tests are sufficient to catch any potential problems, and that you don't need to add more tests? modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 880: > 878: @Override public int indexOf(Object obj) { > 879: reset(); > 880: return super.indexOf(obj); So `reset` doesn't need to still be called? tests/manual/controls/SelectListViewTest.java line 1: > 1: import javafx.application.Application; This needs a copyright header. tests/manual/controls/SelectListViewTest.java line 24: > 22: > 23: ObservableList items = listView.getItems(); > 24: for(int i=0; i 45: stage.setScene(new Scene(root, 600, 600)); > 46: > 47: selectAll.setOnAction((e)->selectAll(listView)); Minor: add space before and after the `->` operator. tests/manual/controls/SelectListViewTest.java line 66: > 64: long t = System.currentTimeMillis(); > 65: listView.getSelectionModel().clearSelection(); > 66: System.out.println("time:"+ (System.currentTimeMillis() - t)); MInor: space before the `+` here and a few places below. tests/manual/controls/SelectTableViewTest.java line 1: > 1: import javafx.application.Application; This needs a copyright header. tests/manual/controls/SelectTableViewTest.java line 28: > 26: > 27: final ObservableList> columns = tableView.getColumns(); > 28: for(int i=0; i 35: > 36: ObservableList items = tableView.getItems(); > 37: for(int i=0; i 37: for(int i=0; i 38: String[] rec = new String[COL_COUNT]; > 39: for(int j=0; j References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: <-68p8_i0rJwuIzuxXMBgmiyS9286uB6HlUp0hVdln0M=.dc5e1db9-a123-4c20-9bf1-2e132a4b70b2@github.com> On Wed, 24 Nov 2021 14:39:57 GMT, yosbits wrote: >> But why? The initialization block of a `for` statement is exactly where you'd put loop-scoped variables. > > This change significantly improves performance because the BitSet's size () method is an O (N) implementation. You may be wondering because it is O (1) in many other collections. This change looks fine to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From jvos at openjdk.java.net Fri Dec 17 21:16:30 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 17 Dec 2021 21:16:30 GMT Subject: RFR: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes [v9] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 15:18:51 GMT, Kevin Rushforth wrote: >> This PR updates the `CONTRIBUTING.md` guide to address the following: >> >> 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. >> 2. Add a link to the mailing list in the section regarding contributing bug fixes. >> 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this >> 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. >> 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate >> 6. Update the note regarding which JDK(s) to use. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From almatvee at openjdk.java.net Fri Dec 17 21:17:31 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 17 Dec 2021 21:17:31 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 17:15:22 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v5] > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 646: > >> 644: >> 645: if (SUCCEEDED(hr) && dwFlags != MFT_OUTPUT_STATUS_SAMPLE_READY) >> 646: return FALSE; > > If the previous call failed, should you really continue with the following call to `ProcessOutput`? Yes, if call GetOutputStatus() fails we need to call ProcessOutput(). It is based on documentation. See https://docs.microsoft.com/en-us/windows/win32/medfound/basic-mft-processing-model#process-data ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Fri Dec 17 22:18:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 22:18:26 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 26 Nov 2021 19:49:37 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Update ROW_COUNT to 700_000 Thanks for adding the manual test. I can confirm the performance gains. I ran the ListView test, clicked on one of the cells visible without scrolling, then pressed the "select to the end" operation. With the 70k cells defined by the test program that operation ran 13,715 times faster on my machine with this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Sat Dec 18 00:12:32 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 00:12:32 GMT Subject: Integrated: 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 17:16:38 GMT, Kevin Rushforth wrote: > This PR updates the `CONTRIBUTING.md` guide to address the following: > > 1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step. > 2. Add a link to the mailing list in the section regarding contributing bug fixes. > 3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this > 4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated. > 5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate > 6. Update the note regarding which JDK(s) to use. This pull request has now been integrated. Changeset: 18063ade Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/18063ade22defdf55ec1b2083a5b296422ed05f4 Stats: 104 lines in 1 file changed: 43 ins; 13 del; 48 mod 8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes Reviewed-by: nlisker, jvos, mstrauss ------------- PR: https://git.openjdk.java.net/jfx/pull/303 From kcr at openjdk.java.net Sat Dec 18 00:14:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 00:14:26 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: <3pm2RlwBTpsgKcCRLkVIokcdPlRC5u2IL-jlCM2Jc2k=.360ffaaa-c1b4-4290-b666-ca63942b818f@github.com> On Tue, 14 Dec 2021 07:27:50 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v5] Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Sat Dec 18 00:17:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 00:17:25 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: <2EpNJAj2zJpd4lcIznXCkPlP7gkBK1Pvig1ZosIBAnA=.69ce1b16-e1a8-4e1e-ab6f-ca826cc5e0b5@github.com> References: <2EpNJAj2zJpd4lcIznXCkPlP7gkBK1Pvig1ZosIBAnA=.69ce1b16-e1a8-4e1e-ab6f-ca826cc5e0b5@github.com> Message-ID: On Wed, 15 Dec 2021 21:30:41 GMT, Martin Fox wrote: > I've decided that if this PR goes forward we should abandon #672. The changes in #672 would be bypassed for KeyEvents generated by physical keystrokes. For a while I thought it would be useful for handling KeyEvents created via the API but have decided against it. OK, I'll focus on this one then, along with #425. ------------- PR: https://git.openjdk.java.net/jfx/pull/694 From nlisker at openjdk.java.net Sat Dec 18 15:31:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 15:31:27 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> Message-ID: On Tue, 7 Dec 2021 16:22:25 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DirectionalLightHelper.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > 2021 Can the script do all these corrections? ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Sat Dec 18 15:45:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 15:45:10 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> Message-ID: <8UHsTyngxLUE4WBabfiFK55xwGpJaB0Vu1TMcxac8Fg=.9e4e0c3d-0d13-4f11-a035-d339b9b191dd@github.com> On Sat, 18 Dec 2021 15:28:48 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DirectionalLightHelper.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. >> >> 2021 > > Can the script do all these corrections? For existing files, yes. For this file (along with `NGDirectionalLight` and `DirectionalLight`), we will end up with `2020, 2021,` after running the script. Not a big deal, but since you have to make other changes anyway to fix the typos you might as well fix this, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Dec 18 15:45:07 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 15:45:07 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v3] In-Reply-To: References: Message-ID: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixes for review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/548/files - new: https://git.openjdk.java.net/jfx/pull/548/files/adcf1fce..e95db983 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=01-02 Stats: 8 lines in 4 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Dec 18 15:48:06 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 15:48:06 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v4] In-Reply-To: References: Message-ID: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Updated copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/548/files - new: https://git.openjdk.java.net/jfx/pull/548/files/e95db983..452e5672 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Dec 18 16:03:22 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 16:03:22 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> Message-ID: On Tue, 7 Dec 2021 16:38:03 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 106: > >> 104: >> 105: void computeLight(float i, float3 n, float3 refl, float specPower, float3 L, float3 lightDir, in out float3 d, in out float3 s) { >> 106: if (gLightAttenuation[i].w < 0.5) { > > Is there any performance difference between `< 0.5` and `!= 0` ? I suspect not, but in any case, you might consider the latter (as I also mentioned in the java files). The latter is more clear, so if you choose to stick with what you have, I'd like to see a comment added. Initially I went with the equality test, but it did not work well, probably since we are comparing floating points. This just seemed safer. If you want to try the equality test on you machine(s) it would be interesting, but I don't know if I would trust it. Same with the ES shaders. On the Java side I would trust it, but at this point it's a matter of consistency. I suspect that this also messed up with the computation approaches of spot light that check `falloff != 0` where we should be checking with a small delta: `abs(falloff) < EPSILON` instead. Performance should be revisited anyway I think at a later stage after the emissive color is added (where we need to figure out splitting shaders, which also has to do with the removal of the 3 lights restriction). ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Sat Dec 18 16:15:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 16:15:27 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> Message-ID: <2EHDfnTcy0dTbtkTbmz1XWAGwuine_3Ht1u9RbRmKXI=.7a661543-410f-4152-88e0-d58450a0ccbb@github.com> On Sat, 18 Dec 2021 16:00:24 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 106: >> >>> 104: >>> 105: void computeLight(float i, float3 n, float3 refl, float specPower, float3 L, float3 lightDir, in out float3 d, in out float3 s) { >>> 106: if (gLightAttenuation[i].w < 0.5) { >> >> Is there any performance difference between `< 0.5` and `!= 0` ? I suspect not, but in any case, you might consider the latter (as I also mentioned in the java files). The latter is more clear, so if you choose to stick with what you have, I'd like to see a comment added. > > Initially I went with the equality test, but it did not work well, probably since we are comparing floating points. This just seemed safer. If you want to try the equality test on you machine(s) it would be interesting, but I don't know if I would trust it. Same with the ES shaders. On the Java side I would trust it, but at this point it's a matter of consistency. > > I suspect that this also messed up with the computation approaches of spot light that check `falloff != 0` where we should be checking with a small delta: `abs(falloff) < EPSILON` instead. > Performance should be revisited anyway I think at a later stage after the emissive color is added (where we need to figure out splitting shaders, which also has to do with the removal of the 3 lights restriction). It seems safer then to either leave it the way you have it (in which case, please a comment), or change it to `abs(gLightAttenuation[i].w) < EPSILON` both here and in the Java code (for consistency). I'll leave it up to you. For spot light, you might want to file a new bug to address the `falloff != 0` problem. I agree about deferring the performance question. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Sat Dec 18 16:40:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 16:40:04 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: <2EHDfnTcy0dTbtkTbmz1XWAGwuine_3Ht1u9RbRmKXI=.7a661543-410f-4152-88e0-d58450a0ccbb@github.com> References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> <2EHDfnTcy0dTbtkTbmz1XWAGwuine_3Ht1u9RbRmKXI=.7a661543-410f-4152-88e0-d58450a0ccbb@github.com> Message-ID: On Sat, 18 Dec 2021 16:12:16 GMT, Kevin Rushforth wrote: >> Initially I went with the equality test, but it did not work well, probably since we are comparing floating points. This just seemed safer. If you want to try the equality test on you machine(s) it would be interesting, but I don't know if I would trust it. Same with the ES shaders. On the Java side I would trust it, but at this point it's a matter of consistency. >> >> I suspect that this also messed up with the computation approaches of spot light that check `falloff != 0` where we should be checking with a small delta: `abs(falloff) < EPSILON` instead. >> Performance should be revisited anyway I think at a later stage after the emissive color is added (where we need to figure out splitting shaders, which also has to do with the removal of the 3 lights restriction). > > It seems safer then to either leave it the way you have it (in which case, please a comment), or change it to `abs(gLightAttenuation[i].w) < EPSILON` both here and in the Java code (for consistency). I'll leave it up to you. > > For spot light, you might want to file a new bug to address the `falloff != 0` problem. > > I agree about deferring the performance question. Btw, you don't need the "abs" for the gLightAttenuation check (you don't have it now when checking against 0.5) so you can just change it to `gLightAttenuation[i].w < EPSILON` which seems cleaner than testing against 0.5. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Dec 18 16:40:01 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 16:40:01 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v5] In-Reply-To: References: Message-ID: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Fixed indentation - Added comments about floating point comparison ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/548/files - new: https://git.openjdk.java.net/jfx/pull/548/files/452e5672..7b3709d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=03-04 Stats: 6 lines in 6 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Sat Dec 18 16:40:05 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 18 Dec 2021 16:40:05 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> <2EHDfnTcy0dTbtkTbmz1XWAGwuine_3Ht1u9RbRmKXI=.7a661543-410f-4152-88e0-d58450a0ccbb@github.com> Message-ID: <0RZa_zfeC4V1JlBGpLn46evDvJi1rHMXmxoYYpW7DHo=.e09b44ef-26e4-41e4-90d5-3488b22a6921@github.com> On Sat, 18 Dec 2021 16:34:21 GMT, Kevin Rushforth wrote: >> Btw, you don't need the "abs" for the gLightAttenuation check (you don't have it now when checking against 0.5) so you can just change it to `gLightAttenuation[i].w < EPSILON` which seems cleaner than testing against 0.5. > > I see you kept it as 0.5 and documented it. That's fine, too. I just didn't want to mess with the math and need to retest everything just for this. If I add the EPSILON checks for falloff later I will use it there too. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Sat Dec 18 16:40:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Dec 2021 16:40:04 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v2] In-Reply-To: References: <9kVESFuZSPQ7blJa7fG1vseYPZm6rlq5KRDdxyj7p2M=.e95913cb-d94c-4ac8-9cd8-f6c1dfb40b4c@github.com> <2EHDfnTcy0dTbtkTbmz1XWAGwuine_3Ht1u9RbRmKXI=.7a661543-410f-4152-88e0-d58450a0ccbb@github.com> Message-ID: On Sat, 18 Dec 2021 16:32:53 GMT, Kevin Rushforth wrote: >> It seems safer then to either leave it the way you have it (in which case, please a comment), or change it to `abs(gLightAttenuation[i].w) < EPSILON` both here and in the Java code (for consistency). I'll leave it up to you. >> >> For spot light, you might want to file a new bug to address the `falloff != 0` problem. >> >> I agree about deferring the performance question. > > Btw, you don't need the "abs" for the gLightAttenuation check (you don't have it now when checking against 0.5) so you can just change it to `gLightAttenuation[i].w < EPSILON` which seems cleaner than testing against 0.5. I see you kept it as 0.5 and documented it. That's fine, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From jvos at openjdk.java.net Sun Dec 19 20:50:27 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 19 Dec 2021 20:50:27 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 07:27:50 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v5] Works as expected on Linux/mac ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/649 From jvos at openjdk.java.net Mon Dec 20 12:14:38 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 20 Dec 2021 12:14:38 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 21:40:47 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) > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into macshortcut > - Fixed whitespace error. > - A small number of keyboard layouts require the Option key to reach > critical letters like 'Q'. Added a third probe (after Command and > Shift+Command) to look for letters that require Option. The > keyboards in question are Azeri, Turkmen, and the Sami layouts. > - 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. > - Mac - generate KeyCodes that match user's active keyboard layout. This looks ok, but I'm still a bit worried about possible regression. I understand that rigorous automated tests are hard in this case, but I wonder if we can have some basic tests at least. Is there an issue in the Robot implementation preventing this? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Mon Dec 20 13:00:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Dec 2021 13:00:31 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v3] In-Reply-To: References: Message-ID: On Sat, 18 Dec 2021 15:45:07 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for review comments tests/performance/3DLighting/attenuation/Environment.java line 87: > 85: > 86: directionalLight1.setDirection(new Point3D(-LIGHT_X_DIST, 0, LIGHT_Z_DIST)); > 87: directionalLight2.setDirection(new Point3D(LIGHT_X_DIST, 0, LIGHT_Z_DIST)); You need to add an import for `Point3D`. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Mon Dec 20 13:13:09 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 20 Dec 2021 13:13:09 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: > Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. > > I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. > > I noticed a drop of ~1 fps in the stress test of 5000 meshes. > > I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added import ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/548/files - new: https://git.openjdk.java.net/jfx/pull/548/files/7b3709d7..c3fa4b49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=548&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/548.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/548/head:pull/548 PR: https://git.openjdk.java.net/jfx/pull/548 From nlisker at openjdk.java.net Mon Dec 20 13:13:13 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 20 Dec 2021 13:13:13 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v3] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 12:57:51 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for review comments > > tests/performance/3DLighting/attenuation/Environment.java line 87: > >> 85: >> 86: directionalLight1.setDirection(new Point3D(-LIGHT_X_DIST, 0, LIGHT_Z_DIST)); >> 87: directionalLight2.setDirection(new Point3D(LIGHT_X_DIST, 0, LIGHT_Z_DIST)); > > You need to add an import for `Point3D`. Weird that the IDE didn't warn. It seems like it did not identify the file as part of the source code. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From kcr at openjdk.java.net Mon Dec 20 15:00:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Dec 2021 15:00:28 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: On Mon, 20 Dec 2021 13:13:09 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Added import Marked as reviewed by kcr (Lead). Btw, `NGDirectionalLight.java` still has copyright 2020. If you need to update the PR for some other reason, please fix this, but otherwise don't worry about it. @arapte this is ready for you to review. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From duke at openjdk.java.net Mon Dec 20 19:21:36 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 20 Dec 2021 19:21:36 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v5] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 21:40:47 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) > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into macshortcut > - Fixed whitespace error. > - A small number of keyboard layouts require the Option key to reach > critical letters like 'Q'. Added a third probe (after Command and > Shift+Command) to look for letters that require Option. The > keyboards in question are Azeri, Turkmen, and the Sami layouts. > - 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. > - Mac - generate KeyCodes that match user's active keyboard layout. Let me start by saying that I already have two small changes to make to this PR. One is a fix for a bug in the Robot code. The other is a small tweak to the way dead keys are assigned key codes (I recently did a deep dive on dead keys). I will submit the changes in the next day or two. The regression that concerns me the most is losing access to key codes that are likely to be bound to KeyCodeCombination shortcuts. This includes the fixed-function keys (like KeyCode.SPACE and KeyCode.TAB) as well as KeyCode.A through KeyCode.Z. The attached KeyboardTest app contains a manual test for most of these keys (it's the "A-Z test" button at the bottom). With this PR the Robot implementation for letter keys will be good enough on all platforms that we can expand automated testing. But there's already a basic test for this (test.robot.javafx.scene.RobotTest) that fails on the Mac if the layout is French. I'm not sure why that failure was never reported. Expanding the test to cover more keys won't do any good if the test isn't run against non-US layouts and that requires manual setup. On every platform the Robot implementation has bugs related to punctuation and symbols. The fixes aren't that deep and I'll be submitting PR's for them (this PR already fixes the Mac). Once those bugs are fixed the testing will still be limited and manual. You have to know the current layout to craft a useful test and there's no API for querying the layout much less forcing it to the one you want to test. The KeyboardTest app has some limited tests specific to US, German, and French layouts that are useful for sanity checking. Unfortunately the attached version also include checks for KeyCharacterCombination matching which fail on the Mac (for now). I will tweak the app to make that part of the test optional. I was planning to submit this app as a manual test once the various platforms were in better shape. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From almatvee at openjdk.java.net Mon Dec 20 21:19:40 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 20 Dec 2021 21:19:40 GMT Subject: Integrated: 8273096: Add support for H.265/HEVC to JavaFX Media In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 07:51:20 GMT, Alexander Matveev wrote: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev This pull request has now been integrated. Changeset: 1f10c633 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/1f10c63358ac4cfdbe503da823f420d224397c78 Stats: 2086 lines in 30 files changed: 1964 ins; 28 del; 94 mod 8273096: Add support for H.265/HEVC to JavaFX Media Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Tue Dec 21 00:23:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Dec 2021 00:23:18 GMT Subject: RFR: 8234921: Add DirectionalLight to the selection of 3D light types In-Reply-To: References: Message-ID: <7O7CuxVop_t3rDDxiX3P5D9QChjNihup1PFjcud2_1k=.eebf7f22-9663-4b81-afda-87af72e8a39d@github.com> On Sat, 14 Aug 2021 12:58:01 GMT, Nir Lisker wrote: >> Adds a directional light as a subclass of `LightBase`. I think that this is the correct hierarchy for it. >> >> I tried to simulate a directional light by putting a point light far away, but I got artifacts when the distance was large. Instead, I added an on/off attenuation flag as the 4th component of the attenuation 4-vector. When it is 0, a simpler computation is used in the pixel/fragment shader that calculates the illumination based on the light direction only (making the position variables meaningless). When it is 1, the point/spot light computation is used. It's possible that the vertex shader can also be simplified in this case since it does not need to transform the position vectors, but I left this optimization avenue for another time. >> >> I noticed a drop of ~1 fps in the stress test of 5000 meshes. >> >> I added a system test that verifies the correct color result from a few directions. I also updated the lighting sample application to include 3 directional lights and tested them on all the models visually. The lights seem to behave the way I would expect. > > My commit message was wrong. I updated the `@since` tag, not the copyright year. I'll let the copyright year script do all the changed files together instead of doing it by hand. @nlisker I reviewed the CSR as well, so you can finalize it. ------------- PR: https://git.openjdk.java.net/jfx/pull/548 From duke at openjdk.java.net Tue Dec 21 12:13:17 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 21 Dec 2021 12:13:17 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 17 Dec 2021 19:18:23 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ROW_COUNT to 700_000 > > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 880: > >> 878: @Override public int indexOf(Object obj) { >> 879: reset(); >> 880: return super.indexOf(obj); > > So `reset` doesn't need to still be called? `reset()` was previously called since `super.indexof()` was making calls to `get(int index)` and it needed to have `lastGetIndex` and `lastGetValue` set to -1 ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Tue Dec 21 12:21:57 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 21 Dec 2021 12:21:57 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v4] In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: <477mS4pNlEi7uQMY9X1A1Kv2u0rIPzJkU5V7_kcHSkI=.509d4497-3f42-4a5c-b95c-0ca32770308a@github.com> > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: - Add space around operator and string - Add license header and add space around operators ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/673/files - new: https://git.openjdk.java.net/jfx/pull/673/files/8196b348..2d321087 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=02-03 Stats: 68 lines in 2 files changed: 50 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Tue Dec 21 12:22:03 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Tue, 21 Dec 2021 12:22:03 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> On Fri, 17 Dec 2021 17:46:54 GMT, Kevin Rushforth wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ROW_COUNT to 700_000 > > modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 877: > >> 875: if (size >= 0) { >> 876: return size; >> 877: } > > Using lazy evaluation means that you need to be extra careful that the size is invalidated in all the right places. One method that needs to be checked is the `set(int index, int... indices)` method. How carefully have you checked to make sure that nothing that could change the size fails to update the `size` field? > > Related to this, are you satisfied that the current set of unit tests are sufficient to catch any potential problems, and that you don't need to add more tests? Good point. All the test cases that I could think of were already present in `MultipleSelectionModelImplTest`. Nevertheless, test cases for different `set()` methods can definitely be added. I will work on it. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Tue Dec 21 15:38:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Dec 2021 15:38:14 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> Message-ID: On Tue, 21 Dec 2021 12:13:55 GMT, Abhinay Agarwal wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 877: >> >>> 875: if (size >= 0) { >>> 876: return size; >>> 877: } >> >> Using lazy evaluation means that you need to be extra careful that the size is invalidated in all the right places. One method that needs to be checked is the `set(int index, int... indices)` method. How carefully have you checked to make sure that nothing that could change the size fails to update the `size` field? >> >> Related to this, are you satisfied that the current set of unit tests are sufficient to catch any potential problems, and that you don't need to add more tests? > > Good point. All the test cases that I could think of were already present in `MultipleSelectionModelImplTest`. Nevertheless, test cases for different `set()` methods can definitely be added. I will work on it. What about the first part of my question? Have you looked at the set logic to ensure that `size` is being invalidated in all places it should be. The `set(int index, int... indices)` method does not directly invalidate `size`. If that method unconditionally set `size = -1`, it would be easier to prove that there are no missed cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Tue Dec 21 16:42:40 2021 From: duke at openjdk.java.net (Martin Fox) Date: Tue, 21 Dec 2021 16:42:40 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6] 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: Bug fixes in Robot. Ensure symbols uncovered using Option are ignored. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/425/files - new: https://git.openjdk.java.net/jfx/pull/425/files/1037be20..99d24ae0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=425&range=04-05 Stats: 9 lines in 1 file changed: 3 ins; 3 del; 3 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 duke at openjdk.java.net Tue Dec 21 16:47:21 2021 From: duke at openjdk.java.net (Martin Fox) Date: Tue, 21 Dec 2021 16:47:21 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v6] In-Reply-To: References: Message-ID: On Tue, 21 Dec 2021 16:42:40 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) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Bug fixes in Robot. Ensure symbols uncovered using Option are ignored. I?ve updated the PR with three bug fixes that were in my queue. Sorry for not getting them in earlier. GetGlassKey (used by the Robot) - The table only covers US QWERTY and is missing entries for codes like PLUS or NUMBER_SIGN. There was a bug that prevented these codes from working on any layout. That?s been fixed. The same routine was also returning a bogus result when asked to look up UNDEFINED. That?s also been fixed. getJavaCodeForMacKey - The probe for the Option key character was intended to find letters. In some instances it could find a symbol and use that to determine the code. This could cause a key like ? or ? to be given a code like SLASH. That?s been fixed to better match Windows and Linux where these keys are UNDEFINED. I?ve attached a sanity test for the Robot code. Every time you press a key it just sends the KeyCode to a Robot and verifies that a TYPED event with the same code is received. [RobotKeySanityTest.txt](https://github.com/openjdk/jfx/files/7756820/RobotKeySanityTest.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From duke at openjdk.java.net Tue Dec 21 17:11:20 2021 From: duke at openjdk.java.net (yosbits) Date: Tue, 21 Dec 2021 17:11:20 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> Message-ID: On Tue, 21 Dec 2021 15:35:32 GMT, Kevin Rushforth wrote: >> Good point. All the test cases that I could think of were already present in `MultipleSelectionModelImplTest`. Nevertheless, test cases for different `set()` methods can definitely be added. I will work on it. > > What about the first part of my question? Have you looked at the set logic to ensure that `size` is being invalidated in all places it should be. The `set(int index, int... indices)` method does not directly invalidate `size`. If that method unconditionally set `size = -1`, it would be easier to prove that there are no missed cases. This is a cache of the cardinality method of BitSet, not Lazy evaluation. It sets invalidity (-1) in the method call that changes the bit. This could be a subclass of BitSet to make the code more readable. This patch does not subclass BitSet because there is no case where it is used in the same way. If it were to be subclassed, it would be possible to reduce the number of cardinality calls if it were calculated wisely instead of simply being disabled. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Tue Dec 21 17:59:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Dec 2021 17:59:17 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> Message-ID: On Tue, 21 Dec 2021 17:08:26 GMT, yosbits wrote: >> What about the first part of my question? Have you looked at the set logic to ensure that `size` is being invalidated in all places it should be. The `set(int index, int... indices)` method does not directly invalidate `size`. If that method unconditionally set `size = -1`, it would be easier to prove that there are no missed cases. > > This is a cache of the cardinality method of BitSet, not Lazy evaluation. It sets invalidity (-1) in the method call that changes the bit. This could be a subclass of BitSet to make the code more readable. This patch does not subclass BitSet because there is no case where it is used in the same way. > > If you subclass it, you can probably reduce the number of calls to cardinality to zero if you calculate it wisely instead of simply setting invalid. The patch does not take this challenge for readability reasons. A cache that's manually invalidated and then validated when needed is a form of lazy evaluation. The main point, regardless of how you name it, is to ensure that every call that modifies the underlying BitSet invalidates the size. If it does, and it can be proven to do so, then that's sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From arapte at openjdk.java.net Tue Dec 21 18:36:31 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 21 Dec 2021 18:36:31 GMT Subject: RFR: 8279078: Update copyright header for files modified in 2021 Message-ID: Fix for updating last modified year in the files that were modified during year 2021. @kevinrushforth, Please take a look. ------------- Commit messages: - copyright year update 2021 Changes: https://git.openjdk.java.net/jfx/pull/699/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=699&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279078 Stats: 75 lines in 74 files changed: 0 ins; 0 del; 75 mod Patch: https://git.openjdk.java.net/jfx/pull/699.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/699/head:pull/699 PR: https://git.openjdk.java.net/jfx/pull/699 From kcr at openjdk.java.net Tue Dec 21 19:02:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Dec 2021 19:02:18 GMT Subject: RFR: 8279078: Update copyright header for files modified in 2021 In-Reply-To: References: Message-ID: <4FnKnQ-mjNBYpv--vELpE-nrcMr4tqd10WIdYICw0Wg=.8f0c3a6f-bad6-40fb-be9f-68bd4f1014bd@github.com> On Tue, 21 Dec 2021 18:31:13 GMT, Ambarish Rapte wrote: > Fix for updating last modified year in the files that were modified during year 2021. > @kevinrushforth, Please take a look. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/699 From arapte at openjdk.java.net Tue Dec 21 20:22:21 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 21 Dec 2021 20:22:21 GMT Subject: Integrated: 8279078: Update copyright header for files modified in 2021 In-Reply-To: References: Message-ID: <3xRQBYa5uVh0GTNkMqOSQCYfUJfUna-zC8xTkdTOqXc=.f6781e74-7791-4d5c-8b3a-1fc90e6a5cd6@github.com> On Tue, 21 Dec 2021 18:31:13 GMT, Ambarish Rapte wrote: > Fix for updating last modified year in the files that were modified during year 2021. > @kevinrushforth, Please take a look. This pull request has now been integrated. Changeset: 303bcdb9 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/303bcdb9ba40b7d82e555d675dad8d028e018c86 Stats: 75 lines in 74 files changed: 0 ins; 0 del; 75 mod 8279078: Update copyright header for files modified in 2021 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/699 From duke at openjdk.java.net Wed Dec 22 09:05:32 2021 From: duke at openjdk.java.net (eduardsdv) Date: Wed, 22 Dec 2021 09:05:32 GMT Subject: RFR: 8203463: [Accessibility, Narrator] NPE in TableView Message-ID: The NullPointer occurs when `Accessible.getAttribute(Object)` returns null. I checked all places where the `getAttribute(..)` method is called. Everywhere it is checked for null `(Accessible,` `MacAccessible,` `WinAccessible,` `WinTextRangeProvider`). Only at this one place in `WinAccessible.GetPatternProvider(int)` it is missing. This PR adds this missing null-check in the `WinAccessible.GetPatternProvider(int)` method. ------------- Commit messages: - Merge branch 'openjdk:master' into bugfix/8203463-NPE-in-WinAccessible-GetPatternProvider - WinAccessible: Add missing null check Changes: https://git.openjdk.java.net/jfx/pull/700/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/700.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/700/head:pull/700 PR: https://git.openjdk.java.net/jfx/pull/700 From kcr at openjdk.java.net Wed Dec 22 13:52:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Dec 2021 13:52:23 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v4] In-Reply-To: <477mS4pNlEi7uQMY9X1A1Kv2u0rIPzJkU5V7_kcHSkI=.509d4497-3f42-4a5c-b95c-0ca32770308a@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <477mS4pNlEi7uQMY9X1A1Kv2u0rIPzJkU5V7_kcHSkI=.509d4497-3f42-4a5c-b95c-0ca32770308a@github.com> Message-ID: <-KKF_xhe5T31cNtxS6qwPN2kIy9HVfh-m3ve7WzOEq0=.59855f48-5307-4bda-8600-aa64bce421b8@github.com> On Tue, 21 Dec 2021 12:21:57 GMT, Abhinay Agarwal wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Add space around operator and string > - Add license header and add space around operators I think this is very close to being ready to go in. I left one more inline comment about the invalidation of `size`. There is also a pending minor code formatting comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Wed Dec 22 13:52:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Dec 2021 13:52:23 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> <2ToUUw8Har8rqexRIrQovxsUvzzPrzHjIEDqRSz_9PQ=.d0dbaa50-f0e1-47ae-ab94-7ec79ba34ec9@github.com> Message-ID: On Tue, 21 Dec 2021 17:56:22 GMT, Kevin Rushforth wrote: >> This is a cache of the cardinality method of BitSet, not Lazy evaluation. It sets invalidity (-1) in the method call that changes the bit. This could be a subclass of BitSet to make the code more readable. This patch does not subclass BitSet because there is no case where it is used in the same way. >> >> If you subclass it, you can probably reduce the number of calls to cardinality to zero if you calculate it wisely instead of simply setting invalid. The patch does not take this challenge for readability reasons. > > A cache that's manually invalidated and then validated when needed is a form of lazy evaluation. The main point, regardless of how you name it, is to ensure that every call that modifies the underlying BitSet invalidates the size. If it does, and it can be proven to do so, then that's sufficient. I checked, and I think that `set(int index, int... indices)` is fine, since it doesn't modify `bitset` directly, and all of the methods it calls that do modify it, correctly invalidate `size`. One more thing I spotted that needs to be checked, is the `SelectedIndicesList(BitSet)` constructor. It saves a reference to the source `BitSet` without making a copy. If a caller ever modified the source `BitSet`, it would change the underlying `BitSet` seen by the `SelectedIndicesList` class, and the size would therefore be wrong. Even if the current code doesn't do this, it's somewhat fragile. I recommend adding a comment to the constructor, and to the one place it's called, noting that the source `BitSet` must not be modified after passing it to the constructor. Finally, there is a commented out `clearAndSelect` method that would break the new contract of invalidating size whenever the bitmap is modified, if that method were ever uncommented. Either it should be deleted as part of this PR or it should be modified with a (commented out, of course) `size = -1` in the right place(s). ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Wed Dec 22 13:56:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Dec 2021 13:56:17 GMT Subject: RFR: 8203463: [Accessibility, Narrator] NPE in TableView In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 08:59:53 GMT, eduardsdv wrote: > The NullPointer occurs when `Accessible.getAttribute(Object)` returns null. > I checked all places where the `getAttribute(..)` method is called. Everywhere it is checked for null `(Accessible,` `MacAccessible,` `WinAccessible,` `WinTextRangeProvider`). Only at this one place in `WinAccessible.GetPatternProvider(int)` it is missing. > > This PR adds this missing null-check in the `WinAccessible.GetPatternProvider(int)` method. This looks like an obviously correct fix to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/700 From duke at openjdk.java.net Wed Dec 22 17:27:13 2021 From: duke at openjdk.java.net (eduardsdv) Date: Wed, 22 Dec 2021 17:27:13 GMT Subject: Integrated: 8203463: [Accessibility, Narrator] NPE in TableView In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 08:59:53 GMT, eduardsdv wrote: > The NullPointer occurs when `Accessible.getAttribute(Object)` returns null. > I checked all places where the `getAttribute(..)` method is called. Everywhere it is checked for null `(Accessible,` `MacAccessible,` `WinAccessible,` `WinTextRangeProvider`). Only at this one place in `WinAccessible.GetPatternProvider(int)` it is missing. > > This PR adds this missing null-check in the `WinAccessible.GetPatternProvider(int)` method. This pull request has now been integrated. Changeset: c705bd49 Author: eduardsdv <53449139+eduardsdv at users.noreply.github.com> Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c705bd493931d88650542be5466d6add359f45b9 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8203463: [Accessibility, Narrator] NPE in TableView Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/700 From fkirmaier at openjdk.java.net Thu Dec 23 17:49:40 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 23 Dec 2021 17:49:40 GMT Subject: RFR: 8279228 Leak in ScrollPaneSkin, related to touch events Message-ID: Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, and the node is removed from the Scene, then the animation will never stop, causing a memory leak. A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. ------------- Commit messages: - JDK-8279228 Changes: https://git.openjdk.java.net/jfx/pull/701/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=701&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279228 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/701.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/701/head:pull/701 PR: https://git.openjdk.java.net/jfx/pull/701 From duke at openjdk.java.net Thu Dec 23 20:57:35 2021 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 23 Dec 2021 20:57:35 GMT Subject: RFR: 8278938: [Win] Robot can target wrong key for punctuation and symbols Message-ID: When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead key) the glass code will dynamically query the key's unshifted character to determine the Java code to assign to it. This is necessary since the relationship between OEM key codes and the characters they generate varies from layout to layout. The Robot implementation was consulting a table which assumed a fixed relationship between Java codes and Windows key codes even for the OEM keys. The table was also missing entries for any Java code not on a US QWERTY layout, like PLUS. In this PR if we don't find the Java code in the table or if it maps to an OEM key (which may be wrong) we sweep through all the OEM keys looking for the matching Java code. ------------- Commit messages: - Robot now targets punctuation and symbol keys reliably Changes: https://git.openjdk.java.net/jfx/pull/702/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=702&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278938 Stats: 180 lines in 3 files changed: 116 ins; 57 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/702.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/702/head:pull/702 PR: https://git.openjdk.java.net/jfx/pull/702 From duke at openjdk.java.net Wed Dec 29 00:49:27 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Wed, 29 Dec 2021 00:49:27 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog Message-ID: This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivalent functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. ------------- Commit messages: - Merge branch 'openjdk:master' into fix-8242544 - 8242544: CMD+ENTER key event crashes the application when invoked on dialog Changes: https://git.openjdk.java.net/jfx/pull/704/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=704&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242544 Stats: 20 lines in 4 files changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/704.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/704/head:pull/704 PR: https://git.openjdk.java.net/jfx/pull/704 From duke at openjdk.java.net Wed Dec 29 14:03:16 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Wed, 29 Dec 2021 14:03:16 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. This fix seems to also solve [https://github.com/javafxports/openjdk-jfx/issues/370](https://github.com/javafxports/openjdk-jfx/issues/370). ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From mstrauss at openjdk.java.net Wed Dec 29 15:44:34 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 29 Dec 2021 15:44:34 GMT Subject: RFR: 8279328: CssParser uses default charset instead of UTF-8 Message-ID: `CssParser.parse(URL)` is specified to assume UTF-8 file encoding, but (implicitly) uses the default charset to read the file, potentially resulting in incorrect interpretation of the file content. This can be fixed by explicitly specifying the UTF-8 charset for `InputStreamReader`. ------------- Commit messages: - Use UTF-8 charset to parse stylesheets - Failing test Changes: https://git.openjdk.java.net/jfx/pull/705/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=705&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279328 Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/705.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/705/head:pull/705 PR: https://git.openjdk.java.net/jfx/pull/705 From duke at openjdk.java.net Wed Dec 29 17:18:17 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 29 Dec 2021 17:18:17 GMT Subject: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the performKeyEquivalent method, first. If no view or window handles such a shortcut key event (indicated by a return value NO in performKeyEquivalent), the key event is sent a second time via the sendEvent method. Before this fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be called twice: first by performKeyEquivalent and then by sendEvent, since no responder returned YES in performKeyEquivalent. For not handling the same event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** in **GlassViewDelegate.m**. It only handled the first call. The second call checked if the given event was exactly the same like in the last call. In this case it simply returned and did not forward the event. This means that all key events with a CMD or CTRL modifier were handled in JFX in the performKeyEquivalent event loop, even though they actually weren't used by the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if the window was closed and if so, it returned YES. However, nowadays the window closing check did not work... self->gWindow->isClosed returned NO when I debugged it, although the window should be closed by the key event. Returning YES in case of a closed window is not a clean solution, anyway, because YES should mean that the shortcut key equivalent is handled. Another point is that Apple writes that overwriting performKeyEquivalent in an NSWindow subclass is discouraged. So, I completely deleted the method from **GlassWindow.m**, since it only returned the value of the super function, except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns NO, only deleting the method from **GlassWindow.m** did not fix the crash. So I tried to solve the problem that a shortcut key event is handled in the performKeyEquivalent loop. The call of **sendJavaKeyEvent** in **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not be handled, actually. So, I simply removed this call which is done in **GlassView3D.m** **performKeyEquivalent** method. By removing the call, there is also no longer any need to check if the same key event was passed to **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also removed. > > I'm curious about your comments and reviews and I wonder if this is a clean solution. All my tests so far seemed to be fine. I can reproduce this with a small Mac app that does nothing but set the NSWindow's contentView to nil while handling `processKeyEvent:`. I'm not handling the event twice or destroying the NSWindow. The crash happens immediately after returning from my implementation of `processKeyEvent:` and back into Apple's code. There's something about Apple's implementation of this routine that's sensitive to having the contentView nulled out. I don't see the same crash if I set the contentView to nil inside a `keyDown:` event. I would love to get rid of our `performKeyEquivalent:` methods but we can't. JavaFX assumes that the focused Node will get the first opportunity to process a KeyEvent. For example, if a TextArea has the focus it gets the first opportunity to process `Cmd-A` to select all text. A KeyEvent should only bubble up to the top level menus if the focused node doesn't handle it. When using the system menubar on Mac this means we need to implement `processKeyEquivalent:` to ensure that we can hand the key event to the focused JavaFX node before it gets handled by the main NSMenu. Unfortunately there's currently no way to determine that the event was consumed by the node so the Mac glass code hands it over to the main menu anyway. This leads to bugs where one event triggers multiple actions like [JDK-8087863](https://bugs.openjdk.java.net/browse/JDK-8087863) and [JDK-8088897](https://bugs.openjdk.java.net/browse/JDK-8088897) and the ones listed over in javafxports. Most of the changes for fixing this are in PR #694. You're correct that the implementation of `performKeyEquivalent:` in GlassWindow.m is probably not necessary. The `close` selector is sent to the NSWindow asynchronously so the `isClosed` flag will never be set at the end of `performKeyEquivalent:`. This has been true since sometime in 2015, see the comments in `Java_com_sun_glass_ui_mac_MacWindow__1close`. ------------- PR: https://git.openjdk.java.net/jfx/pull/704 From nlisker at openjdk.java.net Thu Dec 30 05:03:18 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 30 Dec 2021 05:03:18 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v3] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Upgrade tests to JUnit 5 I will start my review this week. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From mstrauss at openjdk.java.net Fri Dec 31 12:57:19 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 31 Dec 2021 12:57:19 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v2] In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 15:21:56 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Added missing change Why are the new listener imlementations called `BaseChangeListener` and `BaseInvalidationListener`, i.e. why the _Base_? Also, if you're going to the trouble of refactoring the existing listener implementation, have you considered merging the very similar implementations into a single class? You can then re-use the listener instance and save another object allocation in this way: private static class Listener extends WeakReference> implements InvalidationListener, ListChangeListener, WeakListener { Listener(ListPropertyBase ref) { super(ref); } @Override public boolean wasGarbageCollected() { return get() == null; } @Override public void onChanged(Change change) { ListPropertyBase ref = get(); if(ref != null) { ref.invalidateProperties(); ref.invalidated(); ref.fireValueChangedEvent(change); } } @Override public void invalidated(Observable observable) { ListPropertyBase ref = get(); if (ref == null) { observable.removeListener(this); } else { ref.markInvalid(ref.value); } } } ------------- PR: https://git.openjdk.java.net/jfx/pull/689