From ajoseph at openjdk.java.net Tue Dec 1 03:12:10 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 1 Dec 2020 03:12:10 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v5] In-Reply-To: References: Message-ID: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Concat log warning ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/fc3b66cf..49d7b5f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=324&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324 From johan.vos at gluonhq.com Tue Dec 1 16:40:22 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 1 Dec 2020 17:40:22 +0100 Subject: backport request for JavaFX 11 Message-ID: Hi Kevin, I ask permission to backport the following issue to JavaFX 11 (for 11.0.10) JDK-8199592: Control labels truncated at certain DPI scaling levels - Johan From kcr at openjdk.java.net Tue Dec 1 16:58:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 1 Dec 2020 16:58:55 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 03:12:10 GMT, Arun Joseph wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Concat log warning Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/324 From kevin.rushforth at oracle.com Tue Dec 1 17:04:07 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 1 Dec 2020 09:04:07 -0800 Subject: backport request for JavaFX 11 In-Reply-To: References: Message-ID: +1 -- Kevin On 12/1/2020 8:40 AM, Johan Vos wrote: > Hi Kevin, > > I ask permission to backport the following issue to JavaFX 11 (for 11.0.10) > > JDK-8199592: Control labels truncated at certain DPI scaling levels > > - Johan From kevin.rushforth at oracle.com Wed Dec 2 20:14:01 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 2 Dec 2020 12:14:01 -0800 Subject: Draft PR for JDK-8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina Message-ID: I have created a Draft PR for JDK-8233678 (System menu bar does not work initially on macOS Catalina) here: https://github.com/openjdk/jfx/pull/361 It's just about ready for formal review, once I remove the debugs print statements, but before I do I'd like someone other than me to validate this on a macOS 10.15 (Catalina) or macOS 11 (Big Sur) system. If anyone does try it, go ahead and add a comment to the PR. Thanks. -- Kevin From ghb at openjdk.java.net Thu Dec 3 05:10:56 2020 From: ghb at openjdk.java.net (Guru Hb) Date: Thu, 3 Dec 2020 05:10:56 GMT Subject: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 03:12:10 GMT, Arun Joseph wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: > > Concat log warning Looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/324 From ajoseph at openjdk.java.net Thu Dec 3 08:14:55 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 3 Dec 2020 08:14:55 GMT Subject: Integrated: 8254049: Update WebView to public suffix list 2020-04-24 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 04:29:13 GMT, Arun Joseph wrote: > We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java This pull request has now been integrated. Changeset: c8d9c94d Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/c8d9c94d Stats: 5363 lines in 4 files changed: 87 ins; 5214 del; 62 mod 8254049: Update WebView to public suffix list 2020-04-24 Reviewed-by: kcr, ghb ------------- PR: https://git.openjdk.java.net/jfx/pull/324 From kcr at openjdk.java.net Thu Dec 3 13:50:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 13:50:02 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina Message-ID: This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. ------------- Commit messages: - Remove debug print statements and turn off verbose logging - Fix cases where the app is not a normal app (e.g., JFXPanel, FXCanvas and non-taskbar apps) - TEMPORARY: enabled verbose debug print statements (will be reverted before finalising the PR) - 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina Changes: https://git.openjdk.java.net/jfx/pull/361/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=361&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233678 Stats: 103 lines in 4 files changed: 88 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/361.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/361/head:pull/361 PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 13:50:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 13:50:03 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. I note that this does not seem to be a problem for Swing apps. AWT uses the Java Runtime Support (JRS) framework to initialize the application and menubar. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 13:50:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 13:50:03 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> References: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> Message-ID: On Wed, 2 Dec 2020 20:05:03 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > I note that this does not seem to be a problem for Swing apps. AWT uses the Java Runtime Support (JRS) framework to initialize the application and menubar. Note to testers: `JFXPanel` applications deadlock with this fix. I need to check whether glass is being started up for a normal Taskbar application, and not being embedded in an `FXCanvas` or `JFXPanel`. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Thu Dec 3 13:50:03 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Dec 2020 13:50:03 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> Message-ID: On Wed, 2 Dec 2020 21:06:10 GMT, Kevin Rushforth wrote: >> I note that this does not seem to be a problem for Swing apps. AWT uses the Java Runtime Support (JRS) framework to initialize the application and menubar. > > Note to testers: `JFXPanel` applications deadlock with this fix. I need to check whether glass is being started up for a normal Taskbar application, and not being embedded in an `FXCanvas` or `JFXPanel`. I tested the patch, and it works for me (MacOS Catalina, 10.15.7) I will look into more detail in the code, as I'm slightly worried about not following the Apple conventions. From experience, this often leads to more issues sooner or later. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 13:50:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 13:50:03 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> Message-ID: On Thu, 3 Dec 2020 09:14:00 GMT, Johan Vos wrote: >> Note to testers: `JFXPanel` applications deadlock with this fix. I need to check whether glass is being started up for a normal Taskbar application, and not being embedded in an `FXCanvas` or `JFXPanel`. > > I tested the patch, and it works for me (MacOS Catalina, 10.15.7) > I will look into more detail in the code, as I'm slightly worried about not following the Apple conventions. From experience, this often leads to more issues sooner or later. Thanks for checking. I'll remove the debug print statements, turn off verbose logging, and send it out for review. I would appreciate a thorough review of the code. Given the way JavaFX initializes the macOS application and sets the system menu bar, this seems like the least intrusive and least risky fix, but it would be nice if we can find a better fix that isn't overly complicated or risky. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 14:00:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 14:00:56 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> Message-ID: <4cNMTD8HLIPGniCjrxxnIiT1Fz0ePpWyAfbi_dr0SA8=.57854d10-cbf6-41bf-8999-81af6c11a93c@github.com> On Thu, 3 Dec 2020 13:34:04 GMT, Kevin Rushforth wrote: >> I tested the patch, and it works for me (MacOS Catalina, 10.15.7) >> I will look into more detail in the code, as I'm slightly worried about not following the Apple conventions. From experience, this often leads to more issues sooner or later. > > Thanks for checking. I'll remove the debug print statements, turn off verbose logging, and send it out for review. I would appreciate a thorough review of the code. Given the way JavaFX initializes the macOS application and sets the system menu bar, this seems like the least intrusive and least risky fix, but it would be nice if we can find a better fix that isn't overly complicated or risky. For some reason, the GitHub actions test results weren't added by the Skara bot. I filed [SKARA-839](https://bugs.openjdk.java.net/browse/SKARA-839) to track this. You can [click here](https://github.com/kevinrushforth/jfx/actions/runs/398484208) to see the results of the GitHub action for the most recent commit I pushed. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Thu Dec 3 16:26:00 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Dec 2020 16:26:00 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 142: > 140: @Override > 141: protected void notifyDidBecomeActive() { > 142: super.notifyDidBecomeActive(); if an exception occurs in this method (which can happen in case the superclass eventHandler.handleDidBecomeActiveAction() throws an exception), the countDownLatch is never decreased, and the `wrappedRunnable` will never return. I am not sure what the best approach is in this case. The Thread that waits for the reactivation is a daemon thread, but there might be other non-daemon threads lingering. One of the options is to set a timeout on the `reactivationLatch`. If the countdown didn't happen almost instantly, something is going wrong. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Thu Dec 3 16:33:56 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Dec 2020 16:33:56 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: <4cNMTD8HLIPGniCjrxxnIiT1Fz0ePpWyAfbi_dr0SA8=.57854d10-cbf6-41bf-8999-81af6c11a93c@github.com> References: <3dohe9YpfqEEnVpIQf9bNhMPR1RffvAIqWJ6x4T5lLY=.092b43c2-78a9-4bf0-bf8c-5caa7eac2a0a@github.com> <4cNMTD8HLIPGniCjrxxnIiT1Fz0ePpWyAfbi_dr0SA8=.57854d10-cbf6-41bf-8999-81af6c11a93c@github.com> Message-ID: On Thu, 3 Dec 2020 13:58:31 GMT, Kevin Rushforth wrote: >> Thanks for checking. I'll remove the debug print statements, turn off verbose logging, and send it out for review. I would appreciate a thorough review of the code. Given the way JavaFX initializes the macOS application and sets the system menu bar, this seems like the least intrusive and least risky fix, but it would be nice if we can find a better fix that isn't overly complicated or risky. > > For some reason, the GitHub actions test results weren't added by the Skara bot. I filed [SKARA-839](https://bugs.openjdk.java.net/browse/SKARA-839) to track this. > > You can [click here](https://github.com/kevinrushforth/jfx/actions/runs/398484208) to see the results of the GitHub action for the most recent commit I pushed. I added a few comments. In general, the approach looks ok to me. My comments are about edge cases, for which I'm not sure how we need to handle them. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Thu Dec 3 16:33:58 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Dec 2020 16:33:58 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: <2XoQdACTzzHygo625dav7YWvTeSo7w-1O5ZuAmO5HMk=.ccc21232-a9e1-4d27-9b86-44579cc92e93@github.com> On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 1079: > 1077: { > 1078: LOG("Java_com_sun_glass_ui_mac_MacApplication__1isNormalTaskbarApp"); > 1079: return isNormalTaskbarApp; Are we guaranteed that this is not called before the runLoop is invoked? The `isNormalTaskbarApp` is only set to `YES` at line 536, and in theory, this method may get called before. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 16:42:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 16:42:59 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 16:23:47 GMT, Johan Vos wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 142: > >> 140: @Override >> 141: protected void notifyDidBecomeActive() { >> 142: super.notifyDidBecomeActive(); > > if an exception occurs in this method (which can happen in case the superclass eventHandler.handleDidBecomeActiveAction() throws an exception), the countDownLatch is never decreased, and the `wrappedRunnable` will never return. > I am not sure what the best approach is in this case. The Thread that waits for the reactivation is a daemon thread, but there might be other non-daemon threads lingering. > One of the options is to set a timeout on the `reactivationLatch`. If the countdown didn't happen almost instantly, something is going wrong. Good catch. It will block the starting of the app if this happens since we will never exit the nested event loop. Putting the call to `reactivationLatch.countDown();` in a try / finally seems best (although I had earlier considered a timeout as well). > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 1079: > >> 1077: { >> 1078: LOG("Java_com_sun_glass_ui_mac_MacApplication__1isNormalTaskbarApp"); >> 1079: return isNormalTaskbarApp; > > Are we guaranteed that this is not called before the runLoop is invoked? The `isNormalTaskbarApp` is only set to `YES` at line 536, and in theory, this method may get called before. Yes, we only call it after runLoop (which is why the check is in the `wrappedRunnable`). A comment seems in order, so I'll add one. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 17:39:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 17:39:08 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. 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/361/files - new: https://git.openjdk.java.net/jfx/pull/361/files/3078e21f..e7de442c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=361&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=361&range=00-01 Stats: 12 lines in 1 file changed: 8 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/361.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/361/head:pull/361 PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Thu Dec 3 17:39:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Dec 2020 17:39:08 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 16:39:59 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 142: >> >>> 140: @Override >>> 141: protected void notifyDidBecomeActive() { >>> 142: super.notifyDidBecomeActive(); >> >> if an exception occurs in this method (which can happen in case the superclass eventHandler.handleDidBecomeActiveAction() throws an exception), the countDownLatch is never decreased, and the `wrappedRunnable` will never return. >> I am not sure what the best approach is in this case. The Thread that waits for the reactivation is a daemon thread, but there might be other non-daemon threads lingering. >> One of the options is to set a timeout on the `reactivationLatch`. If the countdown didn't happen almost instantly, something is going wrong. > > Good catch. It will block the starting of the app if this happens since we will never exit the nested event loop. Putting the call to `reactivationLatch.countDown();` in a try / finally seems best (although I had earlier considered a timeout as well). Rather than a try / catch I simply moved the call to super after the setting of the flag in `notifyDidResignActive` and the countdown in `notifyDidBecomeActive`. I also added a timeout just to be safe. It waits for 5 seconds and logs a warning before continuing. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Thu Dec 3 17:56:57 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 3 Dec 2020 17:56:57 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 17:39:08 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > 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/361 From kcr at openjdk.java.net Fri Dec 4 02:14:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Dec 2020 02:14:02 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread Message-ID: This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. ------------- Commit messages: - Add automated tests, enclose the latch in try/finally, - 8231372: Correctly terminate secondary event loop in JFXPanel.setScene() Changes: https://git.openjdk.java.net/jfx/pull/362/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=362&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231372 Stats: 62 lines in 2 files changed: 56 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/362/head:pull/362 PR: https://git.openjdk.java.net/jfx/pull/362 From psadhukhan at openjdk.java.net Fri Dec 4 04:17:55 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 4 Dec 2020 04:17:55 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 02:07:37 GMT, Kevin Rushforth wrote: > This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. > > While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. > > NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/362 From fthevenet at openjdk.java.net Fri Dec 4 10:49:10 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 4 Dec 2020 10:49:10 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> Message-ID: <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> On Wed, 21 Oct 2020 12:35:34 GMT, Kevin Rushforth wrote: >> Hello, >> Did anyone get a chance to look into this? >> Thanks! > > Not yet. I took a quick look, and this is helpful in pointing out where the problem is, but I don't know whether it is the right solution to simply round the transform values when rendering the cache to the screen. Hi, Is there anything I can do to help get this moving forward again? As mentioned before, I agree the proposed fix might be simply be addressing the symptoms rather than the root cause and I'm willing to keep working on it but I'd really appreciate a second opinion and some insights as to where to direct my attention if this fix proves to be not enough. For what it's worth, I've been living with this fix on my dev machine for a while now, and it does provide the expected relief to the underlying issue, without me noticing any obvious regressions, neither visually nor performance-wise (I haven't run any targeted benchmarks, though). With JDK-8199592 fixed, I think it'd be great if we could tackle all of the scaling issues in 16 (might be getting a bit late now, though) ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Fri Dec 4 14:13:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Dec 2020 14:13:12 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: <4cQaEBtzBYen7uJ87oMuNuRZ6nSCAkOHptylkRaXjXA=.5bc33635-b53f-4931-b81d-4f1c8c9154d4@github.com> On Thu, 3 Dec 2020 17:39:08 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 103: > 101: private final CountDownLatch reactivationLatch = new CountDownLatch(1); > 102: > 103: // Spin up a nested even loop waiting for the app reactivation event I just spotted a typo in this comment: even --> event I'll wait to see if there are suggested changes from other reviewers, and then fix this. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Fri Dec 4 23:44:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Dec 2020 23:44:09 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Fri, 4 Dec 2020 10:46:27 GMT, Frederic Thevenet wrote: >> Not yet. I took a quick look, and this is helpful in pointing out where the problem is, but I don't know whether it is the right solution to simply round the transform values when rendering the cache to the screen. > > Hi, > > Is there anything I can do to help get this moving forward again? > > As mentioned before, I agree the proposed fix might be simply be addressing the symptoms rather than the root cause and I'm willing to keep working on it but I'd really appreciate a second opinion and some insights as to where to direct my attention if this fix proves to be not enough. > > For what it's worth, I've been living with this fix on my dev machine for a while now, and it does provide the expected relief to the underlying issue, without me noticing any obvious regressions, neither visually nor performance-wise (I haven't run any targeted benchmarks, though). > > With JDK-8199592 fixed, I think it'd be great if we could tackle all of the scaling issues in 16 (might be getting a bit late now, though) I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Sat Dec 5 11:36:13 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sat, 5 Dec 2020 11:36:13 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Fri, 4 Dec 2020 23:41:38 GMT, Kevin Rushforth wrote: > > > I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. That's great news, thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Sat Dec 5 13:42:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Dec 2020 13:42:22 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 04:14:48 GMT, Prasanta Sadhukhan wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Dispose JFrame after each test > > Marked as reviewed by psadhukhan (Reviewer). I noticed that the Swing `JFrame`s weren't being hidden after each test, so I added an `@After` cleanup method. ------------- PR: https://git.openjdk.java.net/jfx/pull/362 From kcr at openjdk.java.net Sat Dec 5 13:42:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Dec 2020 13:42:21 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread [v2] In-Reply-To: References: Message-ID: > This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. > > While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. > > NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Dispose JFrame after each test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/362/files - new: https://git.openjdk.java.net/jfx/pull/362/files/6039460b..22e3886d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=362&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=362&range=00-01 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/362/head:pull/362 PR: https://git.openjdk.java.net/jfx/pull/362 From arapte at openjdk.java.net Mon Dec 7 06:28:14 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Dec 2020 06:28:14 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: <-hSPCmNmhCqK7s2x56HBDfiu7g7UuXIA21wd6E-dKWE=.df6b26d5-97ce-40be-92ff-ff5dc2089a91@github.com> On Thu, 19 Nov 2020 12:20:47 GMT, Jeanette Winzenburg wrote: > Cleanup of LabeledSkinBase to allow for switching skins > > - removed null check in listener on graphic's layoutBounds > - added removal of listener in dispose Looks good, added a minor comment to remove a FIXME note modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 286: > 284: } > 285: } else { > 286: // FIXME: this listener must be removed in dispose! minor: the FIXME note should be removed. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/355 From aghaisas at openjdk.java.net Mon Dec 7 07:36:15 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 7 Dec 2020 07:36:15 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 17:39:08 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I tested the test program provided in the JBS on macOS 10.15.4. This PR fixes the reported issue. The side effect of brief flash when the application is launched is undesirable, but livable given the important issue this PR fixes. I spotted a typo in code comments. modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 370: > 368: @Override native protected boolean _supportsSystemMenu(); > 369: > 370: // NOTE: this will not return a valid result unil the native _runloop typo : unil -> until ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From arapte at openjdk.java.net Mon Dec 7 07:55:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Dec 2020 07:55:15 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 13:42:21 GMT, Kevin Rushforth wrote: >> This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. >> >> While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. >> >> NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Dispose JFrame after each test Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/362 From arapte at openjdk.java.net Mon Dec 7 09:33:18 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Dec 2020 09:33:18 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 14:17:21 GMT, Jeanette Winzenburg wrote: > issues with behavior: > - memory leak due to an key eventHandler that's not removed > - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed > > issues with skin: > - memory leak due to behavior leaking > - memory leak due to cellFactory in flow not removed > - throws NPE after switching (on modifying root children, refresh) due to listeners not removed > > Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. Looks good, requested a minor change. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 71: > 69: @Test > 70: public void testTreeViewSetRoot() { > 71: TreeView listView = new TreeView<>(createRoot()); minor: Please rename the variable to `treeView` in this method and others. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/358 From fastegal at openjdk.java.net Mon Dec 7 10:36:30 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 10:36:30 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin [v2] In-Reply-To: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: > Cleanup of LabeledSkinBase to allow for switching skins > > - removed null check in listener on graphic's layoutBounds > - added removal of listener in dispose Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed outdated code comment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/355/files - new: https://git.openjdk.java.net/jfx/pull/355/files/10c9f485..31b3ac08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=355&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=355&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/355.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/355/head:pull/355 PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Mon Dec 7 10:36:31 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 10:36:31 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin [v2] In-Reply-To: <-hSPCmNmhCqK7s2x56HBDfiu7g7UuXIA21wd6E-dKWE=.df6b26d5-97ce-40be-92ff-ff5dc2089a91@github.com> References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> <-hSPCmNmhCqK7s2x56HBDfiu7g7UuXIA21wd6E-dKWE=.df6b26d5-97ce-40be-92ff-ff5dc2089a91@github.com> Message-ID: On Mon, 7 Dec 2020 06:18:09 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> removed outdated code comment > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/LabeledSkinBase.java line 286: > >> 284: } >> 285: } else { >> 286: // FIXME: this listener must be removed in dispose! > > minor: the FIXME note should be removed. thanks for spotting it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Mon Dec 7 10:42:22 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 10:42:22 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: <0tfid-Bu72IK8n2Zukp2PYK0Jq5onyuK7EFGTrr0VsA=.365c2ad4-bc30-4d76-8d7e-1609f714f416@github.com> > issues with behavior: > - memory leak due to an key eventHandler that's not removed > - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed > > issues with skin: > - memory leak due to behavior leaking > - memory leak due to cellFactory in flow not removed > - throws NPE after switching (on modifying root children, refresh) due to listeners not removed > > Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: fixed c&p naming error ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/358/files - new: https://git.openjdk.java.net/jfx/pull/358/files/1275c5fb..007c6f77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=358&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=358&range=00-01 Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/358/head:pull/358 PR: https://git.openjdk.java.net/jfx/pull/358 From fastegal at openjdk.java.net Mon Dec 7 10:42:23 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 10:42:23 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 09:29:32 GMT, Ambarish Rapte wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed c&p naming error > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinCleanupTest.java line 71: > >> 69: @Test >> 70: public void testTreeViewSetRoot() { >> 71: TreeView listView = new TreeView<>(createRoot()); > > minor: Please rename the variable to `treeView` in this method and others. darn c&p - thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/358 From fastegal at openjdk.java.net Mon Dec 7 10:46:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 10:46:32 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin [v3] In-Reply-To: References: Message-ID: > issues with behavior: > - memory leak due to an key eventHandler that's not removed > - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed > > issues with skin: > - memory leak due to behavior leaking > - memory leak due to cellFactory in flow not removed > - throws NPE after switching (on modifying root children, refresh) due to listeners not removed > > Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: rename for consistency ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/358/files - new: https://git.openjdk.java.net/jfx/pull/358/files/007c6f77..6609cd51 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=358&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=358&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/358/head:pull/358 PR: https://git.openjdk.java.net/jfx/pull/358 From arapte at openjdk.java.net Mon Dec 7 13:03:17 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Dec 2020 13:03:17 GMT Subject: RFR: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin [v3] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 10:46:32 GMT, Jeanette Winzenburg wrote: >> issues with behavior: >> - memory leak due to an key eventHandler that's not removed >> - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed >> >> issues with skin: >> - memory leak due to behavior leaking >> - memory leak due to cellFactory in flow not removed >> - throws NPE after switching (on modifying root children, refresh) due to listeners not removed >> >> Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > rename for consistency Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/358 From arapte at openjdk.java.net Mon Dec 7 13:04:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Dec 2020 13:04:13 GMT Subject: RFR: 8247576: Labeled/SkinBase: misbehavior on switching skin [v2] In-Reply-To: References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: On Mon, 7 Dec 2020 10:36:30 GMT, Jeanette Winzenburg wrote: >> Cleanup of LabeledSkinBase to allow for switching skins >> >> - removed null check in listener on graphic's layoutBounds >> - added removal of listener in dispose > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed outdated code comment Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Mon Dec 7 13:09:14 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 13:09:14 GMT Subject: Integrated: 8247576: Labeled/SkinBase: misbehavior on switching skin In-Reply-To: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> References: <0LsFGBvfeLRPXtxNIbb6b5mbH4ZyFZdbfxdiia5GBNs=.0853e15f-6a1e-475f-ad99-00d09bfcb0c8@github.com> Message-ID: <9H7NNUSnc1hD6-LfKtC7a9QnpmmNSB-j4DCAee11PRI=.9d58b911-65c3-4fe6-81bd-1e6ddf48f867@github.com> On Thu, 19 Nov 2020 12:20:47 GMT, Jeanette Winzenburg wrote: > Cleanup of LabeledSkinBase to allow for switching skins > > - removed null check in listener on graphic's layoutBounds > - added removal of listener in dispose This pull request has now been integrated. Changeset: 00a8646c Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/00a8646c Stats: 146 lines in 2 files changed: 145 ins; 0 del; 1 mod 8247576: Labeled/SkinBase: misbehavior on switching skin Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/355 From fastegal at openjdk.java.net Mon Dec 7 13:10:14 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 7 Dec 2020 13:10:14 GMT Subject: Integrated: 8256821: TreeViewSkin/Behavior: misbehavior on switching skin In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 14:17:21 GMT, Jeanette Winzenburg wrote: > issues with behavior: > - memory leak due to an key eventHandler that's not removed > - after dispose, still modifying treeView (anchor) state due to listeners selection that are not removed > > issues with skin: > - memory leak due to behavior leaking > - memory leak due to cellFactory in flow not removed > - throws NPE after switching (on modifying root children, refresh) due to listeners not removed > > Fixed by cleaning up as needed. Added tests that are failing before and passing after the fix. This pull request has now been integrated. Changeset: ca0d3d0f Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/ca0d3d0f Stats: 158 lines in 6 files changed: 142 ins; 13 del; 3 mod 8256821: TreeViewSkin/Behavior: misbehavior on switching skin Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/358 From kcr at openjdk.java.net Mon Dec 7 14:06:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Dec 2020 14:06:26 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: References: Message-ID: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: fix typos in comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/361/files - new: https://git.openjdk.java.net/jfx/pull/361/files/e7de442c..dc31f0bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=361&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=361&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/361.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/361/head:pull/361 PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Mon Dec 7 14:06:27 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Dec 2020 14:06:27 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v2] In-Reply-To: References: Message-ID: <---fwJWmYnatu78Uz3WzSwNMrbCmSjYXhNGHswBDBxw=.2b269c34-2f8f-4392-90a7-2742f251d392@github.com> On Mon, 7 Dec 2020 05:31:23 GMT, Ajit Ghaisas wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java line 370: > >> 368: @Override native protected boolean _supportsSystemMenu(); >> 369: >> 370: // NOTE: this will not return a valid result unil the native _runloop > > typo : unil -> until Thanks for catching this. Fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From jvos at openjdk.java.net Mon Dec 7 14:26:15 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 7 Dec 2020 14:26:15 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 14:06:26 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > fix typos in comments Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From aghaisas at openjdk.java.net Mon Dec 7 14:50:15 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 7 Dec 2020 14:50:15 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 14:06:26 GMT, Kevin Rushforth wrote: >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > fix typos in comments Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From kcr at openjdk.java.net Mon Dec 7 15:33:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Dec 2020 15:33:11 GMT Subject: Integrated: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: > This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. > > JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). > > The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. > > I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). > > I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. > > The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. This pull request has now been integrated. Changeset: e7dbdfcb Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e7dbdfcb Stats: 109 lines in 4 files changed: 94 ins; 0 del; 15 mod 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina Reviewed-by: jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From nmrview at mac.com Mon Dec 7 15:58:31 2020 From: nmrview at mac.com (Bruce Johnson) Date: Mon, 7 Dec 2020 10:58:31 -0500 Subject: Integrated: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina In-Reply-To: References: Message-ID: <52052143-B2E2-44CA-919F-EC358C40ACB8@mac.com> > On Dec 7, 2020, at 10:33 AM, Kevin Rushforth wrote: > > On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: > >> This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. >> >> JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). >> >> The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. >> >> I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). >> >> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. >> >> The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. > > This pull request has now been integrated. > > Changeset: e7dbdfcb > Author: Kevin Rushforth > URL: https://git.openjdk.java.net/jfx/commit/e7dbdfcb > Stats: 109 lines in 4 files changed: 94 ins; 0 del; 15 mod > > 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina > > Reviewed-by: jvos, aghaisas > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/361 It would be useful, at least to me, to see a brief comment in this email thread about why this approach (which results in the application flashing) is necessary. Why does JavaFX require this approach, or is there an alternative, but more complex approach that could ultimately be used in later releases. I?d just like to be able to look back in the email thread when I (or the users of my software) see the flash to understand why it's there. Bruce From kcr at openjdk.java.net Mon Dec 7 16:24:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Dec 2020 16:24:12 GMT Subject: RFR: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina [v3] In-Reply-To: References: Message-ID: <469WSEqGhPucVTAr4CbRZuAW6AP0qc6ifpJaHqtx8t8=.7b9589bf-af11-41c0-a381-d39f7d765fa8@github.com> On Mon, 7 Dec 2020 14:47:42 GMT, Ajit Ghaisas wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typos in comments > > Marked as reviewed by aghaisas (Reviewer). I don't yet know whether there is an alternative that would allow the menubar to work without deactivating the app, but I filed a follow-up bug to track this: [JDK-8257835](https://bugs.openjdk.java.net/browse/JDK-8257835): Brief flash in terminal window when launching FX app on macOS It seems like it might be possible to fix this, since AWT initialization doesn't run into this. I note that AWT uses an Apple-provided "JavaRuntime Support" (JRS) Framework. We would need to see whether there is something else possible using public macOS APIs. ------------- PR: https://git.openjdk.java.net/jfx/pull/361 From psadhukhan at openjdk.java.net Tue Dec 8 08:23:17 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 8 Dec 2020 08:23:17 GMT Subject: RFR: 8231372: JFXPanel fails to render if setScene called on Swing thread [v2] In-Reply-To: References: Message-ID: On Sat, 5 Dec 2020 13:42:21 GMT, Kevin Rushforth wrote: >> This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. >> >> While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. >> >> NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Dispose JFrame after each test Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/362 From jvos at openjdk.java.net Tue Dec 8 11:04:17 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 8 Dec 2020 11:04:17 GMT Subject: RFR: 8257758: Allow building of JavaFX native libs for Apple Silicon Message-ID: Fix for JDK-8257758 In case the -PtargetArch=arm64 option is supplied to the gradle build, the native components that are part of the JavaFX build will target this platform. ------------- Commit messages: - Allow to build an arm64-macos build Changes: https://git.openjdk.java.net/jfx/pull/363/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=363&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257758 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/363.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/363/head:pull/363 PR: https://git.openjdk.java.net/jfx/pull/363 From kcr at openjdk.java.net Tue Dec 8 15:22:12 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 15:22:12 GMT Subject: Integrated: 8231372: JFXPanel fails to render if setScene called on Swing thread In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 02:07:37 GMT, Kevin Rushforth wrote: > This fix was originally proposed by @mruzicka in PR #16 which was closed several months ago without being integrated. At the time we didn't have a test case that was failing. > > While evaluating a bug that I filed, [JDK-8235843](https://bugs.openjdk.java.net/browse/JDK-8235843), I discovered that that bug was a duplicate of this one. The original proposed fix is correct, although I modified it slightly to add a try / finally so that the secondary event loop will be terminated even if the setScene throws an exception. I also added a unit test. Since the bulk of the fix is from PR #16, I will add the contributor of that PR. > > NOTE to reviewers: I pushed two commits to my branch. The first is exactly the commit created for PR #16 and the second is the unit test along with the fix to the code to add try / finally. As always, they will be squashed into a single commit by Skara. This pull request has now been integrated. Changeset: 794ffc09 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/794ffc09 Stats: 73 lines in 2 files changed: 66 ins; 1 del; 6 mod 8231372: JFXPanel fails to render if setScene called on Swing thread Correctly terminate secondary event loop in JFXPanel::setScene Co-authored-by: Michal R??i?ka Reviewed-by: psadhukhan, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/362 From jpereda at openjdk.java.net Tue Dec 8 16:35:41 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 8 Dec 2020 16:35:41 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 Message-ID: This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. ------------- Commit messages: - Initialize scene of embedded windows before updating output scales, including test Changes: https://git.openjdk.java.net/jfx/pull/364/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=364&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257719 Stats: 180 lines in 2 files changed: 179 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/364/head:pull/364 PR: https://git.openjdk.java.net/jfx/pull/364 From ajoseph at openjdk.java.net Tue Dec 8 17:34:20 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Tue, 8 Dec 2020 17:34:20 GMT Subject: RFR: 8257897: Fix webkit build for XCode 12 Message-ID: The WebKit build fails with recent Xcode 12. Bug: `getVTablePointer()` should return a const void* Fix: Use const void* and remove dependency on JavaVM.framework in Xcode Upstream fix: https://bugs.webkit.org/show_bug.cgi?id=207871 Test: Build webkit with the Xcode 12 compiler with and without this fix. It should fail without the fix and build with the fix. ------------- Commit messages: - 8257897: Fix webkit build for XCode 12 Changes: https://git.openjdk.java.net/jfx/pull/365/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=365&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257897 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/365.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/365/head:pull/365 PR: https://git.openjdk.java.net/jfx/pull/365 From kcr at openjdk.java.net Tue Dec 8 20:10:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 20:10:39 GMT Subject: RFR: 8256983: GitHub actions: specify the version of each platform OS and compiler Message-ID: <72GulK0MBpDIdrzwJYVXEPH5rWA3-TbclpqI3BoFX4U=.87506b41-f230-4885-be08-fb2d5140874a@github.com> As described in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8256983), we should specify the specific version of each OS and compiler rather than just using the defaults. This will help insulate us from changes to the defaults that can break the build, and has recently done so. On Linux, we upgraded to 20.04 (18.04 is still the default), which required specifying the version of ant, since the default version for 20.04 is 1.10.7 which has a bug that causes FX apps to fail. I decided to also specify the version of ant (1.10.5) for all three platforms. The following will be used: | Platform | OS | Compiler | Ant | | --- | --- | --- | --- | | Linux | Ubuntu 20.04 | gcc 10.2 | ant 1.10.5 | | Mac | macOS 10.15 | Xcode 11.3.1 | ant 1.10.5 | | Windows | Windows Server 2019 | [1] | ant 1.10.5 | [1] The Microsoft compiler version is unspecified as there is a dependency on [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) in addition to the problem of increasing the build time to download a specific version. ------------- Commit messages: - 8256983: GitHub actions: specify the version of each platform OS and compiler Changes: https://git.openjdk.java.net/jfx/pull/366/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256983 Stats: 46 lines in 1 file changed: 34 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/366.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/366/head:pull/366 PR: https://git.openjdk.java.net/jfx/pull/366 From kcr at openjdk.java.net Tue Dec 8 20:49:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 20:49:36 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:29:52 GMT, Jose Pereda wrote: > This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. > > A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. Looks good with one minor comment. tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelHiDPITest.java line 166: > 164: } > 165: > 166: } Minor: missing newline at end of file ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/364 From kcr at openjdk.java.net Tue Dec 8 21:08:36 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 21:08:36 GMT Subject: RFR: 8257758: Allow building of JavaFX native libs for Apple Silicon In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:00:43 GMT, Johan Vos wrote: > Fix for JDK-8257758 > > In case the -PtargetArch=arm64 option is supplied to the gradle build, the > native components that are part of the JavaFX build will target this platform. I haven't tested it yet. I made a naming suggestion, but otherwise looks OK. buildSrc/mac.gradle line 32: > 30: > 31: def TARGET_ARCH = "x86_64" > 32: if (hasProperty('targetArch')) { Normally, our external gradle properties are all upper-case, so `TARGET_ARCH` might be a better name for the property and `targetArch` a better name for the local variable. buildSrc/mac.gradle line 130: > 128: > 129: if (hasProperty('targetArch')) { > 130: commonParams = ["-target", "$TARGET_ARCH-apple-macos-11", commonParams] Maybe surround the variable with curly braces to make it clearer? ------------- PR: https://git.openjdk.java.net/jfx/pull/363 From jpereda at openjdk.java.net Tue Dec 8 21:34:46 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 8 Dec 2020 21:34:46 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v2] In-Reply-To: References: Message-ID: > This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. > > A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add new line at the end of the test file ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/364/files - new: https://git.openjdk.java.net/jfx/pull/364/files/8c81e317..4eb1ace5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=364&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=364&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/364/head:pull/364 PR: https://git.openjdk.java.net/jfx/pull/364 From kcr at openjdk.java.net Tue Dec 8 21:46:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 21:46:33 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 21:34:46 GMT, Jose Pereda wrote: >> This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. >> >> A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add new line at the end of the test file Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/364 From kcr at openjdk.java.net Tue Dec 8 23:18:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Dec 2020 23:18:32 GMT Subject: RFR: 8257897: Fix webkit build for XCode 12 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 17:29:56 GMT, Arun Joseph wrote: > The WebKit build fails with recent Xcode 12. > > Bug: `getVTablePointer()` should return a const void* > > Fix: Use const void* and remove dependency on JavaVM.framework in Xcode > Upstream fix: https://bugs.webkit.org/show_bug.cgi?id=207871 > > Test: Build webkit with the Xcode 12 compiler with and without this fix. It should fail without the fix and build with the fix. Looks good. I tested it with both Xcode 11.3.1 and Xcode 12.2. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/365 From ajoseph at openjdk.java.net Wed Dec 9 02:54:33 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 9 Dec 2020 02:54:33 GMT Subject: Integrated: 8257897: Fix webkit build for XCode 12 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 17:29:56 GMT, Arun Joseph wrote: > The WebKit build fails with recent Xcode 12. > > Bug: `getVTablePointer()` should return a const void* > > Fix: Use const void* and remove dependency on JavaVM.framework in Xcode > Upstream fix: https://bugs.webkit.org/show_bug.cgi?id=207871 > > Test: Build webkit with the Xcode 12 compiler with and without this fix. It should fail without the fix and build with the fix. This pull request has now been integrated. Changeset: 7fa02fe2 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/7fa02fe2 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod 8257897: Fix webkit build for XCode 12 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/365 From jvos at openjdk.java.net Wed Dec 9 12:52:49 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Dec 2020 12:52:49 GMT Subject: RFR: 8257758: Allow building of JavaFX native libs for Apple Silicon [v2] In-Reply-To: References: Message-ID: <8p91Ln8Gqy4fXgKffaR8jEHpg7l7j1BeJP6KZOkmEt0=.4411dd95-66af-4cc2-9175-9fcc7ec9efdc@github.com> > Fix for JDK-8257758 > > In case the -PtargetArch=arm64 option is supplied to the gradle build, the > native components that are part of the JavaFX build will target this platform. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/363/files - new: https://git.openjdk.java.net/jfx/pull/363/files/1e695699..36becd31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=363&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=363&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/363.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/363/head:pull/363 PR: https://git.openjdk.java.net/jfx/pull/363 From jvos at openjdk.java.net Wed Dec 9 15:03:36 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Dec 2020 15:03:36 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v2] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 21:34:46 GMT, Jose Pereda wrote: >> This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. >> >> A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add new line at the end of the test file tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelHiDPITest.java line 68: > 66: private static MyApp myApp; > 67: > 68: private static final double SCALE = 1.25; // 1.25, 1.5, 1.75 Can you add some explanation on these values? Why are the other commented values there? ------------- PR: https://git.openjdk.java.net/jfx/pull/364 From jpereda at openjdk.java.net Wed Dec 9 15:38:46 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 9 Dec 2020 15:38:46 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v3] In-Reply-To: References: Message-ID: > This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. > > A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Add comment to test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/364/files - new: https://git.openjdk.java.net/jfx/pull/364/files/4eb1ace5..34862492 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=364&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=364&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/364/head:pull/364 PR: https://git.openjdk.java.net/jfx/pull/364 From jvos at openjdk.java.net Wed Dec 9 15:38:46 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Dec 2020 15:38:46 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v3] In-Reply-To: References: Message-ID: <0NgK0APw4BvugQgIhDjLDL0XhoO8_v1FxGldnzZzx44=.5614db93-3c89-4d9d-971a-8a9740fb22e5@github.com> On Wed, 9 Dec 2020 15:36:19 GMT, Jose Pereda wrote: >> This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. >> >> A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to test Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/364 From kcr at openjdk.java.net Wed Dec 9 15:38:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Dec 2020 15:38:47 GMT Subject: RFR: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 [v3] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 15:36:19 GMT, Jose Pereda wrote: >> This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. >> >> A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to test Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/364 From jpereda at openjdk.java.net Wed Dec 9 15:51:34 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 9 Dec 2020 15:51:34 GMT Subject: Integrated: 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:29:52 GMT, Jose Pereda wrote: > This PR fixes a regression introduced in [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592), where scene initialization was moved after updating output scales. However, in case of embedded windows (used by `JFXPanel` or `FXCanvas`), the scene has to be initialized before. > > A test has been included. Before applying the fix, the JFXPanel is rendered with a garbled image, and after the fix, the rendering is correct. This pull request has now been integrated. Changeset: 1a8652af Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/1a8652af Stats: 184 lines in 2 files changed: 183 ins; 0 del; 1 mod 8257719: JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/364 From kcr at openjdk.java.net Wed Dec 9 17:05:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Dec 2020 17:05:37 GMT Subject: RFR: 8257758: Allow building of JavaFX native libs for Apple Silicon [v2] In-Reply-To: <8p91Ln8Gqy4fXgKffaR8jEHpg7l7j1BeJP6KZOkmEt0=.4411dd95-66af-4cc2-9175-9fcc7ec9efdc@github.com> References: <8p91Ln8Gqy4fXgKffaR8jEHpg7l7j1BeJP6KZOkmEt0=.4411dd95-66af-4cc2-9175-9fcc7ec9efdc@github.com> Message-ID: On Wed, 9 Dec 2020 12:52:49 GMT, Johan Vos wrote: >> Fix for JDK-8257758 >> >> In case the -PtargetArch=arm64 option is supplied to the gradle build, the >> native components that are part of the JavaFX build will target this platform. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > process reviewer comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/363 From jvos at openjdk.java.net Wed Dec 9 20:24:33 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Dec 2020 20:24:33 GMT Subject: Integrated: 8257758: Allow building of JavaFX native libs for Apple Silicon In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 11:00:43 GMT, Johan Vos wrote: > Fix for JDK-8257758 > > In case the -PtargetArch=arm64 option is supplied to the gradle build, the > native components that are part of the JavaFX build will target this platform. This pull request has now been integrated. Changeset: e1adfa91 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/e1adfa91 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8257758: Allow building of JavaFX native libs for Apple Silicon Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/363 From johan.vos at gluonhq.com Thu Dec 10 13:43:22 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 10 Dec 2020 14:43:22 +0100 Subject: Request to backport issue to JavaFX 11 Message-ID: Hi Kevin, I request permission to backport the following issue to JavaFX 11 (for 11.0.10) JDK-8257719:JFXPanel scene fails to render correctly on HiDPI after fix for JDK-8199592 - Johan From kevin.rushforth at oracle.com Thu Dec 10 14:00:03 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 10 Dec 2020 06:00:03 -0800 Subject: Request to backport issue to JavaFX 11 In-Reply-To: References: Message-ID: <088afa59-9521-8365-d4eb-a8d4ff47503c@oracle.com> +1 On 12/10/2020 5:43 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issue to JavaFX 11 (for > 11.0.10) > JDK-8257719:JFXPanel scene fails to render correctly on HiDPI after fix for > JDK-8199592 > > - Johan From github.com+1413266+jgneff at openjdk.java.net Fri Dec 11 20:31:12 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 11 Dec 2020 20:31:12 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux [v2] In-Reply-To: References: Message-ID: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. > > MonocleGLFactory.c > ... > #include > #include "eglUtils.h" > > #include "../PrismES2Defs.h" > > #include "com_sun_prism_es2_MonocleGLContext.h" > #ifndef ANDROID > #define __USE_GNU > #include > #endif > ... > > The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. > > $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log > . opt/vc/include/EGL/egl.h > ...... usr/include/dlfcn.h > ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h > . monocle/eglUtils.h > > For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into RTLD_DEFAULT - 8256012: Fix build of Monocle for Linux ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/350/files - new: https://git.openjdk.java.net/jfx/pull/350/files/9ae62088..d3a8f0d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=350&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=350&range=00-01 Stats: 6258 lines in 33 files changed: 898 ins; 5253 del; 107 mod Patch: https://git.openjdk.java.net/jfx/pull/350.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/350/head:pull/350 PR: https://git.openjdk.java.net/jfx/pull/350 From github.com+1413266+jgneff at openjdk.java.net Fri Dec 11 20:48:11 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 11 Dec 2020 20:48:11 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux [v3] In-Reply-To: References: Message-ID: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. > > MonocleGLFactory.c > ... > #include > #include "eglUtils.h" > > #include "../PrismES2Defs.h" > > #include "com_sun_prism_es2_MonocleGLContext.h" > #ifndef ANDROID > #define __USE_GNU > #include > #endif > ... > > The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. > > $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log > . opt/vc/include/EGL/egl.h > ...... usr/include/dlfcn.h > ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h > . monocle/eglUtils.h > > For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Move fix to the ARM build file instead of the code ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/350/files - new: https://git.openjdk.java.net/jfx/pull/350/files/d3a8f0d0..2d044e75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=350&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=350&range=01-02 Stats: 10 lines in 2 files changed: 6 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/350.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/350/head:pull/350 PR: https://git.openjdk.java.net/jfx/pull/350 From jvos at openjdk.java.net Fri Dec 11 21:00:58 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 11 Dec 2020 21:00:58 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux [v3] In-Reply-To: References: Message-ID: <9G95nBfERuPcdxO3NFBSlkzF-GBjZqK3v854JnKU13g=.dc99baf9-8509-4751-bee7-9fa4ee8b4181@github.com> On Fri, 11 Dec 2020 20:48:11 GMT, John Neffenger wrote: >> This pull request fixes the error when building embedded JavaFX for Linux. >> >> The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. >> >> MonocleGLFactory.c >> ... >> #include >> #include "eglUtils.h" >> >> #include "../PrismES2Defs.h" >> >> #include "com_sun_prism_es2_MonocleGLContext.h" >> #ifndef ANDROID >> #define __USE_GNU >> #include >> #endif >> ... >> >> The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. >> >> $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log >> . opt/vc/include/EGL/egl.h >> ...... usr/include/dlfcn.h >> ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h >> . monocle/eglUtils.h >> >> For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: >> >> * ['RTLD_NEXT' undeclared][1] >> * [_GNU_SOURCE and __USE_GNU][2] >> >> [1]: https://stackoverflow.com/q/1777397 >> [2]: https://stackoverflow.com/q/7296963 > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Move fix to the ARM build file instead of the code Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From jvos at openjdk.java.net Fri Dec 11 21:07:56 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 11 Dec 2020 21:07:56 GMT Subject: RFR: 8256012: Fix build of Monocle for Linux In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 23:13:48 GMT, John Neffenger wrote: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. > > MonocleGLFactory.c > ... > #include > #include "eglUtils.h" > > #include "../PrismES2Defs.h" > > #include "com_sun_prism_es2_MonocleGLContext.h" > #ifndef ANDROID > #define __USE_GNU > #include > #endif > ... > > The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. > > $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log > . opt/vc/include/EGL/egl.h > ...... usr/include/dlfcn.h > ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h > . monocle/eglUtils.h > > For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 @jgneff this looks good to be merged now. You can integrate it and then I will sponsor this. ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From github.com+1413266+jgneff at openjdk.java.net Fri Dec 11 21:51:54 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 11 Dec 2020 21:51:54 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2] In-Reply-To: References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> Message-ID: On Tue, 29 Sep 2020 19:47:54 GMT, John Neffenger wrote: >> I don't have access to a Pi right now, so I can't test this (I'll be able to test in about 10 days from now though) > > @johanvos, would you mind approving this pull request again? It looks as if the *ready* label was removed when I merged the master branch. All of the tests I ran this week worked as expected and are described below. > > ### Tests > > I ran additional tests on the following devices after merging the master branch: > > * Kobo Touch Model N905C, > * Kobo Glo HD Model N437, and > * Raspberry Pi 2 Model B. > > I ran the tests: > > * without this fix and without the workaround, > * with this fix but without the workaround, > * with this fix and with the workaround (representing this pull request). > > The workaround is the code in `EPDInputDeviceRegistry.createDevice` that lets the current JavaFX 15 release avoid the problem even without this fix. The goal of this pull request is to be able eventually to remove the `EPDInputDeviceRegistry` subclass entirely. > > The test results are shown below. The system call trace was captured with the following command using the [epd-javafx][1] application. > > $ sudo strace -f -e trace=open,openat,close -o strace.log \ > bin/run.sh --pattern=3 --loops=1 > > **Note:** In the messages below from the kernel ring buffer, the final two lines with `zforce_i2c_close` and `Deactivate` are printed when the program terminates. That call made by the kernel on behalf of the program is not recorded in the program's system call trace. > > ### Kobo Touch Model N905C > > This device has the "command overrun" bug. > > #### Without fix, without workaround > > The system call trace shows: > > 3576 open("/dev/input/event1", O_RDONLY) = 12 > 3576 close(12) = 0 > 3576 open("/dev/input/event1", O_RDONLY) = 12 > > The error occurs, and the touchscreen is disabled: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() > [zForce_ir_touch_recv_data-145] command Activate (0) ... > [zForce_ir_touch_recv_data-154] command Resolution (0) ... > [zForce_ir_touch_recv_data-179] command Frequency (0) ... > [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() > [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() > [zForce_ir_touch_recv_data-142] command Deactivate ... > [zForce_ir_touch_recv_data-198] command overrun (8) ... > [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() > [zForce_ir_touch_recv_data-142] command Deactivate ... > > #### With fix, without workaround > > The system call trace shows: > > 3997 open("/dev/input/event1", O_RDONLY) = 12 > 3997 open("/dev/input/event1", O_RDONLY) = 13 > 3997 close(13) = 0 > > The error does not occur, and the touchscreen works as expected: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() > [zForce_ir_touch_recv_data-145] command Activate (0) ... > [zForce_ir_touch_recv_data-154] command Resolution (0) ... > [zForce_ir_touch_recv_data-179] command Frequency (0) ... > [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() > [zForce_ir_touch_recv_data-142] command Deactivate ... > > #### With fix, with workaround > > The system call trace shows the additional *open* call due to the workaround: > > 4123 open("/dev/input/event1", O_RDONLY) = 13 > 4123 open("/dev/input/event1", O_RDONLY) = 14 > 4123 open("/dev/input/event1", O_RDONLY) = 15 > 4123 close(15) = 0 > > The error does not occur, and the touchscreen works as expected: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() > [zForce_ir_touch_recv_data-145] command Activate (0) ... > [zForce_ir_touch_recv_data-154] command Resolution (0) ... > [zForce_ir_touch_recv_data-179] command Frequency (0) ... > [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() > [zForce_ir_touch_recv_data-142] command Deactivate ... > > ### Kobo Glo HD Model N437 > > This device does not have the "command overrun" bug. > > #### Without fix, without workaround > > The system call trace shows: > > 3396 open("/dev/input/event1", O_RDONLY) = 11 > 3396 close(11) = 0 > 3396 open("/dev/input/event1", O_RDONLY) = 11 > > The error does not occur, and the touchscreen works as expected: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() > [zForce_ir_touch_recv_data-233] command Activate (0) ... > ... > [zForce_ir_touch_recv_data-250] command Resolution (0) ... > [zForce_ir_touch_recv_data-278] command Frequency (0) ... > [zForce_ir_touch_recv_data-260] command Configuration ... > [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() > [zForce_ir_touch_recv_data-230] command Deactivate ... > > #### With fix, without workaround > > The system call trace shows: > > 3620 open("/dev/input/event1", O_RDONLY) = 15 > 3620 open("/dev/input/event1", O_RDONLY) = 16 > 3620 close(16) = 0 > > The error does not occur, and the touchscreen works as expected: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() > [zForce_ir_touch_recv_data-233] command Activate (0) ... > ... > [zForce_ir_touch_recv_data-250] command Resolution (0) ... > [zForce_ir_touch_recv_data-278] command Frequency (0) ... > [zForce_ir_touch_recv_data-260] command Configuration ... > [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() > [zForce_ir_touch_recv_data-230] command Deactivate ... > > #### With fix, with workaround > > The system call trace shows the additional *open* call due to the workaround: > > 3913 open("/dev/input/event1", O_RDONLY) = 18 > 3913 open("/dev/input/event1", O_RDONLY) = 19 > 3913 open("/dev/input/event1", O_RDONLY) = 20 > 3913 close(20) = 0 > > The error does not occur, and the touchscreen works as expected: > > $ dmesg | grep -i zforce > [drivers/input/touchscreen/zforce_i2c.c-740] zforce_i2c_open() > [zForce_ir_touch_recv_data-233] command Activate (0) ... > ... > [zForce_ir_touch_recv_data-250] command Resolution (0) ... > [zForce_ir_touch_recv_data-278] command Frequency (0) ... > [zForce_ir_touch_recv_data-260] command Configuration ... > [drivers/input/touchscreen/zforce_i2c.c-756] zforce_i2c_close() > [zForce_ir_touch_recv_data-230] command Deactivate ... > > ### Raspberry Pi 2 Model B > > This device has a normal mouse rather than a touchscreen. > > #### Without fix, without workaround > > The system call trace shows: > > 19407 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 > > There is no output to the kernel ring buffer, and the mouse (event0) works as expected. > > #### With fix, without workaround > > The system call trace shows: > > 19548 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 > > There is no output to the kernel ring buffer, and the mouse (event0) works as expected. > > #### With fix, with workaround > > The system call trace shows: > > 19802 openat(AT_FDCWD, "/dev/input/event0", O_RDONLY) = 18 > > There is no output to the kernel ring buffer, and the mouse (event0) works as expected. > > [1]: https://github.com/jgneff/epd-javafx I'm unsure of the next step for this pull request. GitHub says that it's approved, but the *openjdk* bot removed the "Ready to be integrated" label when I merged in the *master* branch back in September. Do I need to wait for its re-approval before integrating it? ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From github.com+1413266+jgneff at openjdk.java.net Fri Dec 11 22:00:54 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 11 Dec 2020 22:00:54 GMT Subject: Integrated: 8256012: Fix build of Monocle for Linux In-Reply-To: References: Message-ID: On Sat, 7 Nov 2020 23:13:48 GMT, John Neffenger wrote: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the header file has already been included at that point, and the header contains include guards to ignore subsequent attempts. > > MonocleGLFactory.c > ... > #include > #include "eglUtils.h" > > #include "../PrismES2Defs.h" > > #include "com_sun_prism_es2_MonocleGLContext.h" > #ifndef ANDROID > #define __USE_GNU > #include > #endif > ... > > The `-H` option of `gcc` prints the name of each header file used. Its output shows that `egl.h` ends up including `dlfcn.h` indirectly, but without the required macro definition. > > $ grep -e 'EGL/egl.h' -e 'eglUtils.h' -e 'dlfcn.h' headers.log > . opt/vc/include/EGL/egl.h > ...... usr/include/dlfcn.h > ....... usr/include/arm-linux-gnueabihf/bits/dlfcn.h > . monocle/eglUtils.h > > For the proposed fix, I referred to the page of the *Linux Programmer's Manual* at "`man dlsym`" which states, "The `_GNU_SOURCE` feature test macro must be defined in order to obtain the definitions of `RTLD_DEFAULT` and `RTLD_NEXT` from ``." I also used information in the following two Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 This pull request has now been integrated. Changeset: 97d655fc Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/97d655fc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256012: Fix build of Monocle for Linux Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/350 From brendandalcin at gmail.com Fri Dec 11 22:24:02 2020 From: brendandalcin at gmail.com (Brendan DalCin) Date: Fri, 11 Dec 2020 17:24:02 -0500 Subject: JFXPanel cleanup of ViewPainter.ROOT_PATHS Message-ID: Hi there, I?ve recently been having some trouble with cleanup of FX resources in a JFXPanel inside a Swing application. I'm hoping you can point me in the right direction. For some context, I?m working on a layered desktop application written entirely in Swing. The application has layers added and removed on demand by the user. As a consequence of this, layer dependencies should be cleaned up when a layer is removed to avoid memory leaks. Recently, a JFXPanel was added into one of these layers. However, I?m seeing that even when all references are cleared, the fx nodes and its dependencies can remain. This is with JavaFX 15. From debugging I?ve found that in the quantum toolkit, the ViewPainter.ROOT_PATHS still holds references. Oddly I?ve only ever been able to see the problem when a Text node is involved. The example at the bottom of this email shows the problem. To reproduce: launch the application, resize the panel, close the panel and take a heap dump. In the heap dump, you can see that the Dependency object held in the Node (NodeWithDependency) is eventually referenced by the static ViewPainter.ROOT_PATHS array. This reference seems to be linked through the properties of the Text node. This can take a few attempts to reproduce but I assume that's related to how the panel is resized. Note also that the scene in the JFXPanel is null?d out to ensure the Swing frame does not keep a reference to the fx scene. One workaround I found is to set prism.dirtyopts to false. This mitigates the problem by not using the paths. However, my impression of this property is that it should only ever be used for debugging and will cause performance degradation. So with all that said, I?m wondering if you could explain what I'm doing wrong here and/or if there is a more appropriate way to cleanup the JFXPanel in this scenario. Thanks in advance for any help. Brendan P.s. I attempted to post this last week without being subscribed to the mailing list. The message seems to be stuck awaiting moderator approval. My apologies if this shows up as a duplicate post. --- import java.util.concurrent.CountDownLatch; import javafx.application.Platform; import javafx.embed.swing.JFXPanel; import javafx.scene.Scene; import javafx.scene.control.ScrollPane; import javafx.scene.layout.StackPane; import javafx.scene.text.Text; import javafx.scene.text.TextFlow; import javax.swing.JFrame; import javax.swing.SwingUtilities; import static javax.swing.WindowConstants.DISPOSE_ON_CLOSE; public class JFXPanelCleanup { public static void main(String[] args) { SwingUtilities.invokeLater(JFXPanelCleanup::initAndShowGUI); startKeepAliveThread(); } private static void initAndShowGUI() { JFrame frame = new JFrame(); JFXPanel jfxPanel = new CleaningFxPanel(); frame.setContentPane(jfxPanel); frame.setSize(200, 100); frame.setVisible(true); frame.setDefaultCloseOperation(DISPOSE_ON_CLOSE); Platform.runLater(() -> jfxPanel.setScene(new Scene(new NodeWithDependency(new Dependency())))); } private static void startKeepAliveThread() { new Thread(() -> { while (true) { try { //Force gc for good measure System.gc(); Thread.sleep(3_000); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } private static class CleaningFxPanel extends JFXPanel { @Override public void removeNotify() { //Set the scene to null so that the invisible JFrame does not reference the scene invokeAndWaitOnPlatform(() -> setScene(null)); super.removeNotify(); } private void invokeAndWaitOnPlatform(Runnable runnable) { CountDownLatch latch = new CountDownLatch(1); Platform.runLater(() -> { runnable.run(); latch.countDown(); }); try { latch.await(); } catch (InterruptedException e) { throw new RuntimeException(e); } } } public static class NodeWithDependency extends StackPane { private final Dependency dataDependecy; public NodeWithDependency(Dependency dependency) { this.dataDependecy = dependency; getChildren().add(new ScrollPane(new TextFlow(new Text("The quick brown fox jumps over the lazy dog")))); } } public static class Dependency { } } From kcr at openjdk.java.net Sat Dec 12 14:59:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Dec 2020 14:59:54 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Sat, 5 Dec 2020 11:33:46 GMT, Frederic Thevenet wrote: >> I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. > >> >> >> I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. > > That's great news, thanks! I spent a bit of time looking at this. I think the root cause of the problem is in ScrollPane itself. It is attempting to layout its children by doing a snap to pixel (meaning that the final scaled translation should be an integer value), but it is failing to do so. This is mostly not a problem when caching is disabled, since our text rendering does sub-pixel antialiasing that looks crisp even at non-integer boundaries. However, translating an already-rendered image by a non-integer boundary will cause the blurriness we are seeing. There is another issue with the Y translation which isn't 0 even when not using a ScrollPane. I'll continue looking at this in the coming week. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Sat Dec 12 22:34:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Dec 2020 22:34:57 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Sat, 12 Dec 2020 14:57:05 GMT, Kevin Rushforth wrote: >>> >>> >>> I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. >> >> That's great news, thanks! > > I spent a bit of time looking at this. I think the root cause of the problem is in ScrollPane itself. It is attempting to layout its children by doing a snap to pixel (meaning that the final scaled translation should be an integer value), but it is failing to do so. This is mostly not a problem when caching is disabled, since our text rendering does sub-pixel antialiasing that looks crisp even at non-integer boundaries. However, translating an already-rendered image by a non-integer boundary will cause the blurriness we are seeing. There is another issue with the Y translation which isn't 0 even when not using a ScrollPane. > > I'll continue looking at this in the coming week. One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Sat Dec 12 22:44:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Dec 2020 22:44:54 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 21:28:29 GMT, Matthias Bl?sing wrote: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run I'll plan to look at this next week. I have a general question and a comment: 1. Would it be possible to turn the test into an automated one? Possibly using some of the same techniques that the ModuleLauncherTest does? 2. All of the new files need a proper copyright header (including the new `build.gradle`). ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From github.com+2179736+matthiasblaesing at openjdk.java.net Sun Dec 13 16:09:16 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Sun, 13 Dec 2020 16:09:16 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v2] In-Reply-To: References: Message-ID: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: 8242361: Add missing copyright headers and integrate test into systemTests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/360/files - new: https://git.openjdk.java.net/jfx/pull/360/files/02ba4ed2..0281aa12 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=00-01 Stats: 447 lines in 10 files changed: 290 ins; 156 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From github.com+2179736+matthiasblaesing at openjdk.java.net Sun Dec 13 16:13:53 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Sun, 13 Dec 2020 16:13:53 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 22:41:59 GMT, Kevin Rushforth wrote: > 1. Would it be possible to turn the test into an automated one? Possibly using some of the same techniques that the ModuleLauncherTest does? Thank you for the pointer to `ModuleLauncherTest` indeed that was an inspiration for integration. I updated this PR with an integrated test. The new test is derived from the original manual test, but reworked to be automatically checkable. It was verified to fail without the fix and ran clean after. > 2. All of the new files need a proper copyright header (including the new `build.gradle`). Sorry about that - should be fixed in the updated version. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From jvos at openjdk.java.net Sun Dec 13 16:24:59 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 13 Dec 2020 16:24:59 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2] In-Reply-To: References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: On Fri, 25 Sep 2020 22:21:36 GMT, John Neffenger wrote: >> Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into zforce-command-overrun > - 8201568: zForce touchscreen input device fails when closed and immediately reopened Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From jvos at openjdk.java.net Sun Dec 13 16:25:02 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 13 Dec 2020 16:25:02 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2] In-Reply-To: References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: On Sun, 13 Dec 2020 16:21:52 GMT, Johan Vos wrote: >> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into zforce-command-overrun >> - 8201568: zForce touchscreen input device fails when closed and immediately reopened > > Marked as reviewed by jvos (Reviewer). It seems there was an additional merge commit, which didn't change your code, but it triggered a re-approval request that I missed. I re-approved it, so this should be ready to integrate. ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From chad.preisler at gmail.com Sun Dec 13 19:57:21 2020 From: chad.preisler at gmail.com (Chad Preisler) Date: Sun, 13 Dec 2020 13:57:21 -0600 Subject: Linux basic application not displaying correctly Message-ID: Hello, I'm running elementaryOS and when I use gtk3 the main window does not display correctly. When using gtk2, the main window does display correctly. Here is the command line to run with gtk2. java -Djdk.gtk.version=2 --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar Here is the command line to run with gtk3. java -Djdk.gtk.version=2 --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar I've added two screenshots. Please notice in the gtk3 one that the mouse cursor changes inside the window. I can actually change the window size from that spot. I modified glass_window.cpp and added some cout statements to print messages. The major difference I see in method WindowContextTop::process_configure the frame width and height returned from gdk_window_get_frame_extents are bigger in the gtk3 run. Here is my output from the gtk2 run: chad at chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java -Djdk.gtk.version=2 --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar Gtk-Message: 13:49:22.237: Failed to load module "canberra-gtk-module" Creating main window! POPUP2 WindowType is not TITLED set_bounds Frame extents: top 0 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_content_width 640 geometry_get_window_height 513 geometry_get_content_width 480 window_configure window_configure newWidth 640 newHeight 480 geometry_get_window_width 640 geometry_get_window_height 513 set_bounds geometry_get_window_width 640 geometry_get_window_height 513 window_configure process_configure Window is decorated frame.width 640 frame.height 480 Frame x 640 frame y 209 Frame extents: top 0 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_window_height 513 process_configure Window is decorated frame.width 640 frame.height 513 Frame x 640 frame y 209 Frame extents: top 33 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_window_height 513 process_configure Window is decorated frame.width 640 frame.height 513 Frame x 640 frame y 209 Frame extents: top 33 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_window_height 513 process_configure Window is decorated frame.width 640 frame.height 513 Frame x 640 frame y 283 Frame extents: top 33 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_window_height 513 Here is my output from the gtk3 run: chad at chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java -Djdk.gtk.version=3 --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar Creating main window! POPUP2 WindowType is not TITLED set_bounds Frame extents: top 0 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_content_width 640 geometry_get_window_height 513 geometry_get_content_width 480 window_configure window_configure newWidth 640 newHeight 480 geometry_get_window_width 640 geometry_get_window_height 513 set_bounds geometry_get_window_width 640 geometry_get_window_height 513 window_configure process_configure Window is decorated frame.width 798 frame.height 671 Frame x 561 frame y 144 Frame extents: top 0 left 0 bottom 0 right 0 geometry_get_window_width 640 geometry_get_window_height 513 I'm pretty sure this is some issue with the Window manager that elemenatryOS uses. Problem is I'm not sure where to go from here. Has anyone else experienced this? Any ideas on how to further debug this? Thanks, Chad [image: javafx_gtk2.png] [image: javafx_gtk3.png] From arapte at openjdk.java.net Mon Dec 14 06:07:54 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 14 Dec 2020 06:07:54 GMT Subject: RFR: 8256983: GitHub actions: specify the version of each platform OS and compiler In-Reply-To: <72GulK0MBpDIdrzwJYVXEPH5rWA3-TbclpqI3BoFX4U=.87506b41-f230-4885-be08-fb2d5140874a@github.com> References: <72GulK0MBpDIdrzwJYVXEPH5rWA3-TbclpqI3BoFX4U=.87506b41-f230-4885-be08-fb2d5140874a@github.com> Message-ID: On Tue, 8 Dec 2020 20:06:21 GMT, Kevin Rushforth wrote: > As described in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8256983), we should specify the specific version of each OS and compiler rather than just using the defaults. This will help insulate us from changes to the defaults that can break the build, and has recently done so. > > On Linux, we upgraded to 20.04 (18.04 is still the default), which required specifying the version of ant, since the default version for 20.04 is 1.10.7 which has a bug that causes FX apps to fail. I decided to also specify the version of ant (1.10.5) for all three platforms. > > The following will be used: > > | Platform | OS | Compiler | Ant | > | --- | --- | --- | --- | > | Linux | Ubuntu 20.04 | gcc 10.2 | ant 1.10.5 | > | Mac | macOS 10.15 | Xcode 11.3.1 | ant 1.10.5 | > | Windows | Windows Server 2019 | [1] | ant 1.10.5 | > > [1] The Microsoft compiler version is unspecified as there is a dependency on [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) in addition to the problem of increasing the build time to download a specific version. looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/366 From github.com+1413266+jgneff at openjdk.java.net Mon Dec 14 09:28:55 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 14 Dec 2020 09:28:55 GMT Subject: Integrated: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: <9lQEH9BvcztQmaAg5s6dAXLbFpoAoV6vuAas4fFltoE=.a79cf7c4-2e24-4bea-a395-71379d1fe9ab@github.com> On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). This pull request has now been integrated. Changeset: ebb59e9f Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/ebb59e9f Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod 8201568: zForce touchscreen input device fails when closed and immediately reopened Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From fthevenet at openjdk.java.net Mon Dec 14 11:20:00 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 14 Dec 2020 11:20:00 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: <0lsgGGdl2YW-GpbZYoZYQn-HcMrrGbBOpkGdy_7UMmU=.58f1d8f5-4695-430d-89da-3150ae8cc7bd@github.com> On Sat, 12 Dec 2020 22:31:56 GMT, Kevin Rushforth wrote: >> I spent a bit of time looking at this. I think the root cause of the problem is in ScrollPane itself. It is attempting to layout its children by doing a snap to pixel (meaning that the final scaled translation should be an integer value), but it is failing to do so. This is mostly not a problem when caching is disabled, since our text rendering does sub-pixel antialiasing that looks crisp even at non-integer boundaries. However, translating an already-rendered image by a non-integer boundary will cause the blurriness we are seeing. There is another issue with the Y translation which isn't 0 even when not using a ScrollPane. >> >> I'll continue looking at this in the coming week. > > One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. Further investigations on my part raised one more question, which hopefully you can answer: To which extend should `setSnapToPixel` ensure children of a region are indeed snap to whole pixel coordinates? To make it clearer, please consider the following sample: java public class Blur extends Application { @Override public void start(final Stage stage) throws Exception { var root = new Pane(); root.setSnapToPixel(true); var ctrl = new CheckBox("Cached"); ctrl.setLayoutX(0.5); ctrl.setLayoutY(0.5); ctrl.cacheProperty().bind(ctrl.selectedProperty()); ctrl.setSelected(true); var ctrl2 = new Button("Foo"); ctrl2.setLayoutX(0.5); ctrl2.setLayoutY(30.5); ctrl2.cacheProperty().bind(ctrl.selectedProperty()); var ctrl3 = new Button("Bar"); ctrl3.setLayoutY(60); ctrl3.cacheProperty().bind(ctrl.selectedProperty()); root.getChildren().addAll(ctrl, ctrl2, ctrl3); Scene scene; scene = new Scene(root, 200, 200); stage.setTitle("Blur test"); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } In this sample, LayoutX and Y properties are deliberately set to non integer values for the first two controls (the last one serves as a visual baseline, but `snapToPixel` is set to true. Also clicking the check box toggles caching for all controls. Here's what it looks looks **at 100% scaling**, (OpenJFX 15.0.1), with cache enabled: ![image](https://user-images.githubusercontent.com/7450507/102073943-57471680-3e04-11eb-95f5-753fa545a64b.png) and with cache disabled: ![image](https://user-images.githubusercontent.com/7450507/102073975-5f9f5180-3e04-11eb-97e7-41bb722241af.png) What is the legitimate result to expect here; should `root.setSnapToPixel(true);` override `setLayoutX(0.5);` and align everything for crisp rendering (as is my understanding)? Or am I misunderstanding the scope of `setSnapToPixel` and it has no effect when layout is set explicitly? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From thiago.sayao at gmail.com Mon Dec 14 11:45:58 2020 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 14 Dec 2020 08:45:58 -0300 Subject: Linux basic application not displaying correctly In-Reply-To: References: Message-ID: Hi Chad, I did not get the issue, please send the screenshots to my e-mail as they don't get through the list. One possibility: The Gtk glass backend tries to follow Windows (as in the operating system) sizes. On Windows, window sizes are the whole window, including decorations. On X (Linux) window decorations are a window manager job, so they don't count to the window size (more logical to me, as decorations can vary). Gtk backend tries to mimic that by getting decoration sizes. Your window manager seems to be not sending those. Cheers. Em dom., 13 de dez. de 2020 ?s 16:58, Chad Preisler escreveu: > Hello, > I'm running elementaryOS and when I use gtk3 the main window does not > display correctly. When using gtk2, the main window does display correctly. > > Here is the command line to run with gtk2. > > java -Djdk.gtk.version=2 > --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules > javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar > > Here is the command line to run with gtk3. > > java -Djdk.gtk.version=2 > --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules > javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar > > I've added two screenshots. Please notice in the gtk3 one that the mouse > cursor changes inside the window. I can actually change the window size > from that spot. > > I modified glass_window.cpp and added some cout statements to print > messages. The major difference I see in method > WindowContextTop::process_configure the frame width and height returned > from gdk_window_get_frame_extents are bigger in the gtk3 run. > > Here is my output from the gtk2 run: > > chad at chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java > -Djdk.gtk.version=2 --module-path="/home/chad/javafx/jfx/build/sdk/lib" > --add-modules javafx.controls,javafx.fxml -jar > target/javafxElementaryOS-1.0-SNAPSHOT.jar > Gtk-Message: 13:49:22.237: Failed to load module "canberra-gtk-module" > Creating main window! POPUP2 > WindowType is not TITLED > set_bounds > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_content_width 640 > geometry_get_window_height 513 > geometry_get_content_width 480 > window_configure > window_configure newWidth 640 newHeight 480 > geometry_get_window_width 640 > geometry_get_window_height 513 > set_bounds > geometry_get_window_width 640 > geometry_get_window_height 513 > window_configure > process_configure > Window is decorated > frame.width 640 frame.height 480 > Frame x 640 frame y 209 > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 209 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 209 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 283 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > > Here is my output from the gtk3 run: > > chad at chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java > -Djdk.gtk.version=3 --module-path="/home/chad/javafx/jfx/build/sdk/lib" > --add-modules javafx.controls,javafx.fxml -jar > target/javafxElementaryOS-1.0-SNAPSHOT.jar > Creating main window! POPUP2 > WindowType is not TITLED > set_bounds > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_content_width 640 > geometry_get_window_height 513 > geometry_get_content_width 480 > window_configure > window_configure newWidth 640 newHeight 480 > geometry_get_window_width 640 > geometry_get_window_height 513 > set_bounds > geometry_get_window_width 640 > geometry_get_window_height 513 > window_configure > process_configure > Window is decorated > frame.width 798 frame.height 671 > Frame x 561 frame y 144 > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > > I'm pretty sure this is some issue with the Window manager that > elemenatryOS uses. Problem is I'm not sure where to go from here. Has > anyone else experienced this? Any ideas on how to further debug this? > > Thanks, > Chad > [image: javafx_gtk2.png] > [image: javafx_gtk3.png] > From fthevenet at openjdk.java.net Mon Dec 14 12:08:54 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 14 Dec 2020 12:08:54 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Sat, 12 Dec 2020 22:31:56 GMT, Kevin Rushforth wrote: > > > One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. I've done some quick tests with the minimal sample below, and could not notice any performance impact with this patch compared to 15.0.1. java public class TextScroll extends Application { @Override public void start(Stage stage) throws Exception { var textArea = new TextArea(); var txt = new File(getClass().getResource("/Scrollpane.java").getFile()); textArea.setText(Files.readString(txt.toPath(), StandardCharsets.UTF_8)); var root = new ScrollPane(textArea); root.setFitToHeight(true); root.setFitToWidth(true); Scene scene; scene = new Scene(root, 800, 600); stage.setTitle("Scroll test"); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Mon Dec 14 13:13:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Dec 2020 13:13:59 GMT Subject: Integrated: 8256983: GitHub actions: specify the version of each platform OS and compiler In-Reply-To: <72GulK0MBpDIdrzwJYVXEPH5rWA3-TbclpqI3BoFX4U=.87506b41-f230-4885-be08-fb2d5140874a@github.com> References: <72GulK0MBpDIdrzwJYVXEPH5rWA3-TbclpqI3BoFX4U=.87506b41-f230-4885-be08-fb2d5140874a@github.com> Message-ID: On Tue, 8 Dec 2020 20:06:21 GMT, Kevin Rushforth wrote: > As described in the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8256983), we should specify the specific version of each OS and compiler rather than just using the defaults. This will help insulate us from changes to the defaults that can break the build, and has recently done so. > > On Linux, we upgraded to 20.04 (18.04 is still the default), which required specifying the version of ant, since the default version for 20.04 is 1.10.7 which has a bug that causes FX apps to fail. I decided to also specify the version of ant (1.10.5) for all three platforms. > > The following will be used: > > | Platform | OS | Compiler | Ant | > | --- | --- | --- | --- | > | Linux | Ubuntu 20.04 | gcc 10.2 | ant 1.10.5 | > | Mac | macOS 10.15 | Xcode 11.3.1 | ant 1.10.5 | > | Windows | Windows Server 2019 | [1] | ant 1.10.5 | > > [1] The Microsoft compiler version is unspecified as there is a dependency on [JDK-8255713](https://bugs.openjdk.java.net/browse/JDK-8255713) in addition to the problem of increasing the build time to download a specific version. This pull request has now been integrated. Changeset: f2928d95 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f2928d95 Stats: 46 lines in 1 file changed: 34 ins; 0 del; 12 mod 8256983: GitHub actions: specify the version of each platform OS and compiler Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/366 From fastegal at openjdk.java.net Mon Dec 14 14:05:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 14 Dec 2020 14:05:55 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: Message-ID: <5BmGisJBjx3yLkK3b5EjWvLwdkpG7xddwGaIW_Wrjo8=.64fe970c-7448-4d34-8bd7-455fc68e63c0@github.com> On Tue, 13 Oct 2020 15:03:26 GMT, Jeanette Winzenburg wrote: >> `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. >> The fix converts listeners to WeakListeners and also removes them on dispose. >> >> There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. >> >> `SkinMemoryLeakTest` already had a test which only needed to be enabled. >> Test fails before and passes after this change. > > no review yet, just a couple of quick comments from my experience on recent cleanup of skins: > > - if NPE checks seem to be necessary, they always indicate an illegal state: whatever a method is doing, it must not access the skin after dispose. Usually it's the caller of the method that's misbehaving, it simply must not happen. It's worth digging why _exactly_ that's happening and if/how it can be solved without guarding against the null > - while the overall memory test is already done, we still must test every single skin against side-effects (f.i. of listeners not doing any "late" update due to not being yet removed - the NPE above could well be such a case). Have a look at SkinCleanupTest for examples > - when changing listener wiring, it's often a good idea to test that they are still doing there job (if not yet covered in the available tests) > > yeah, you don't get away with not writing tests *good-humored-grinning quick question: is this still in the lane for fx16? ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From thiago.sayao at gmail.com Mon Dec 14 22:26:28 2020 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 14 Dec 2020 19:26:28 -0300 Subject: Glass backends - xGravity and yGravity Message-ID: Hi, Question: Are the xGravity and yGravity still in use? Windows glass backend seems to ignore it, and I can't think of any scenario where this would be used on Linux glass backend. package com.sun.glass.ui; public abstract class Window { ...... /** * Sets the window bounds to the specified values. * * Gravity values specify how to correct window location if only its size * changes (for example when stage decorations are added). User initiated * resizing should be ignored and must not influence window location through * this mechanism. * * The corresponding correction formulas are: * * {@code x -= xGravity * deltaW} * {@code y -= yGravity * deltaH} * * @param x the new window horizontal position, ignored if xSet is set to * false * @param y the new window vertical position, ignored if ySet is set to * false * @param xSet indicates whether the x parameter is valid * @param ySet indicates whether the y parameter is valid * @param w the new window width, ignored if set to -1 * @param h the new window height, ignored if set to -1 * @param cw the new window content width, ignored if set to -1 * @param ch the new window content height, ignored if set to -1 * @param xGravity the xGravity coefficient * @param yGravity the yGravity coefficient */ public void setBounds(float x, float y, boolean xSet, boolean ySet, float w, float h, float cw, float ch, float xGravity, float yGravity) From kcr at openjdk.java.net Mon Dec 14 23:10:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Dec 2020 23:10:01 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v2] In-Reply-To: References: Message-ID: On Sun, 13 Dec 2020 16:09:16 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > 8242361: Add missing copyright headers and integrate test into systemTests The fix looks good to me, although I want Arun to look at it, too. The test looks pretty good with a few comments that I added. modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 51: > 49: // initilization has to be done from a context where the class > 50: // com.sun.webkit.MainThread is accessible. When > 51: // scheduleDispatchFunctionsOnMainThread is invoced, the system class loader Minor typo: invoced --> invoked modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 64: > 62: // WebPage will be used by FindClass. > 63: // > 64: // WTF::initializeMainThread has a guard, so that initialization is only run I guess you meant to say "is only run __once__"? tests/system/src/test/java/test/com/sun/webkit/MainThreadTest.java line 60: > 58: final List cmd = asList( > 59: workerJavaCmd, > 60: "-cp",appModulePath + "/mymod", Minor: need space after `,` tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayer.java line 102: > 100: Platform.runLater(() -> { > 101: String title = webview.getEngine().getTitle(); > 102: if("Executed".equals(title)) { Minor: add space after `if` tests/system/src/test/java/test/com/sun/webkit/MainThreadTest.java line 40: > 38: */ > 39: public class MainThreadTest { > 40: @Test I recommend a `timeout = 15000` in case the launched application doesn't exit. tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayerLauncher.java line 63: > 61: Class testClass = moduleClassLoader.loadClass("myapp7.DataUrlWithModuleLayer"); > 62: Method launchMethod = appClass.getMethod("launch", Class.class, String[].class); > 63: launchMethod.invoke(null, new Object[]{testClass, args}); You might consider adding a `sleep(15000)` followed by `System.exit(1)` or some other mechanism to prevent running indefinitely so that if this process hangs it doesn't hang the test suite (which has happened in the past). tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayer.java line 99: > 97: @Override > 98: public void run() { > 99: while (true) { Rather than a spin loop in a new thread, it's probably better to wait for the content to be loaded (checked using a listener on `WebEngine::getLoadWorker::stateProperty`) before doing the test, which you shouldn't need to do in a loop. In any case you will want a timeout so that if this process hangs it doesn't hang the test suite, which has happened in the past. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Tue Dec 15 02:04:54 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Dec 2020 02:04:54 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Mon, 14 Dec 2020 12:06:37 GMT, Frederic Thevenet wrote: >> One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. > >> >> >> One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. > > I've done some quick tests with the minimal sample below, and could not notice any performance impact with this patch compared to 15.0.1. > > java > public class TextScroll extends Application { > > @Override > public void start(Stage stage) throws Exception { > var textArea = new TextArea(); > var txt = new File(getClass().getResource("/Scrollpane.java").getFile()); > textArea.setText(Files.readString(txt.toPath(), StandardCharsets.UTF_8)); > var root = new ScrollPane(textArea); > root.setFitToHeight(true); > root.setFitToWidth(true); > Scene scene; > scene = new Scene(root, 800, 600); > stage.setTitle("Scroll test"); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } Actually, when I mentioned smooth scrolling, it wasn't performance I was thinking of, it was the ability to scroll by fractional pixel amounts, but with the default snap-to-pixel enabled, that won't happen anyway. I'll look into the other questions you raised tomorrow, specifically what we might want to do about rendering the cache, and also your question about snapToPixel. As for the specific problem with ScrollPane, I found the cause of that one. There is a (long-standing from the look of it) bug in [`Region::updateSnappedInsets`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java#L990). It attempts to account for snap-to-pixel, but does so incorrectly, using `Math.ceil` without taking screen scaling into account (that is, without calling the `snapXxxx` methods). The correct code should be something like: final boolean snap = isSnapToPixel(); snappedTopInset = snapSizeY(insets.getTop(), snap); snappedRightInset = snapSizeX(insets.getRight(), snap); snappedBottomInset = snapSizeY(insets.getBottom(), snap); snappedLeftInset = snapSizeX(insets.getLeft(), snap); This fixes the ScrollPane problem without needing to modify the cached rendering code. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Tue Dec 15 07:53:54 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 15 Dec 2020 07:53:54 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Tue, 15 Dec 2020 02:02:37 GMT, Kevin Rushforth wrote: >>> >>> >>> One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. >> >> I've done some quick tests with the minimal sample below, and could not notice any performance impact with this patch compared to 15.0.1. >> >> java >> public class TextScroll extends Application { >> >> @Override >> public void start(Stage stage) throws Exception { >> var textArea = new TextArea(); >> var txt = new File(getClass().getResource("/Scrollpane.java").getFile()); >> textArea.setText(Files.readString(txt.toPath(), StandardCharsets.UTF_8)); >> var root = new ScrollPane(textArea); >> root.setFitToHeight(true); >> root.setFitToWidth(true); >> Scene scene; >> scene = new Scene(root, 800, 600); >> stage.setTitle("Scroll test"); >> stage.setScene(scene); >> stage.show(); >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } > > Actually, when I mentioned smooth scrolling, it wasn't performance I was thinking of, it was the ability to scroll by fractional pixel amounts, but with the default snap-to-pixel enabled, that won't happen anyway. > > I'll look into the other questions you raised tomorrow, specifically what we might want to do about rendering the cache, and also your question about snapToPixel. > > As for the specific problem with ScrollPane, I found the cause of that one. There is a (long-standing from the look of it) bug in [`Region::updateSnappedInsets`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java#L990). It attempts to account for snap-to-pixel, but does so incorrectly, using `Math.ceil` without taking screen scaling into account (that is, without calling the `snapXxxx` methods). The correct code should be something like: > > final boolean snap = isSnapToPixel(); > snappedTopInset = snapSizeY(insets.getTop(), snap); > snappedRightInset = snapSizeX(insets.getRight(), snap); > snappedBottomInset = snapSizeY(insets.getBottom(), snap); > snappedLeftInset = snapSizeX(insets.getLeft(), snap); > > This fixes the ScrollPane problem without needing to modify the cached rendering code. Thanks for that. I am wondering; is it ok to potentially address both sub-issues discussed here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be better to address them under separate issues? Speaking of which, the JBS issue title is in fact misleading, as the issue appears to be not specific to Windows; what's the best practice in such cases; rename the issue? Open a new one? Leave it as is? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Tue Dec 15 09:01:59 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 15 Dec 2020 09:01:59 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: <5BmGisJBjx3yLkK3b5EjWvLwdkpG7xddwGaIW_Wrjo8=.64fe970c-7448-4d34-8bd7-455fc68e63c0@github.com> References: <5BmGisJBjx3yLkK3b5EjWvLwdkpG7xddwGaIW_Wrjo8=.64fe970c-7448-4d34-8bd7-455fc68e63c0@github.com> Message-ID: On Mon, 14 Dec 2020 14:03:00 GMT, Jeanette Winzenburg wrote: > > > quick question: is this still in the lane for fx16? Yes, I will update PR later this week. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From kcr at openjdk.java.net Tue Dec 15 13:08:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Dec 2020 13:08:09 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh Message-ID: Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. The following changes are made: 1. Rename whitelist/blacklist to allowlist/rejectlist 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation 3. Rename local variable master in a couple places 4. Remove master from comments in a few other places This PR doesn't remove uses of the word master where there is no connotation of slavery. Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. ------------- Commit messages: - 8253356: JavaFX Terminology Refresh (part 2) - 8253356: JavaFX Terminology Refresh (part 1) Changes: https://git.openjdk.java.net/jfx/pull/368/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253356 Stats: 657 lines in 61 files changed: 228 ins; 235 del; 194 mod Patch: https://git.openjdk.java.net/jfx/pull/368.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/368/head:pull/368 PR: https://git.openjdk.java.net/jfx/pull/368 From fastegal at openjdk.java.net Tue Dec 15 14:59:54 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 15 Dec 2020 14:59:54 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: <5BmGisJBjx3yLkK3b5EjWvLwdkpG7xddwGaIW_Wrjo8=.64fe970c-7448-4d34-8bd7-455fc68e63c0@github.com> Message-ID: On Tue, 15 Dec 2020 08:59:06 GMT, Ambarish Rapte wrote: > > > > quick question: is this still in the lane for fx16? > > Yes, I will update PR later this week. cool, looking forward to it :) ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From fastegal at openjdk.java.net Tue Dec 15 14:59:56 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 15 Dec 2020 14:59:56 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 23:23:29 GMT, Kevin Rushforth wrote: >> `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. >> The fix converts listeners to WeakListeners and also removes them on dispose. >> >> There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. >> >> `SkinMemoryLeakTest` already had a test which only needed to be enabled. >> Test fails before and passes after this change. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 274: > >> 272: getSkinnable().getTabs().removeListener(weakTabsListener); >> 273: >> 274: getChildren().remove(tabHeaderArea); > > As mentioned offline, can you check whether removing `tabHeaderArea` is necessary? good question :) Just have run into a similar case while working on cleaning up TextFieldSkin. My current understanding is ... depends ;) As tests show, some children keep the skin alive, others don't. Which must imply that the first somehow keep a strong reference to the skin, the latter (nor any of its children) don't. An example for the former is tabHeaderArea, an example for the latter is tabContentRegion. Was puzzled about how to distinguish the one from the other (which boils down to finding that strong reference) - until I (faintly ;) remembered that inner classes have an implicit reference to the enclosing instance: TabHeaderArea is an inner class with an implicit reference to the enclosing skin, while TabContentRegion is static nested. As long as the former reside in the scenegraph, it makes the skin leaky. So we have to watch out for - explicit strong references from any node (down the hierarchy) to the skin - implicit strong reference to the enclosing skin class. Both groups have to be removed in dispose to prevent memory leaks. Even if not obviously leaking, children pile up when switching skin: most skins add to children, rarely set. We started a discussion of how to handle those that add [Spinner misbehavior](https://bugs.openjdk.java.net/browse/JDK-8245145) - not yet decided (personally, I didn't do anything about them in the cleanups, deferred to later ;) From today's knowledge, I would suggest to explicitly remove all direct children that the skin added to the control. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From johan.vos at gluonhq.com Tue Dec 15 15:17:46 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 15 Dec 2020 16:17:46 +0100 Subject: Request to backport issue to JavaFX 11 Message-ID: Hi Kevin, I request permission to backport JDK-8212102 ([TextField] IOOBE on paste/replace text with control characters) to JavaFX 11 (for 11.0.10). The patch applies clean. - Johan From kevin.rushforth at oracle.com Tue Dec 15 16:40:19 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Dec 2020 08:40:19 -0800 Subject: Request to backport issue to JavaFX 11 In-Reply-To: References: Message-ID: <40cb22dc-9055-78e6-4f28-37a992d5f6b0@oracle.com> +1 On 12/15/2020 7:17 AM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport JDK-8212102 ([TextField] IOOBE on > paste/replace text with control characters) to JavaFX 11 (for 11.0.10). > > The patch applies clean. > > - Johan From github.com+2179736+matthiasblaesing at openjdk.java.net Tue Dec 15 16:57:13 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 15 Dec 2020 16:57:13 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v3] In-Reply-To: References: Message-ID: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Updated according to review comments - The text and formatting was adjusted according to the raised concerns. - The test was modified with a 15000ms timeout as is the case for other tests in the systemTests project - A safeguard was added in the launched child JVM, that terminates the child after 15000ms is it did not exit normally - The detection of a successful test was moved to a ChangeLister on the load worker state. It is assumed, that the worker success state is similar to the DOMContentLoaded event. The latter is fired after synchronous javascript was executed and that would be late enough to "see" the DOM update of the title. It was validated, that the test still fails without the fix and succeeds with it. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/360/files - new: https://git.openjdk.java.net/jfx/pull/360/files/0281aa12..8e688e94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=01-02 Stats: 60 lines in 4 files changed: 32 ins; 19 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From johan.vos at gluonhq.com Tue Dec 15 20:32:18 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 15 Dec 2020 21:32:18 +0100 Subject: backport request for JavaFX 11 Message-ID: Hi Kevin, I request permission to backport the following issue to JavaFX 11 (for 11.0.10): JDK-8214397: Provide fallback to tmpdir if user home is not writable for native libs - Johan From kevin.rushforth at oracle.com Tue Dec 15 20:33:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Dec 2020 12:33:30 -0800 Subject: backport request for JavaFX 11 In-Reply-To: References: Message-ID: <16b572da-a3a1-5584-1896-a6389e416c95@oracle.com> +1 On 12/15/2020 12:32 PM, Johan Vos wrote: > Hi Kevin, > > I request permission to backport the following issue to JavaFX 11 (for > 11.0.10): > JDK-8214397: Provide fallback to tmpdir if user home is not writable for > native libs > > - Johan From kcr at openjdk.java.net Tue Dec 15 22:53:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Dec 2020 22:53:58 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 16:57:13 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Updated according to review comments > > - The text and formatting was adjusted according to the raised concerns. > - The test was modified with a 15000ms timeout as is the case for other > tests in the systemTests project > - A safeguard was added in the launched child JVM, that terminates the > child after 15000ms is it did not exit normally > - The detection of a successful test was moved to a ChangeLister on the > load worker state. It is assumed, that the worker success state is > similar to the DOMContentLoaded event. The latter is fired after > synchronous javascript was executed and that would be late enough to > "see" the DOM update of the title. > > It was validated, that the test still fails without the fix and succeeds > with it. The updates look good. Two additional comments on the test. tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayer.java line 42: > 40: public class DataUrlWithModuleLayer extends Application { > 41: public static final int ERROR_OK = 0; > 42: public static final int ERROR_ASSUMPTION_VIOLATED = 1; We usually leave 1 unused, since that is what `Process.waitFor` returns if the application fails to launch (in case that happens it will be easier for someone to diagnose). tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayer.java line 97: > 95: new ChangeListener() { > 96: public void changed(ObservableValue ov, State oldState, State newState) { > 97: String title = webview.getEngine().getTitle(); Minor: you might want to move this inside the test for `SUCCEEDED` since it isn't valid until then. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Wed Dec 16 00:27:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 00:27:59 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: On Tue, 15 Dec 2020 07:50:53 GMT, Frederic Thevenet wrote: > I am wondering; is it ok to potentially address both sub-issues discussed here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be better to address them under separate issues? Since both issues -- the snap-to-pixel bug and the rendering of the cached image -- are causing blurriness, it could be OK _in principle_ to address both of them as part of the same bug fix. However, in this instance the snap-to-pixel bug has a simple, well-understood, and safe solution, while the cached rendering bug isn't nearly as simple; there are a couple ways it could be fixed, each with their own implications. Given that, I would prefer to address the snap-to-pixel bug here (which can easily make jfx16), and file a follow-up bug for the cached rendering. > the JBS issue title is in fact misleading, as the issue appears to be not specific to Windows; what's the best practice in such cases; rename the issue? Open a new one? Leave it as is? This is easily fixed by renaming the JBS issue, and then updating the PR title to match. I'll update the JBS issue now, after which you can update the PR title. Here are some thoughts about the cached rendering, which should find their way into the new issue: Whatever we do to fix this, the end result should be that rendering a shape or control into a cache and then rendering that cached image should match rendering that shape or control directly. This should be true the first time it is rendered, and should remain true as long as the transform is unchanged (or differs only by a translation delta of whole pixel values) from when the cache was rendered into. This is clearly broken for rendering text if the translation is not on a pixel boundary. Which leads into a question you asked. > What is the legitimate result to expect here; should root.setSnapToPixel(true); override setLayoutX(0.5); and align everything for crisp rendering? Or am I misunderstanding the scope of setSnapToPixel and it has no effect when layout is set explicitly? A Pane will not force layoutX and layoutY to be on an integer boundary, since it is documented to not alter the position of any of its children. The subclasses of Pane do layout their children, so snap-to-pixel will take effect. So the fact that the controls in your most recent example are being rendered on a non-pixel boundary is not a bug. The fact that the text is so blurry when rendered from a cached image is a bug (as mentioned above). ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 16 00:37:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 00:37:59 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> Message-ID: <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> On Wed, 16 Dec 2020 00:25:15 GMT, Kevin Rushforth wrote: >> Thanks for that. >> >> I am wondering; is it ok to potentially address both sub-issues discussed here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be better to address them under separate issues? >> >> Speaking of which, the JBS issue title is in fact misleading, as the issue appears to be not specific to Windows; what's the best practice in such cases; rename the issue? Open a new one? Leave it as is? > >> I am wondering; is it ok to potentially address both sub-issues discussed here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be better to address them under separate issues? > > Since both issues -- the snap-to-pixel bug and the rendering of the cached image -- are causing blurriness, it could be OK _in principle_ to address both of them as part of the same bug fix. > > However, in this instance the snap-to-pixel bug has a simple, well-understood, and safe solution, while the cached rendering bug isn't nearly as simple; there are a couple ways it could be fixed, each with their own implications. Given that, I would prefer to address the snap-to-pixel bug here (which can easily make jfx16), and file a follow-up bug for the cached rendering. > >> the JBS issue title is in fact misleading, as the issue appears to be not specific to Windows; what's the best practice in such cases; rename the issue? Open a new one? Leave it as is? > > This is easily fixed by renaming the JBS issue, and then updating the PR title to match. I'll update the JBS issue now, after which you can update the PR title. > > Here are some thoughts about the cached rendering, which should find their way into the new issue: > > Whatever we do to fix this, the end result should be that rendering a shape or control into a cache and then rendering that cached image should match rendering that shape or control directly. This should be true the first time it is rendered, and should remain true as long as the transform is unchanged (or differs only by a translation delta of whole pixel values) from when the cache was rendered into. This is clearly broken for rendering text if the translation is not on a pixel boundary. > > Which leads into a question you asked. > >> What is the legitimate result to expect here; should root.setSnapToPixel(true); override setLayoutX(0.5); and align everything for crisp rendering? Or am I misunderstanding the scope of setSnapToPixel and it has no effect when layout is set explicitly? > > A Pane will not force layoutX and layoutY to be on an integer boundary, since it is documented to not alter the position of any of its children. The subclasses of Pane do layout their children, so snap-to-pixel will take effect. So the fact that the controls in your most recent example are being rendered on a non-pixel boundary is not a bug. The fact that the text is so blurry when rendered from a cached image is a bug (as mentioned above). For completeness, here is the patch for the snap-to-pixel issue: diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java index 565d52b516..00c0f6da61 100644 --- a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java +++ b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java @@ -989,17 +989,11 @@ public class Region extends Parent { /** Called to update the cached snapped insets */ private void updateSnappedInsets() { final Insets insets = getInsets(); - if (_snapToPixel) { - snappedTopInset = Math.ceil(insets.getTop()); - snappedRightInset = Math.ceil(insets.getRight()); - snappedBottomInset = Math.ceil(insets.getBottom()); - snappedLeftInset = Math.ceil(insets.getLeft()); - } else { - snappedTopInset = insets.getTop(); - snappedRightInset = insets.getRight(); - snappedBottomInset = insets.getBottom(); - snappedLeftInset = insets.getLeft(); - } + final boolean snap = isSnapToPixel(); + snappedTopInset = snapSizeY(insets.getTop(), snap); + snappedRightInset = snapSizeX(insets.getRight(), snap); + snappedBottomInset = snapSizeY(insets.getBottom(), snap); + snappedLeftInset = snapSizeX(insets.getLeft(), snap); } /** We will need a test case for this. You can see [UIRenderSceneTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java) for an example of a test that forces Hi-DPI scaling. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 16 00:44:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 00:44:57 GMT Subject: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling In-Reply-To: <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 00:35:08 GMT, Kevin Rushforth wrote: >>> I am wondering; is it ok to potentially address both sub-issues discussed here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be better to address them under separate issues? >> >> Since both issues -- the snap-to-pixel bug and the rendering of the cached image -- are causing blurriness, it could be OK _in principle_ to address both of them as part of the same bug fix. >> >> However, in this instance the snap-to-pixel bug has a simple, well-understood, and safe solution, while the cached rendering bug isn't nearly as simple; there are a couple ways it could be fixed, each with their own implications. Given that, I would prefer to address the snap-to-pixel bug here (which can easily make jfx16), and file a follow-up bug for the cached rendering. >> >>> the JBS issue title is in fact misleading, as the issue appears to be not specific to Windows; what's the best practice in such cases; rename the issue? Open a new one? Leave it as is? >> >> This is easily fixed by renaming the JBS issue, and then updating the PR title to match. I'll update the JBS issue now, after which you can update the PR title. >> >> Here are some thoughts about the cached rendering, which should find their way into the new issue: >> >> Whatever we do to fix this, the end result should be that rendering a shape or control into a cache and then rendering that cached image should match rendering that shape or control directly. This should be true the first time it is rendered, and should remain true as long as the transform is unchanged (or differs only by a translation delta of whole pixel values) from when the cache was rendered into. This is clearly broken for rendering text if the translation is not on a pixel boundary. >> >> Which leads into a question you asked. >> >>> What is the legitimate result to expect here; should root.setSnapToPixel(true); override setLayoutX(0.5); and align everything for crisp rendering? Or am I misunderstanding the scope of setSnapToPixel and it has no effect when layout is set explicitly? >> >> A Pane will not force layoutX and layoutY to be on an integer boundary, since it is documented to not alter the position of any of its children. The subclasses of Pane do layout their children, so snap-to-pixel will take effect. So the fact that the controls in your most recent example are being rendered on a non-pixel boundary is not a bug. The fact that the text is so blurry when rendered from a cached image is a bug (as mentioned above). > > For completeness, here is the patch for the snap-to-pixel issue: > > diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java > index 565d52b516..00c0f6da61 100644 > --- a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java > +++ b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java > @@ -989,17 +989,11 @@ public class Region extends Parent { > /** Called to update the cached snapped insets */ > private void updateSnappedInsets() { > final Insets insets = getInsets(); > - if (_snapToPixel) { > - snappedTopInset = Math.ceil(insets.getTop()); > - snappedRightInset = Math.ceil(insets.getRight()); > - snappedBottomInset = Math.ceil(insets.getBottom()); > - snappedLeftInset = Math.ceil(insets.getLeft()); > - } else { > - snappedTopInset = insets.getTop(); > - snappedRightInset = insets.getRight(); > - snappedBottomInset = insets.getBottom(); > - snappedLeftInset = insets.getLeft(); > - } > + final boolean snap = isSnapToPixel(); > + snappedTopInset = snapSizeY(insets.getTop(), snap); > + snappedRightInset = snapSizeX(insets.getRight(), snap); > + snappedBottomInset = snapSizeY(insets.getBottom(), snap); > + snappedLeftInset = snapSizeX(insets.getLeft(), snap); > } > > /** > > We will need a test case for this. You can see [UIRenderSceneTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java) for an example of a test that forces Hi-DPI scaling. In looking at the other instances where snap-to-pixel is done correctly for Insets, the above should use `snapSpace{X,Y}` rather than `snapSize{X,Y}` ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Wed Dec 16 12:38:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Dec 2020 12:38:55 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:03:53 GMT, Kevin Rushforth wrote: > Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. > > The following changes are made: > > 1. Rename whitelist/blacklist to allowlist/rejectlist > 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation > 3. Rename local variable master in a couple places > 4. Remove master from comments in a few other places > > This PR doesn't remove uses of the word master where there is no connotation of slavery. > > Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. `modules\javafx.graphics\src\main\native-glass\ios\GlassWindow.h` has declaration of variables named `masterWindow` and `masterWindowHost`. Please check if we should change these too. ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From fthevenet at openjdk.java.net Wed Dec 16 12:52:10 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 12:52:10 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v2] In-Reply-To: References: Message-ID: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. Frederic Thevenet has updated the pull request incrementally with two additional commits since the last revision: - Fixed region doesn't account for screen scalling when enforcing snap-to-pixel. - Revert "Round up the translation coordinates when rendering a cached node to screen to prevent it from appearing blurry" This reverts commit cce931d3 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/308/files - new: https://git.openjdk.java.net/jfx/pull/308/files/cce931d3..4087c062 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=00-01 Stats: 13 lines in 2 files changed: 0 ins; 6 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Wed Dec 16 12:57:57 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 12:57:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 00:42:24 GMT, Kevin Rushforth wrote: >> For completeness, here is the patch for the snap-to-pixel issue: >> >> diff --git a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java >> index 565d52b516..00c0f6da61 100644 >> --- a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java >> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java >> @@ -989,17 +989,11 @@ public class Region extends Parent { >> /** Called to update the cached snapped insets */ >> private void updateSnappedInsets() { >> final Insets insets = getInsets(); >> - if (_snapToPixel) { >> - snappedTopInset = Math.ceil(insets.getTop()); >> - snappedRightInset = Math.ceil(insets.getRight()); >> - snappedBottomInset = Math.ceil(insets.getBottom()); >> - snappedLeftInset = Math.ceil(insets.getLeft()); >> - } else { >> - snappedTopInset = insets.getTop(); >> - snappedRightInset = insets.getRight(); >> - snappedBottomInset = insets.getBottom(); >> - snappedLeftInset = insets.getLeft(); >> - } >> + final boolean snap = isSnapToPixel(); >> + snappedTopInset = snapSizeY(insets.getTop(), snap); >> + snappedRightInset = snapSizeX(insets.getRight(), snap); >> + snappedBottomInset = snapSizeY(insets.getBottom(), snap); >> + snappedLeftInset = snapSizeX(insets.getLeft(), snap); >> } >> >> /** >> >> We will need a test case for this. You can see [UIRenderSceneTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java) for an example of a test that forces Hi-DPI scaling. > > In looking at the other instances where snap-to-pixel is done correctly for Insets, the above should use `snapSpace{X,Y}` rather than `snapSize{X,Y}` I agree that it is better to separate the scrollpane issue from the cache rendering one. I've reverted my initial changes and applied the changes you proposed (using snapSpaceX/Y as suggested in your latest comment). I'll also add a test case soon. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 16 13:20:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 13:20:23 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh [v2] In-Reply-To: References: Message-ID: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> > Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. > > The following changes are made: > > 1. Rename whitelist/blacklist to allowlist/rejectlist > 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation > 3. Rename local variable master in a couple places > 4. Remove master from comments in a few other places > > This PR doesn't remove uses of the word master where there is no connotation of slavery. > > Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback: change masterWindow to mainWindow in iOS files ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/368/files - new: https://git.openjdk.java.net/jfx/pull/368/files/f7676317..08963902 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=368&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=368&range=00-01 Stats: 37 lines in 6 files changed: 0 ins; 0 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/368.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/368/head:pull/368 PR: https://git.openjdk.java.net/jfx/pull/368 From kcr at openjdk.java.net Wed Dec 16 13:20:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 13:20:23 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 12:35:34 GMT, Ambarish Rapte wrote: >> Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. >> >> The following changes are made: >> >> 1. Rename whitelist/blacklist to allowlist/rejectlist >> 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation >> 3. Rename local variable master in a couple places >> 4. Remove master from comments in a few other places >> >> This PR doesn't remove uses of the word master where there is no connotation of slavery. >> >> Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. > > `modules\javafx.graphics\src\main\native-glass\ios\GlassWindow.h` has declaration of variables named `masterWindow` and `masterWindowHost`. > Please check if we should change these too. Yes, I agree that these should be changed as well. Given the following in `GlassWindow.h`: +(GlassMainWindow *) getMasterWindow; changing `masterWindow` to `mainWindow` is a better fit anyway. ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From fthevenet at openjdk.java.net Wed Dec 16 13:26:58 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 13:26:58 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 12:55:49 GMT, Frederic Thevenet wrote: >> In looking at the other instances where snap-to-pixel is done correctly for Insets, the above should use `snapSpace{X,Y}` rather than `snapSize{X,Y}` > > I agree that it is better to separate the scrollpane issue from the cache rendering one. > > I've reverted my initial changes and applied the changes you proposed (using snapSpaceX/Y as suggested in your latest comment). > I'll also add a test case soon. I was thinking, while I'm at it I might as well update the copyright notice for Region.java; should it be 2020 or 2021 (or left alone)? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 16 13:26:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 13:26:59 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 13:17:01 GMT, Kevin Rushforth wrote: >> `modules\javafx.graphics\src\main\native-glass\ios\GlassWindow.h` has declaration of variables named `masterWindow` and `masterWindowHost`. >> Please check if we should change these too. > > Yes, I agree that these should be changed as well. Given the following in `GlassWindow.h`: > > +(GlassMainWindow *) getMasterWindow; > > changing `masterWindow` to `mainWindow` is a better fit anyway. @johanvos since this now touches iOS files, can you take a look at them (just a sanity check unless you also want to review the rest)? ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From kcr at openjdk.java.net Wed Dec 16 13:38:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 13:38:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 13:24:25 GMT, Frederic Thevenet wrote: >> I agree that it is better to separate the scrollpane issue from the cache rendering one. >> >> I've reverted my initial changes and applied the changes you proposed (using snapSpaceX/Y as suggested in your latest comment). >> I'll also add a test case soon. > > I was thinking, while I'm at it I might as well update the copyright notice for Region.java; should it be 2020 or 2021 (or left alone)? That file was modified earlier in the year without the copyright year being updated, so it will be updated by a script when @arapte implements [JDK-8254101](https://bugs.openjdk.java.net/browse/JDK-8254101) early next week. So to avoid a possible merge conflict, you can just leave it alone. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Wed Dec 16 13:38:59 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Dec 2020 13:38:59 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh [v2] In-Reply-To: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> References: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> Message-ID: On Wed, 16 Dec 2020 13:20:23 GMT, Kevin Rushforth wrote: >> Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. >> >> The following changes are made: >> >> 1. Rename whitelist/blacklist to allowlist/rejectlist >> 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation >> 3. Rename local variable master in a couple places >> 4. Remove master from comments in a few other places >> >> This PR doesn't remove uses of the word master where there is no connotation of slavery. >> >> Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback: change masterWindow to mainWindow in iOS files Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/368 From jvos at openjdk.java.net Wed Dec 16 13:39:00 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 16 Dec 2020 13:39:00 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh [v2] In-Reply-To: References: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> Message-ID: On Wed, 16 Dec 2020 13:36:13 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to feedback: change masterWindow to mainWindow in iOS files > > Looks good to me. I will look into the iOS changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From kcr at openjdk.java.net Wed Dec 16 14:55:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 14:55:57 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v3] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:51:33 GMT, Kevin Rushforth wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated according to review comments >> >> - The text and formatting was adjusted according to the raised concerns. >> - The test was modified with a 15000ms timeout as is the case for other >> tests in the systemTests project >> - A safeguard was added in the launched child JVM, that terminates the >> child after 15000ms is it did not exit normally >> - The detection of a successful test was moved to a ChangeLister on the >> load worker state. It is assumed, that the worker success state is >> similar to the DOMContentLoaded event. The latter is fired after >> synchronous javascript was executed and that would be late enough to >> "see" the DOM update of the title. >> >> It was validated, that the test still fails without the fix and succeeds >> with it. > > The updates look good. Two additional comments on the test. One more thing: can you enable GitHub actions test execution for your repo? See [this message](https://github.com/openjdk/jfx/pull/360/checks?check_run_id=1564422863) from the Skara bot. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From fthevenet at openjdk.java.net Wed Dec 16 15:35:57 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 15:35:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 13:36:27 GMT, Kevin Rushforth wrote: >> I was thinking, while I'm at it I might as well update the copyright notice for Region.java; should it be 2020 or 2021 (or left alone)? > > That file was modified earlier in the year without the copyright year being updated, so it will be updated by a script when @arapte implements [JDK-8254101](https://bugs.openjdk.java.net/browse/JDK-8254101) early next week. So to avoid a possible merge conflict, you can just leave it alone. I've been looking for other occurrences of the same issue in other places, and came across this one, in TextFlow: https://github.com/openjdk/jfx/blob/f2928d9506b928d991d7474e36bc5a0b24d3b017/modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java#L614 >From what I gather, this is likely to cause the same result. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From ajoseph at openjdk.java.net Wed Dec 16 15:44:01 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 16 Dec 2020 15:44:01 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v3] In-Reply-To: References: Message-ID: <8nf3-vscZ5by8xs5ErJSzUPLhytayQ0ZQPoB3WpbJdc=.3bc0c4d7-924e-4cb9-80a8-7256aaad6302@github.com> On Tue, 15 Dec 2020 16:57:13 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Updated according to review comments > > - The text and formatting was adjusted according to the raised concerns. > - The test was modified with a 15000ms timeout as is the case for other > tests in the systemTests project > - A safeguard was added in the launched child JVM, that terminates the > child after 15000ms is it did not exit normally > - The detection of a successful test was moved to a ChangeLister on the > load worker state. It is assumed, that the worker success state is > similar to the DOMContentLoaded event. The latter is fired after > synchronous javascript was executed and that would be late enough to > "see" the DOM update of the title. > > It was validated, that the test still fails without the fix and succeeds > with it. Fix and test looks good. Added a minor typo fix. modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line 49: > 47: { > 48: // Initialize the class reference and methodids for the MainThread. The > 49: // initilization has to be done from a context where the class initilization -> initialization ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Wed Dec 16 16:41:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 16:41:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 15:33:36 GMT, Frederic Thevenet wrote: >> That file was modified earlier in the year without the copyright year being updated, so it will be updated by a script when @arapte implements [JDK-8254101](https://bugs.openjdk.java.net/browse/JDK-8254101) early next week. So to avoid a possible merge conflict, you can just leave it alone. > > I've been looking for other occurrences of the same issue in other places, and came across this one, in TextFlow: > > https://github.com/openjdk/jfx/blob/f2928d9506b928d991d7474e36bc5a0b24d3b017/modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java#L614 > > From what I gather, this is likely to cause the same result. > > If this is indeed a bug, should we address it in the PR or open another JBS issue? Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as part of this, probably by deleting that method and using the public methods in Region. It seems wholly unnecessary to use the copied method, since the value of `snap` is always set to `isSnapPixel()`, which is what the public methods do. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Wed Dec 16 17:16:56 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 17:16:56 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: On Wed, 16 Dec 2020 16:39:37 GMT, Kevin Rushforth wrote: > > > Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as part of this, probably by deleting that method and using the public methods in Region. It seems wholly unnecessary to use the copied method, since the value of `snap` is always set to `isSnapPixel()`, which is what the public methods do. Actually I think the copy was necessary for the other methods in this delimited block: `computeChildXXXAreaWidth/Height` because members from Region are indeed inaccessible. These copies are outdated and should be updated as they use the deprecated `snapSpace()` (instead of `snapSpaceX/Y()`) which does not take into account non square screen ratio. I assume we have no other choice than copy the new versions of these from Region into TextFlow? Unless you think we have reasons to reassess why these where made package-private in the first place ? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 16 17:26:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 17:26:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> Message-ID: <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> On Wed, 16 Dec 2020 17:13:57 GMT, Frederic Thevenet wrote: >> Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as part of this, probably by deleting that method and using the public methods in Region. It seems wholly unnecessary to use the copied method, since the value of `snap` is always set to `isSnapPixel()`, which is what the public methods do. > >> >> >> Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as part of this, probably by deleting that method and using the public methods in Region. It seems wholly unnecessary to use the copied method, since the value of `snap` is always set to `isSnapPixel()`, which is what the public methods do. > > Actually I think the copy was necessary for the other methods in this delimited block: `computeChildXXXAreaWidth/Height` because members from Region are indeed inaccessible. > These copies are outdated and should be updated as they use the deprecated `snapSpace()` (instead of `snapSpaceX/Y()`) which does not take into account non square screen ratio. > > I assume we have no other choice than copy the new versions of these from Region into TextFlow? Unless you think we have reasons to reassess why these where made package-private in the first place ? Region is part of the public API, so any change to increase the visibility of fields or methods would require a new enhancement with a CSR and justification as to why it is needed as public API. We wouldn't do that just to fix this bug. Does TextFlow really need the package-scope snap methods from Region? I was thinking you would modify the copied `computeChildXXXAreaWidth/Height` methods to call the public `snapSpaceX/Y` methods (the ones that don't take `snap` as a parameter). ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Wed Dec 16 18:16:54 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 18:16:54 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Wed, 16 Dec 2020 17:24:10 GMT, Kevin Rushforth wrote: >>> >>> >>> Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as part of this, probably by deleting that method and using the public methods in Region. It seems wholly unnecessary to use the copied method, since the value of `snap` is always set to `isSnapPixel()`, which is what the public methods do. >> >> Actually I think the copy was necessary for the other methods in this delimited block: `computeChildXXXAreaWidth/Height` because members from Region are indeed inaccessible. >> These copies are outdated and should be updated as they use the deprecated `snapSpace()` (instead of `snapSpaceX/Y()`) which does not take into account non square screen ratio. >> >> I assume we have no other choice than copy the new versions of these from Region into TextFlow? Unless you think we have reasons to reassess why these where made package-private in the first place ? > > Region is part of the public API, so any change to increase the visibility of fields or methods would require a new enhancement with a CSR and justification as to why it is needed as public API. We wouldn't do that just to fix this bug. > > Does TextFlow really need the package-scope snap methods from Region? I was thinking you would modify the copied `computeChildXXXAreaWidth/Height` methods to call the public `snapSpaceX/Y` methods (the ones that don't take `snap` as a parameter). Looking the git blame, it appears the orignal and copy diverged on commit 55cf799de20b6fbf9ee31850b75c34389c8a28f2 "Baseline offset depends on layout bounds which are calculated during layout". I really can't say if TextFlow needs that as well, so I left it out and just adapted the methods as discussed above. Maybe someone more knowledgeable about font rendering and the TextFlow implementation can comment on whether or not it should be added to TextFlow (presumably in a follow up?) ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From github.com+2179736+matthiasblaesing at openjdk.java.net Wed Dec 16 18:20:14 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 16 Dec 2020 18:20:14 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v4] In-Reply-To: References: Message-ID: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Updated according to review comments - Shifted error codes of the value "1" - Move title fetching to SUCCEEDED state - Fix typo - enable github actions on contributor repository ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/360/files - new: https://git.openjdk.java.net/jfx/pull/360/files/8e688e94..2bf05e90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=02-03 Stats: 6 lines in 2 files changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From fthevenet at openjdk.java.net Wed Dec 16 18:21:10 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 18:21:10 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v3] In-Reply-To: References: Message-ID: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: computeChildArea methods in TextFlow should take screen scaling in account. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/308/files - new: https://git.openjdk.java.net/jfx/pull/308/files/4087c062..5720f03d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=01-02 Stats: 14 lines in 1 file changed: 0 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From github.com+2179736+matthiasblaesing at openjdk.java.net Wed Dec 16 18:30:13 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 16 Dec 2020 18:30:13 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v5] In-Reply-To: References: Message-ID: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Ensure that the process sentinal does not keep the JVM running ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/360/files - new: https://git.openjdk.java.net/jfx/pull/360/files/2bf05e90..c81a478d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=03-04 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Wed Dec 16 18:46:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 18:46:03 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v5] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:30:13 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Ensure that the process sentinal does not keep the JVM running tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayerLauncher.java line 44: > 42: new Thread() { > 43: { > 44: setDaemon(true); Ordinarily a good idea, but in this case it might be better without it. The only way this can matter is if there is a case where all other threads would return (thus stopping them) without any calls to `System.exit`. In that case, the earlier code would report a timeout, while the new code would exit with a normal (0) status. Not sure that's what we want. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From github.com+2179736+matthiasblaesing at openjdk.java.net Wed Dec 16 18:54:57 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 16 Dec 2020 18:54:57 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v5] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:43:33 GMT, Kevin Rushforth wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Ensure that the process sentinal does not keep the JVM running > > tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayerLauncher.java line 44: > >> 42: new Thread() { >> 43: { >> 44: setDaemon(true); > > Ordinarily a good idea, but in this case it might be better without it. The only way this can matter is if there is a case where all other threads would return (thus stopping them) without any calls to `System.exit`. In that case, the earlier code would report a timeout, while the new code would exit with a normal (0) status. Not sure that's what we want. I tested the "bad" case. That means I removed the fix and I see the segfault, but the JVM does not exit - it exists after 15s with the timeout (error code 3), but not with the expected code 134. Someone looking at a segfault problem would then get the wrong information and look at the wrong code. That is fixed by making the process reaper a daemon thread. I could add another error return at the end of myapp7.DataUrlWithModuleLayerLauncher.main(String[]). That point should only be reached when all JavaFX windows are closed or the Platform is explicitly shutdown. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Wed Dec 16 19:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 19:01:59 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v5] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 18:52:22 GMT, Matthias Bl?sing wrote: >> tests/system/src/testapp7/java/mymod/myapp7/DataUrlWithModuleLayerLauncher.java line 44: >> >>> 42: new Thread() { >>> 43: { >>> 44: setDaemon(true); >> >> Ordinarily a good idea, but in this case it might be better without it. The only way this can matter is if there is a case where all other threads would return (thus stopping them) without any calls to `System.exit`. In that case, the earlier code would report a timeout, while the new code would exit with a normal (0) status. Not sure that's what we want. > > I tested the "bad" case. That means I removed the fix and I see the segfault, but the JVM does not exit - it exists after 15s with the timeout (error code 3), but not with the expected code 134. Someone looking at a segfault problem would then get the wrong information and look at the wrong code. That is fixed by making the process reaper a daemon thread. > > I could add another error return at the end of myapp7.DataUrlWithModuleLayerLauncher.main(String[]). That point should only be reached when all JavaFX windows are closed or the Platform is explicitly shutdown. Oh, in that case, go ahead and leave it as a daemon thread. And yes, another error exit in the launcher main should handle the problem I was worried about. ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From github.com+2179736+matthiasblaesing at openjdk.java.net Wed Dec 16 19:07:17 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 16 Dec 2020 19:07:17 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v6] In-Reply-To: References: Message-ID: <3q6_fEXneRkFNzpi8iyd8jmQoiJCJkJztIQfsRsdYhE=.c9952c88-006e-48eb-a435-028a4acf2bf0@github.com> > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Ensure error code 0 is not reached by normal javafx exit ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/360/files - new: https://git.openjdk.java.net/jfx/pull/360/files/c81a478d..78571648 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=360&range=04-05 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/360.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/360/head:pull/360 PR: https://git.openjdk.java.net/jfx/pull/360 From fthevenet at openjdk.java.net Wed Dec 16 19:29:54 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 16 Dec 2020 19:29:54 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Wed, 16 Dec 2020 18:14:42 GMT, Frederic Thevenet wrote: >> Region is part of the public API, so any change to increase the visibility of fields or methods would require a new enhancement with a CSR and justification as to why it is needed as public API. We wouldn't do that just to fix this bug. >> >> Does TextFlow really need the package-scope snap methods from Region? I was thinking you would modify the copied `computeChildXXXAreaWidth/Height` methods to call the public `snapSpaceX/Y` methods (the ones that don't take `snap` as a parameter). > > Looking the git blame, it appears the orignal and copy diverged on commit 55cf799de20b6fbf9ee31850b75c34389c8a28f2 "Baseline offset depends on layout bounds which are calculated during layout". > I really can't say if TextFlow needs that as well, so I left it out and just adapted the methods as discussed above. > > Maybe someone more knowledgeable about font rendering and the TextFlow implementation can comment on whether or not it should be added to TextFlow (presumably in a follow up?) There is still a remain scaling issue, I'm afraid: snapped insets coordinates are cached after they've been computed and only updated when the inset (or a related property, such as shape or border) changes or if the snapToPixel property changes. This means that on a setup with more than one screen with different scales, when moving the application's window from one screen to the other, controls that were snapped on the first screen nor longer are once moved on the second one, and therefore appear blurry. We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call ` updateSnappedInsets`& `requestLayout` when one changes? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From jvos at openjdk.java.net Wed Dec 16 20:06:55 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 16 Dec 2020 20:06:55 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh [v2] In-Reply-To: References: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> Message-ID: On Wed, 16 Dec 2020 13:36:34 GMT, Johan Vos wrote: >> Looks good to me. > > I will look into the iOS changes. I confirm that the iOS changes do not cause regression. ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From kcr at openjdk.java.net Wed Dec 16 23:24:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Dec 2020 23:24:55 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v6] In-Reply-To: <3q6_fEXneRkFNzpi8iyd8jmQoiJCJkJztIQfsRsdYhE=.c9952c88-006e-48eb-a435-028a4acf2bf0@github.com> References: <3q6_fEXneRkFNzpi8iyd8jmQoiJCJkJztIQfsRsdYhE=.c9952c88-006e-48eb-a435-028a4acf2bf0@github.com> Message-ID: On Wed, 16 Dec 2020 19:07:17 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Ensure error code 0 is not reached by normal javafx exit Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/360 From kcr at openjdk.java.net Thu Dec 17 00:27:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 00:27:58 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Wed, 16 Dec 2020 19:25:56 GMT, Frederic Thevenet wrote: >> Looking the git blame, it appears the orignal and copy diverged on commit 55cf799de20b6fbf9ee31850b75c34389c8a28f2 "Baseline offset depends on layout bounds which are calculated during layout". >> I really can't say if TextFlow needs that as well, so I left it out and just adapted the methods as discussed above. >> >> Maybe someone more knowledgeable about font rendering and the TextFlow implementation can comment on whether or not it should be added to TextFlow (presumably in a follow up?) > > There is still a remain scaling issue, I'm afraid: snapped insets coordinates are cached after they've been computed and only updated when the inset (or a related property, such as shape or border) changes or if the snapToPixel property changes. > > This means that on a setup with more than one screen with different scales, when moving the application's window from one screen to the other, controls that were snapped on the first screen nor longer are once moved on the second one, and therefore appear blurry. > > We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call ` updateSnappedInsets`& `requestLayout` when one changes? Good point. We would need some way to invalidate the cached values if the screen scale changes. > We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call `updateSnappedInsets` & `requestLayout` when one changes? A layout will happen anyway as the result of a Window moving to another screen, so really it's only the cached snapped insets that need to be recalculated. I don't know whether a listener is the best approach, since it would need to handle the case where the Window changes (either because the scene changed or the scene was added to a new window), which would present similar challenges to what we face with treeVisible. Another possibility is for `updateSnappedInsets` to also cache the scaleX/Y at which the snapped insets were computed. The `snappedXXXXX` methods could check the current scale against the cached scale (a simple == test) and call `updateSnappedInsets` if the scale changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From ajoseph at openjdk.java.net Thu Dec 17 02:18:02 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 17 Dec 2020 02:18:02 GMT Subject: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v6] In-Reply-To: <3q6_fEXneRkFNzpi8iyd8jmQoiJCJkJztIQfsRsdYhE=.c9952c88-006e-48eb-a435-028a4acf2bf0@github.com> References: <3q6_fEXneRkFNzpi8iyd8jmQoiJCJkJztIQfsRsdYhE=.c9952c88-006e-48eb-a435-028a4acf2bf0@github.com> Message-ID: <_dwySqfsTXrXjhn7Hjgk67MLt4SMQgHqaUda-c1vwq4=.7129fd06-0bef-44e9-b231-84a02be00cd2@github.com> On Wed, 16 Dec 2020 19:07:17 GMT, Matthias Bl?sing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Ensure error code 0 is not reached by normal javafx exit Marked as reviewed by ajoseph (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From jpereda at openjdk.java.net Thu Dec 17 16:00:04 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 17 Dec 2020 16:00:04 GMT Subject: RFR: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels Message-ID: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> This PR is a follow up of [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). When using DPI scaling levels > 1, labels of controls get truncated when they are added to Dialogs which have an owner Window. To fix the issue, this PR binds dialog and owner window renderScale X, Y properties. It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check` when launching the dialog. ------------- Commit messages: - Bind dialog and owner window renderScale properties, including test Changes: https://git.openjdk.java.net/jfx/pull/369/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258592 Stats: 130 lines in 2 files changed: 130 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/369.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/369/head:pull/369 PR: https://git.openjdk.java.net/jfx/pull/369 From kcr at openjdk.java.net Thu Dec 17 16:36:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 16:36:56 GMT Subject: RFR: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels In-Reply-To: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> References: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> Message-ID: On Thu, 17 Dec 2020 15:55:58 GMT, Jose Pereda wrote: > This PR is a follow up of [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). > > When using DPI scaling levels > 1, labels of controls get truncated when they are added to Dialogs which have an owner Window. > > To fix the issue, this PR binds dialog and owner window renderScale X, Y properties. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check` when launching the dialog. Looks good. This seems a straight-forward enough fix that a single review would suffice. I left one question on the cleanup method in the test, but it's up to you as to whether to address it. tests/system/src/test/java/test/javafx/scene/UIRenderDialogTest.java line 121: > 119: public static void teardown() { > 120: Platform.runLater(() -> { > 121: alert.hide(); Maybe add a null check in case the test fails to create the Alert? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/369 From github.com+1496922+chewett at openjdk.java.net Thu Dec 17 17:08:58 2020 From: github.com+1496922+chewett at openjdk.java.net (Christopher Hewett) Date: Thu, 17 Dec 2020 17:08:58 GMT Subject: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: References: <9C1p4mWMNYAPwFRCwRLX2VGsMH4k3rkZd4ZVhxjw8NA=.d32adb57-173c-4b4e-85e0-c2d5db3d0954@github.com> Message-ID: On Tue, 13 Oct 2020 16:40:45 GMT, Oliver Schmidtmer wrote: >> I hope I understood your intend. I've tried to replace the recreation of the GraphicsPipeline-Instance by only calling the native parts. Unfortunately that doesn't seem to work at all. Probably I'm missing some updates. >> public boolean reinit() { >> if (d3dEnabled) { >> if (creator != Thread.currentThread()) { >> throw new IllegalStateException( >> "This operation is not permitted on the current thread [" >> + Thread.currentThread().getName() + "]"); >> } >> notifyAllResourcesReleased(); >> nDispose(); >> for (int i = 0; i != factories.length; ++i) { >> factories[i] = null; >> } >> nInit(PrismSettings.class); >> factories = new D3DResourceFactory[nGetAdapterCount()]; >> } >> return d3dEnabled; >> } > > On a side note, not all resources seem to be freed / recreated on pipeline disposal. There are some error outputs, and some parts in a webview are only rendered after interactions. So it is probably better to mark this as WIP. I would be happy if you have some advice for me. > java.lang.IllegalStateException: unmanaged resource freed from pool D3D Vram Pool > at com.sun.prism.impl.BaseResourcePool.resourceFreed(BaseResourcePool.java:463) > at com.sun.prism.impl.ManagedResource.dispose(ManagedResource.java:127) > at com.sun.prism.impl.BaseTexture.dispose(BaseTexture.java:297) > at com.sun.scenario.effect.impl.prism.ps.PPSDrawable.flush(PPSDrawable.java:69) > at com.sun.scenario.effect.impl.ImagePool.dispose(ImagePool.java:267) > at com.sun.scenario.effect.impl.Renderer.getRenderer(Renderer.java:367) > at com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$Layer.(WCGraphicsPrismContext.java:1369) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext$ClipLayer.(WCGraphicsPrismContext.java:1440) > at com.sun.javafx.webkit.prism.WCGraphicsPrismContext.setClip(WCGraphicsPrismContext.java:328) > at com.sun.webkit.graphics.GraphicsDecoder.decode(GraphicsDecoder.java:225) > at com.sun.webkit.graphics.WCRenderQueue.decode(WCRenderQueue.java:92) > at com.sun.webkit.WebPage.paint2GC(WebPage.java:736) > at com.sun.webkit.WebPage.paint(WebPage.java:703) > at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:95) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:143) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) > at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) > at java.base/java.lang.Thread.run(Thread.java:832) Now more of my company are remoting into machines this issue is causing problems for us. ------------- PR: https://git.openjdk.java.net/jfx/pull/315 From jpereda at openjdk.java.net Thu Dec 17 17:14:13 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 17 Dec 2020 17:14:13 GMT Subject: RFR: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels [v2] In-Reply-To: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> References: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> Message-ID: > This PR is a follow up of [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). > > When using DPI scaling levels > 1, labels of controls get truncated when they are added to Dialogs which have an owner Window. > > To fix the issue, this PR binds dialog and owner window renderScale X, Y properties. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check` when launching the dialog. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Check that the alert exists ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/369/files - new: https://git.openjdk.java.net/jfx/pull/369/files/149caa77..4d148175 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=369&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=369&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/369.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/369/head:pull/369 PR: https://git.openjdk.java.net/jfx/pull/369 From jpereda at openjdk.java.net Thu Dec 17 17:14:14 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 17 Dec 2020 17:14:14 GMT Subject: RFR: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels [v2] In-Reply-To: References: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> Message-ID: <5c-RgPa3Gbdn02rmNjZTemaCQO_8LLu7izpptZpUKbw=.d46d898d-4432-471b-9f73-12a2b898ae0f@github.com> On Thu, 17 Dec 2020 16:25:05 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Check that the alert exists > > tests/system/src/test/java/test/javafx/scene/UIRenderDialogTest.java line 121: > >> 119: public static void teardown() { >> 120: Platform.runLater(() -> { >> 121: alert.hide(); > > Maybe add a null check in case the test fails to create the Alert? OK, done ------------- PR: https://git.openjdk.java.net/jfx/pull/369 From almaslvl at gmail.com Thu Dec 17 17:17:24 2020 From: almaslvl at gmail.com (Almas Baimagambetov) Date: Thu, 17 Dec 2020 17:17:24 +0000 Subject: Feature Idea: Mouse Input Grab in Window Message-ID: Hi, Johan Vos and I had a quick chat about this feature and he suggested it might be a good idea to start a discussion. *Use case:* 3D games or 3D modelling tools, where the application "grabs" (gets exclusive control of) the mouse and moving the mouse doesn't move the cursor. *Feature:* Allow to confine the mouse to a window. The cursor is centered on the window and does not move/leave the window, whilst all mouse move events are reported normally. Since this is already provided by native code (e.g. Windows API), an implementation of this would probably be a wrapper, similar to the wrapper that the SDL library provides: https://wiki.libsdl.org/SDL_SetWindowGrab *Possible high-level API:* Window window = ... window.setMouseGrabbed(true); *Alternatives*: I've tried working around this by using Robot API, but it isn't quite the same. Kind regards, Almas From org.openjdk at io7m.com Thu Dec 17 17:39:11 2020 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 17 Dec 2020 17:39:11 +0000 Subject: Feature Idea: Mouse Input Grab in Window In-Reply-To: References: Message-ID: <20201217173911.55740f3f@sunflower.int.arc7.info> On 2020-12-17T17:17:24 +0000 Almas Baimagambetov wrote: > > *Use case:* 3D games or 3D modelling tools, where the application "grabs" > (gets exclusive control of) the mouse and moving the mouse doesn't move the > cursor. > This is pretty much essential for mouse-based camera control in 3D simulations, especially when combined with a "warp cursor to center of window" feature. Typically, the cursor will be confined to the window and warped to the center of the window at the start of every frame. This allows for all mouse movements to be treated as delta offsets from the center of the window, and these can typically be passed directly into camera handling functions. -- Mark Raynsford | https://www.io7m.com From fthevenet at openjdk.java.net Thu Dec 17 17:42:19 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Thu, 17 Dec 2020 17:42:19 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v4] In-Reply-To: References: Message-ID: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Invalidate cached snapped inset values when screen scale has changes. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/308/files - new: https://git.openjdk.java.net/jfx/pull/308/files/5720f03d..c448691b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=02-03 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Thu Dec 17 17:48:58 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Thu, 17 Dec 2020 17:48:58 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Thu, 17 Dec 2020 00:24:49 GMT, Kevin Rushforth wrote: >> There is still a remaining scaling issue, I'm afraid: snapped insets coordinates are cached after they've been computed and only updated when the inset (or a related property, such as shape or border) changes or if the snapToPixel property changes. >> >> This means that on a setup with more than one screen with different scales, when moving the application's window from one screen to the other, controls that were snapped on the first screen nor longer are once moved on the second one, and therefore appear blurry. >> >> We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call ` updateSnappedInsets`& `requestLayout` when one changes? > > Good point. We would need some way to invalidate the cached values if the screen scale changes. > >> We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call `updateSnappedInsets` & `requestLayout` when one changes? > > A layout will happen anyway as the result of a Window moving to another screen, so really it's only the cached snapped insets that need to be recalculated. I don't know whether a listener is the best approach, since it would need to handle the case where the Window changes (either because the scene changed or the scene was added to a new window), which would present similar challenges to what we face with treeVisible. > > Another possibility is for `updateSnappedInsets` to also cache the scaleX/Y at which the snapped insets were computed. The `snappedXXXXX` methods could check the current scale against the cached scale (a simple == test) and call `updateSnappedInsets` if the scale changes. I've opted for the cache and check for screen scale solution, as I agree it presents less risks of leaked or missing listeners down the road. There's a slight unexpected drawback I've noticed, though, which is that the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Thu Dec 17 17:55:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 17:55:58 GMT Subject: RFR: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels [v2] In-Reply-To: References: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> Message-ID: On Thu, 17 Dec 2020 17:14:13 GMT, Jose Pereda wrote: >> This PR is a follow up of [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). >> >> When using DPI scaling levels > 1, labels of controls get truncated when they are added to Dialogs which have an owner Window. >> >> To fix the issue, this PR binds dialog and owner window renderScale X, Y properties. >> >> It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check` when launching the dialog. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Check that the alert exists Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/369 From prr at openjdk.java.net Thu Dec 17 18:00:58 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 17 Dec 2020 18:00:58 GMT Subject: RFR: 8253356: JavaFX Terminology Refresh [v2] In-Reply-To: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> References: <5dN92P_RwrlYkPMc2Q0Esgwt2fLRUw5lLUHlSm6XCG4=.91a32ea7-310e-49c3-9d4e-d5c817c9a40a@github.com> Message-ID: On Wed, 16 Dec 2020 13:20:23 GMT, Kevin Rushforth wrote: >> Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. >> >> The following changes are made: >> >> 1. Rename whitelist/blacklist to allowlist/rejectlist >> 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation >> 3. Rename local variable master in a couple places >> 4. Remove master from comments in a few other places >> >> This PR doesn't remove uses of the word master where there is no connotation of slavery. >> >> Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback: change masterWindow to mainWindow in iOS files Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From kcr at openjdk.java.net Thu Dec 17 18:13:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 18:13:59 GMT Subject: Integrated: 8253356: JavaFX Terminology Refresh In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:03:53 GMT, Kevin Rushforth wrote: > Replace archaic/non-inclusive words in JavaFX with more neutral terms. See [JDK-8253315](https://bugs.openjdk.java.net/browse/JDK-8253315) for background information. > > The following changes are made: > > 1. Rename whitelist/blacklist to allowlist/rejectlist > 2. Rename `MasterTimer` to `PrimaryTimer` in animation and toolkit implementation > 3. Rename local variable master in a couple places > 4. Remove master from comments in a few other places > > This PR doesn't remove uses of the word master where there is no connotation of slavery. > > Note that it is out of scope of this PR to address similar issues in 3rd-party code, such as WebKit or GStreamer. We will pick up any relevant changes after they are available in the upstream sources. This pull request has now been integrated. Changeset: fb8e0cd0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/fb8e0cd0 Stats: 694 lines in 67 files changed: 228 ins; 235 del; 231 mod 8253356: JavaFX Terminology Refresh Reviewed-by: arapte, prr ------------- PR: https://git.openjdk.java.net/jfx/pull/368 From github.com+2179736+matthiasblaesing at openjdk.java.net Thu Dec 17 18:15:57 2020 From: github.com+2179736+matthiasblaesing at openjdk.java.net (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 17 Dec 2020 18:15:57 GMT Subject: Integrated: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 21:28:29 GMT, Matthias Bl?sing wrote: > The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that > the java class com.sun.webkit.MainThread can be found be the JNI > function FindClass. This is only true if the class is loadable by the > system class loader. > > One such case is when the OpenJFX modules are loaded from a new > ModuleLayer. To fix this, the reference to the class needs to be loaded > from when a JNI call from Java into native code is active. In that case > FindClass uses the classloader associated with that method. > > The test code can be executed by running: > > cd tests/manual/web/dataurl > ../../../../gradlew run This pull request has now been integrated. Changeset: e61b9239 Author: Matthias Bl?sing Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e61b9239 Stats: 368 lines in 6 files changed: 348 ins; 15 del; 5 mod 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/360 From jpereda at openjdk.java.net Thu Dec 17 18:18:58 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 17 Dec 2020 18:18:58 GMT Subject: Integrated: 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels In-Reply-To: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> References: <2r20gzWvRBM5BEZdaBeD-eQRZVslpDVtMrgWsswwl4E=.85b80906-bc3a-4f12-982d-6cac65e0029d@github.com> Message-ID: <79qRvZYyCXqGWM4k8FWv0xPaijA6DtGlZ2zbxhJxyNg=.5816e255-2b2a-4579-8236-01e6305f54d0@github.com> On Thu, 17 Dec 2020 15:55:58 GMT, Jose Pereda wrote: > This PR is a follow up of [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592). > > When using DPI scaling levels > 1, labels of controls get truncated when they are added to Dialogs which have an owner Window. > > To fix the issue, this PR binds dialog and owner window renderScale X, Y properties. > > It also provides a system test that can be tested on Linux and Windows. Before applying the fix, the `Check` text of the checkboxes is rendered as `Che...`. With the fix, the test verifies, for a given UI scale, that the rendered text is `Check` when launching the dialog. This pull request has now been integrated. Changeset: 53fe38bb Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/53fe38bb Stats: 135 lines in 2 files changed: 135 ins; 0 del; 0 mod 8258592: Control labels in Dialogs are truncated at certain DPI scaling levels Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/369 From jose.pereda at gluonhq.com Thu Dec 17 18:57:26 2020 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Thu, 17 Dec 2020 19:57:26 +0100 Subject: Access to private EventHandlers Message-ID: While chasing down an issue on Mac with application events, we have noticed that there is some code under a private package that apparently it is supposed to be used by developers, which of course it is discouraged: com.sun.glass.ui.Application:EventHandler [1] is a public static inner class under a private package, that is added to the Application class for subclassing. So far, only QuantumToolkit does subclass it [2] (just for Quit action and Theme changed events). However the EventHandler class has more methods for listening to MacOS/iOS application events. While most of those events happen before the app starts (and it wouldn't make sense to try to listen to them app-wise), in particular, the OpenFilesAction event is forwarded [3] when a second EventHandler is set. Other events like resign/become active actions can be listened to as well. A developer could provide a subclass of such EventHandler if it were public API, but so far, that has to be done accessing private API. At this point, and following on this other thread [4] that discussed a similar issue with EventHandlerManager, we should start considering the design of new public API that could provide developers with access to such events, with considerations to possible platform specifics. Regards, Jose [1] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L45 [2] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L352 [3] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L346 [4] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027909.html -- From kcr at openjdk.java.net Thu Dec 17 19:32:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 19:32:56 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Thu, 17 Dec 2020 17:46:28 GMT, Frederic Thevenet wrote: >> Good point. We would need some way to invalidate the cached values if the screen scale changes. >> >>> We could possibly listen to `Window::renderScaleXProperty` and `Window::renderScaleYProperty` and call `updateSnappedInsets` & `requestLayout` when one changes? >> >> A layout will happen anyway as the result of a Window moving to another screen, so really it's only the cached snapped insets that need to be recalculated. I don't know whether a listener is the best approach, since it would need to handle the case where the Window changes (either because the scene changed or the scene was added to a new window), which would present similar challenges to what we face with treeVisible. >> >> Another possibility is for `updateSnappedInsets` to also cache the scaleX/Y at which the snapped insets were computed. The `snappedXXXXX` methods could check the current scale against the cached scale (a simple == test) and call `updateSnappedInsets` if the scale changes. > > I've opted for the cache and check for screen scale solution, as I agree it presents less risks of leaked or missing listeners down the road. > There's a slight unexpected drawback I've noticed, though, which is that the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). Your latest patch looks exactly like what I would expect. I need to do some multi-screen testing on Windows with different scale factors. > ... the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). This seems like a different (and preexisting) bug then. I think we're up to three follow-on issues if I haven't lost track: 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods 3. Need to Render and layout scene out when scale changes (either when moving to a screen with a different scale or when the scale changes as the result of changing the setting of the current screen) ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kevin.rushforth at oracle.com Thu Dec 17 19:41:48 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Dec 2020 11:41:48 -0800 Subject: Feature Idea: Mouse Input Grab in Window In-Reply-To: <20201217173911.55740f3f@sunflower.int.arc7.info> References: <20201217173911.55740f3f@sunflower.int.arc7.info> Message-ID: <4fc9de3b-6179-91e6-9927-d0d8d2bd16c5@oracle.com> Immersive 3D games is not really a key use case for JavaFX, so I doubt we would add any API to support this. I don't see it as a feature we could implement in isolation anyway. As an example, we don't support full-screen exclusive mode (FSEM) on Windows, which might be needed to implement this completely. You might be able to do something in the application: set your stage to fullScreen, and update the cursor manually each frame (possibly using Robot::mouseMove). You would have to figure out how to interpret the mouse events you will receive. -- Kevin On 12/17/2020 9:39 AM, Mark Raynsford wrote: > On 2020-12-17T17:17:24 +0000 > Almas Baimagambetov wrote: >> *Use case:* 3D games or 3D modelling tools, where the application "grabs" >> (gets exclusive control of) the mouse and moving the mouse doesn't move the >> cursor. >> > This is pretty much essential for mouse-based camera control in 3D > simulations, especially when combined with a "warp cursor to center of > window" feature. Typically, the cursor will be confined to the window > and warped to the center of the window at the start of every frame. > This allows for all mouse movements to be treated as delta offsets from > the center of the window, and these can typically be passed directly > into camera handling functions. > From kevin.rushforth at oracle.com Thu Dec 17 19:46:24 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 17 Dec 2020 11:46:24 -0800 Subject: Feature Idea: Mouse Input Grab in Window In-Reply-To: References: Message-ID: <044bc55e-0e26-868d-5cad-623eae2f8194@oracle.com> I replied to a reply that snipped too much of this (I was thinking more of the full-screen fully immersive use case). If all you are looking for is some way to prevent the cursor from leaving a Window, there might be a way to do it, but the implications of this would need to be carefully thought through. And there would need to be a way (at least by default) to exit out of this mode like there is for full-screen. I'm still unsure about the "mouse doesn't move" part of this. -- Kevin On 12/17/2020 9:17 AM, Almas Baimagambetov wrote: > Hi, > > Johan Vos and I had a quick chat about this feature and he suggested it > might be a good idea to start a discussion. > > *Use case:* 3D games or 3D modelling tools, where the application "grabs" > (gets exclusive control of) the mouse and moving the mouse doesn't move the > cursor. > > *Feature:* Allow to confine the mouse to a window. The cursor is centered > on the window and does not move/leave the window, whilst all mouse move > events are reported normally. Since this is already provided by native code > (e.g. Windows API), an implementation of this would probably be a wrapper, > similar to the wrapper that the SDL library provides: > https://wiki.libsdl.org/SDL_SetWindowGrab > > *Possible high-level API:* > > Window window = ... > window.setMouseGrabbed(true); > > *Alternatives*: > > I've tried working around this by using Robot API, but it isn't quite the > same. > > Kind regards, Almas From kcr at openjdk.java.net Thu Dec 17 23:45:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Dec 2020 23:45:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Thu, 17 Dec 2020 19:30:17 GMT, Kevin Rushforth wrote: >> I've opted for the cache and check for screen scale solution, as I agree it presents less risks of leaked or missing listeners down the road. >> There's a slight unexpected drawback I've noticed, though, which is that the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). > > Your latest patch looks exactly like what I would expect. I need to do some multi-screen testing on Windows with different scale factors. > >> ... the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). > > This seems like a different (and preexisting) bug then. I think we're up to three follow-on issues if I haven't lost track: > > 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. > 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods > 3. Need to Render and layout scene out when scale changes (either when moving to a screen with a different scale or when the scale changes as the result of changing the setting of the current screen) I did some testing with your latest patch, and I don't see any problem when dragging a window between screens with different scales. It seems to be recalculating the cached insets and using them in layout as I would expect. Do you have a test case that shows the problem? ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Fri Dec 18 11:42:24 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 18 Dec 2020 11:42:24 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Thu, 17 Dec 2020 23:43:39 GMT, Kevin Rushforth wrote: >> Your latest patch looks exactly like what I would expect. I need to do some multi-screen testing on Windows with different scale factors. >> >>> ... the repaint for the affected Region does not seem to occur right away on moving the window to another screen, but only once the Region is interacted with (e.g. hovering the mouse over it). >> >> This seems like a different (and preexisting) bug then. I think we're up to three follow-on issues if I haven't lost track: >> >> 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. >> 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods >> 3. Need to Render and layout scene out when scale changes (either when moving to a screen with a different scale or when the scale changes as the result of changing the setting of the current screen) > > I did some testing with your latest patch, and I don't see any problem when dragging a window between screens with different scales. It seems to be recalculating the cached insets and using them in layout as I would expect. Do you have a test case that shows the problem? Unfortunately I've only seen it within an application with a fairly complex scene graph, which make isolating the issue tricky. I'm still trying to reproduce it a minimal sample, but in the mean time, please have a look at the a screen capture below, which should at least help clarify the issue I'm observing: ![8211294](https://user-images.githubusercontent.com/7450507/102610169-064d6000-412d-11eb-8ebd-b1999a6c6009.gif) This snippet is captured after the window had been moved from a screen scaled to 100% to a second one scaled to 150%; notice how the controls in the "Chart Properties" pane only snap to pixel when the mouse pointer enters the pane. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Fri Dec 18 13:37:25 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 18 Dec 2020 13:37:25 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Fri, 18 Dec 2020 11:39:04 GMT, Frederic Thevenet wrote: >> I did some testing with your latest patch, and I don't see any problem when dragging a window between screens with different scales. It seems to be recalculating the cached insets and using them in layout as I would expect. Do you have a test case that shows the problem? > > Unfortunately I've only seen it within an application with a fairly complex scene graph, which make isolating the issue tricky. > > I'm still trying to reproduce it a minimal sample, but in the mean time, please have a look at the a screen capture below, which should at least help clarify the issue I'm observing: > > ![8211294](https://user-images.githubusercontent.com/7450507/102610169-064d6000-412d-11eb-8ebd-b1999a6c6009.gif) > > This snippet is captured after the window had been moved from a screen scaled to 100% to a second one scaled to 150%; notice how the controls in the "Chart Properties" pane only snap to pixel when the mouse pointer enters the pane. Digging deeper into my own code, it appears that there are several areas where I need to account for screen scale within the application's code itself (i.e. I use coordinates from mouseEvent to set the layout of some elements, and these are not snapped), so it probably safe to ignore these issues in the context of the PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Fri Dec 18 14:36:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Dec 2020 14:36:26 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Fri, 18 Dec 2020 13:34:28 GMT, Frederic Thevenet wrote: >> Unfortunately I've only seen it within an application with a fairly complex scene graph, which make isolating the issue tricky. >> >> I'm still trying to reproduce it a minimal sample, but in the mean time, please have a look at the a screen capture below, which should at least help clarify the issue I'm observing: >> >> ![8211294](https://user-images.githubusercontent.com/7450507/102610169-064d6000-412d-11eb-8ebd-b1999a6c6009.gif) >> >> This snippet is captured after the window had been moved from a screen scaled to 100% to a second one scaled to 150%; notice how the controls in the "Chart Properties" pane only snap to pixel when the mouse pointer enters the pane. > > Digging deeper into my own code, it appears that there are several areas where I need to account for screen scale within the application's code itself (i.e. I use coordinates from mouseEvent to set the layout of some elements, and these are not snapped), so it probably safe to ignore these issues in the context of the PR. So that leaves two follow-on bugs then: 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Fri Dec 18 16:57:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Dec 2020 16:57:55 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Fri, 18 Dec 2020 14:34:01 GMT, Kevin Rushforth wrote: >> Digging deeper into my own code, it appears that there are several areas where I need to account for screen scale within the application's code itself (i.e. I use coordinates from mouseEvent to set the layout of some elements, and these are not snapped), so it probably safe to ignore these issues in the context of the PR. > > So that leaves two follow-on bugs then: > 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. > 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods I filed the following follow-on bugs: 1. [JDK-8258694](https://bugs.openjdk.java.net/browse/JDK-8258694) : Rendering cached nodes with sub-pixel translation is blurry 2. [JDK-8258697](https://bugs.openjdk.java.net/browse/JDK-8258697) : TextFlow: methods copied from Region have diverged ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From kevin.rushforth at oracle.com Fri Dec 18 17:13:51 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 18 Dec 2020 09:13:51 -0800 Subject: Proposed schedule for JavaFX 16 In-Reply-To: <497c89d3-2e83-2bf5-75a4-43691c51e114@oracle.com> References: <497c89d3-2e83-2bf5-75a4-43691c51e114@oracle.com> Message-ID: As a reminder, RDP1 for JavaFX 16 starts on January 7, 2021 at 16:00 UTC (08:00 Pacific time). Given the upcoming holidays, that's a little over 1 working week from now. During rampdown of JavaFX 16, the "master" branch of the jfx repo will be open for JavaFX 17 fixes. New features currently targeted to JavaFX 16 should be retargeted to JavaFX 17. We will follow the same process as previous releases for getting fixes into JavaFX 16 during rampdown. I'll send a message with detailed information later, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 10/9/2020 6:21 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 16. > > RDP1: Jan 7, 2021 (aka ?feature freeze?) > RDP2: Jan 28, 2021 > Freeze: Feb 18, 2021 > GA: March 9, 2021 > > We plan to fork a jfx16 stabilization branch at RDP1. The GA date is > expected to be one week ahead of JDK 16, matching what we did for 15. > > As was done for the previous release, the start of RDP1, the start of > RDP2, and the code freeze will be 16:00 UTC on the respective dates. > > Please let Johan or me know if you have any questions. > > -- Kevin > From tsayao at openjdk.java.net Sun Dec 20 00:35:02 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 20 Dec 2020 00:35:02 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend Message-ID: This is a new approach to rewrite parts of gtk glass backend to be more clean. I will provide small "manageable" PR to incrementally make the backend better. This PR adresses cleanup of the Size and Positioning code. It makes code more "straightforward" and easier to maintain. Current status: ![image](https://user-images.githubusercontent.com/30704286/102702414-1b1b1800-4241-11eb-90bf-8ab737ce2e04.png) ------------- Commit messages: - Fix parent window being resizable (it should not) - Minor fix to positioning - Small adjustment - Fixes - Revert files - Replace the window size & positining code - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - Merge pull request #11 from openjdk/master - ... and 7 more: https://git.openjdk.java.net/jfx/compare/f2928d95...bdfd0deb Changes: https://git.openjdk.java.net/jfx/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236651 Stats: 613 lines in 5 files changed: 136 ins; 311 del; 166 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367 From cjgunzel at gmail.com Sun Dec 20 20:48:19 2020 From: cjgunzel at gmail.com (Chuck Davis) Date: Sun, 20 Dec 2020 12:48:19 -0800 Subject: list digest Message-ID: I just joined the list but I can't find a link to a digest of past activity. I'm specifically interested in discussions regarding TableView. Does anyone know where to find the list digest? Thanks. From johan.vos at gluonhq.com Sun Dec 20 20:52:52 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 20 Dec 2020 21:52:52 +0100 Subject: list digest In-Reply-To: References: Message-ID: Hi, You can find the archives at http://mail.openjdk.java.net/pipermail/openjfx-dev/ - Johan On Sun, Dec 20, 2020 at 9:49 PM Chuck Davis wrote: > I just joined the list but I can't find a link to a digest of past > activity. > > I'm specifically interested in discussions regarding TableView. Does > anyone know where to find the list digest? > > Thanks. > From mp at jugs.org Sun Dec 20 20:55:36 2020 From: mp at jugs.org (Michael Paus) Date: Sun, 20 Dec 2020 21:55:36 +0100 Subject: list digest In-Reply-To: References: Message-ID: You can find the archives here: https://mail.openjdk.java.net/pipermail/openjfx-dev/ Am 20.12.20 um 21:48 schrieb Chuck Davis: > I just joined the list but I can't find a link to a digest of past activity. > > I'm specifically interested in discussions regarding TableView. Does > anyone know where to find the list digest? > > Thanks. From cjgunzel at gmail.com Sun Dec 20 21:47:48 2020 From: cjgunzel at gmail.com (Chuck Davis) Date: Sun, 20 Dec 2020 13:47:48 -0800 Subject: list digest In-Reply-To: References: Message-ID: Thanks guys for the link to the digest. I've looked through a couple of years and find nothing that addresses my interest. As background, I write financial applications and usually when a user selects something to display in a table it's because they're interested in the total amount. And it is easy to provide that information to them on the initial display. The rub comes when they select a column header or otherwise sort the table. I need, first of all, to eliminate the total object from the model (this is done easily by listening to the onSort property). Then, after the sort is complete I need to add the total object back to the model. If I don't eliminate the total object from the model the sort puts it in very strange places..... What I need to know is when the sort is complete so that I can add the total object back into the model and get it displayed. I've been looking at the TableView source and find the following code near the start of the sort() method: SortEvent> sortEvent = new SortEvent<>(TableView.this, TableView.this); fireEvent(sortEvent); It seems to me it would be trivial to invent another event type SORT_COMPLETE and emit it at the end of the sort() method to notify the program that the sort has been completed. And that would certainly solve a major headache with showing a total amount for financial tables. What I don't know is whether the sort is done on another thread in which case a Future would probably be required to detect the sort completion. If this were implemented we programmers would be able to detect both the start and completion of a sort of the table and proceed accordingly. It would be VERY helpful. Thanks for reading. From arapte at openjdk.java.net Mon Dec 21 10:29:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 21 Dec 2020 10:29:09 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v2] In-Reply-To: References: Message-ID: > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. > > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into TabPaneSkinLeak - 8242621: TabPane: Memory leak when switching skin ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/318/files - new: https://git.openjdk.java.net/jfx/pull/318/files/47674a6b..cb7f9eed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=00-01 Stats: 44423 lines in 389 files changed: 5231 ins; 38400 del; 792 mod Patch: https://git.openjdk.java.net/jfx/pull/318.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/318/head:pull/318 PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Mon Dec 21 11:54:06 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 21 Dec 2020 11:54:06 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: References: Message-ID: <9uL0rmq2E0DFdlLr8t0SW25j9JPutM-Vum5bGkJmSoc=.9ecbece3-948f-4a57-b9d5-e666c9523d20@github.com> > `TabPaneSkin` installs some listeners that are not removed when `TabPaneSkin` is changed. > The fix converts listeners to WeakListeners and also removes them on dispose. > > There is a NPE check change needed in `isHosrizontal()`. Without this check it causes NPE if pulse is in progress while TabPaneSkin is getting disposed. > > `SkinMemoryLeakTest` already had a test which only needed to be enabled. > Test fails before and passes after this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Review update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/318/files - new: https://git.openjdk.java.net/jfx/pull/318/files/cb7f9eed..a3b57950 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=318&range=01-02 Stats: 94 lines in 2 files changed: 82 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/318.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/318/head:pull/318 PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Mon Dec 21 12:08:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 21 Dec 2020 12:08:56 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: References: Message-ID: <6TCjAkj1FE2FIO9oWag-lE4Kh5AqpdRwKdVhchF29Qk=.9fd8b9df-f954-44ae-8324-09682e3ecc55@github.com> On Tue, 15 Dec 2020 14:56:09 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 274: >> >>> 272: getSkinnable().getTabs().removeListener(weakTabsListener); >>> 273: >>> 274: getChildren().remove(tabHeaderArea); >> >> As mentioned offline, can you check whether removing `tabHeaderArea` is necessary? > > good question :) Just have run into a similar case while working on cleaning up TextFieldSkin. > > My current understanding is ... depends ;) > > As tests show, some children keep the skin alive, others don't. Which must imply that the first somehow keep a strong reference to the skin, the latter (nor any of its children) don't. An example for the former is tabHeaderArea, an example for the latter is tabContentRegion. Was puzzled about how to distinguish the one from the other (which boils down to finding that strong reference) - until I (faintly ;) remembered that inner classes have an implicit reference to the enclosing instance: TabHeaderArea is an inner class with an implicit reference to the enclosing skin, while TabContentRegion is static nested. As long as the former reside in the scenegraph, it makes the skin leaky. > > So we have to watch out for > - explicit strong references from any node (down the hierarchy) to the skin > - implicit strong reference to the enclosing skin class. > > Both groups have to be removed in dispose to prevent memory leaks. > > Even if not obviously leaking, children pile up when switching skin: most skins add to children, rarely set. We started a discussion of how to handle those that add [Spinner misbehavior](https://bugs.openjdk.java.net/browse/JDK-8245145) - not yet decided (personally, I didn't do anything about them in the cleanups, deferred to later ;) From today's knowledge, I would suggest to explicitly remove all direct children that the skin added to the control. > As mentioned offline, can you check whether removing `tabHeaderArea` is necessary? > Both groups have to be removed in dispose to prevent memory leaks. The list returned by `SkinBase.getChildren()` is actually the same list as `Parent.getChildren()`. `SkinBase()` constructor gets the reference of `Parent.getChildren()` and store it's reference in the class member named `children`. [[see here](https://github.com/openjdk/jfx/blob/53fe38bb34fc01ba298aa1a12f20c061c0cb58b2/modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java#L125)] So, Skin and Parent share the same list of children. So when a skin is being `dispose()`ed, it should remove any children that it added to the list. Otherwise, those children continue to be part of scenegraph. Please check the newly added test SkinCleanupTest.testChildrenCountAfterSkinIsReplaced(). This does not stop a skin object from getting GCed, but the Children that skin adds don't get removed from Scenegraph. Looking at this behavior, it seems like this should be done for cleanup of all Skins. ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From fastegal at openjdk.java.net Mon Dec 21 12:19:53 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 21 Dec 2020 12:19:53 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: <6TCjAkj1FE2FIO9oWag-lE4Kh5AqpdRwKdVhchF29Qk=.9fd8b9df-f954-44ae-8324-09682e3ecc55@github.com> References: <6TCjAkj1FE2FIO9oWag-lE4Kh5AqpdRwKdVhchF29Qk=.9fd8b9df-f954-44ae-8324-09682e3ecc55@github.com> Message-ID: On Mon, 21 Dec 2020 12:06:16 GMT, Ambarish Rapte wrote: >> good question :) Just have run into a similar case while working on cleaning up TextFieldSkin. >> >> My current understanding is ... depends ;) >> >> As tests show, some children keep the skin alive, others don't. Which must imply that the first somehow keep a strong reference to the skin, the latter (nor any of its children) don't. An example for the former is tabHeaderArea, an example for the latter is tabContentRegion. Was puzzled about how to distinguish the one from the other (which boils down to finding that strong reference) - until I (faintly ;) remembered that inner classes have an implicit reference to the enclosing instance: TabHeaderArea is an inner class with an implicit reference to the enclosing skin, while TabContentRegion is static nested. As long as the former reside in the scenegraph, it makes the skin leaky. >> >> So we have to watch out for >> - explicit strong references from any node (down the hierarchy) to the skin >> - implicit strong reference to the enclosing skin class. >> >> Both groups have to be removed in dispose to prevent memory leaks. >> >> Even if not obviously leaking, children pile up when switching skin: most skins add to children, rarely set. We started a discussion of how to handle those that add [Spinner misbehavior](https://bugs.openjdk.java.net/browse/JDK-8245145) - not yet decided (personally, I didn't do anything about them in the cleanups, deferred to later ;) From today's knowledge, I would suggest to explicitly remove all direct children that the skin added to the control. > >> As mentioned offline, can you check whether removing `tabHeaderArea` is necessary? > >> Both groups have to be removed in dispose to prevent memory leaks. > > > The list returned by `SkinBase.getChildren()` is actually the same list as `Parent.getChildren()`. > `SkinBase()` constructor gets the reference of `Parent.getChildren()` and store it's reference in the class member named `children`. [[see here](https://github.com/openjdk/jfx/blob/53fe38bb34fc01ba298aa1a12f20c061c0cb58b2/modules/javafx.controls/src/main/java/javafx/scene/control/SkinBase.java#L125)] > So, Skin and Parent share the same list of children. So when a skin is being `dispose()`ed, it should remove any children that it added to the list. Otherwise, those children continue to be part of scenegraph. > Please check the newly added test SkinCleanupTest.testChildrenCountAfterSkinIsReplaced(). > > This does not stop a skin object from getting GCed, but the Children that skin adds don't get removed from Scenegraph. Looking at this behavior, it seems like this should be done for cleanup of all Skins. quick nit-pick: > This does not stop a skin object from getting GCed, actually, it does ... if it keeps a strong reference to the skin :) ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From arapte at openjdk.java.net Mon Dec 21 12:19:57 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 21 Dec 2020 12:19:57 GMT Subject: RFR: 8242621: TabPane: Memory leak when switching skin [v3] In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 23:24:54 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Review update > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java line 716: > >> 714: >> 715: private boolean isHorizontal() { >> 716: Side tabPosition = getSkinnable() != null ? getSkinnable().getSide() : Side.TOP; > > I agree with @kleopatra This null check suggests that someone (a listener perhaps?) is calling into the skin after it has been disposed. The NPE here occurs if `tabHeaderArea` is not removed when disposing the skin. Actually this NPE does not occur with commit#1 and the null check was not needed, It is removed now. (The NPE can be observed by removing line#283 from TabPaneSkin.java of this fix) ------------- PR: https://git.openjdk.java.net/jfx/pull/318 From fthevenet at openjdk.java.net Mon Dec 21 18:49:11 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 21 Dec 2020 18:49:11 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v5] In-Reply-To: References: Message-ID: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Added a test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/308/files - new: https://git.openjdk.java.net/jfx/pull/308/files/c448691b..969f23f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=03-04 Stats: 106 lines in 1 file changed: 106 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From fthevenet at openjdk.java.net Mon Dec 21 18:49:11 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 21 Dec 2020 18:49:11 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: <8gIgvwLWohCdTZ_N4YyJc1qx7Pl91nPvJHyx0CmZ6q8=.3482ec08-686f-4845-ab4f-849c64124a94@github.com> <6N4e8bYMUGQuEncFt6_S2KM-d8zafQVGD2dpaKl3VhE=.77e9ab10-083d-4488-a1fc-387f628b3a27@github.com> <78hMW0LLT3fBPGgKT_N9PzueEiJFg_dfNXRLUlbHBA0=.e59df894-64e5-4938-aaec-fe5f0310a4d8@github.com> <5r6osoP7eb_4MPG5ArgiV-tjGygDKnt4k7iwDSlf0-4=.f3d8e68f-fd59-4a40-bc2e-8a1c3456df4a@github.com> <2GCDZzmIRER1ckFl3nhY5-PdZLcDVI3dU3z-I1I1E1Q=.45758385-6ee1-4f08-b9bc-a6fb6b2a8358@github.com> Message-ID: On Fri, 18 Dec 2020 16:54:46 GMT, Kevin Rushforth wrote: >> So that leaves two follow-on bugs then: >> 1. Rendering a cached node doesn't match rendering it directly even when the transform is unchanged. >> 2. TextFlow: methods copied from Region have not picked up subsequent changes in those methods > > I filed the following follow-on bugs: > 1. [JDK-8258694](https://bugs.openjdk.java.net/browse/JDK-8258694) : Rendering cached nodes with sub-pixel translation is blurry > 2. [JDK-8258697](https://bugs.openjdk.java.net/browse/JDK-8258697) : TextFlow: methods copied from Region have diverged I've added a test that verifies that the inset values for a scrollpane in a scene are snapped to whole pixels, given the actual screen scale. The test passes without this fix for screen scale of 100% or 200% but fails at 125%, 150% and 175% With this fix, it passes at all screen scale. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From arapte at openjdk.java.net Tue Dec 22 08:18:07 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Dec 2020 08:18:07 GMT Subject: RFR: 8254101: Update copyright header for files modified in 2020 Message-ID: <1JCDAOm99sKWng7huG6DB924eO2ZNvp2w-GFTTLTHek=.89f9e890-5069-4409-97ea-3c0f1ceda2e2@github.com> Fix for updating last modified year in the files that were modified during year 2020. @kevinrushforth, Please take a look. ------------- Commit messages: - update-copyright-2020 Changes: https://git.openjdk.java.net/jfx/pull/370/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=370&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254101 Stats: 196 lines in 196 files changed: 0 ins; 0 del; 196 mod Patch: https://git.openjdk.java.net/jfx/pull/370.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/370/head:pull/370 PR: https://git.openjdk.java.net/jfx/pull/370 From aghaisas at openjdk.java.net Tue Dec 22 09:38:56 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 22 Dec 2020 09:38:56 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v3] In-Reply-To: <8LlhfU0Zb-0FAM7E1sOl-9LSEzP-unqsmkA8EhB9MiE=.e8024574-6050-4d0a-87a1-09f081136124@github.com> References: <8LlhfU0Zb-0FAM7E1sOl-9LSEzP-unqsmkA8EhB9MiE=.e8024574-6050-4d0a-87a1-09f081136124@github.com> Message-ID: <1X3jSdcGCK-ftUW7GZsFHzk7oJA2t2cXrpP1LrwbDxc=.c4e11c26-f86b-4470-aafd-d245fd4735be@github.com> On Wed, 25 Nov 2020 18:06:10 GMT, Jonathan Vusich wrote: >> As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. > > Jonathan Vusich has updated the pull request incrementally with one additional commit since the last revision: > > Unrotate labels if there is enough space for them modules/javafx.controls/src/main/java/javafx/scene/chart/CategoryAxis.java line 381: > 379: } > 380: } > 381: if (!isAutoRanging()) setTickLabelRotation(tickLabelRotation); At first, I thought this setTickLabelRotation() call violates the method javadoc above. On a second look, I found that the javadoc is applicable only if AutoRanging() is true. Method calls - calculateNewSpacing() and calculateNewFirstPos() also set properties if AutoRanging is false. Hence, this fix seems OK to me. modules/javafx.controls/src/main/java/javafx/scene/chart/CategoryAxis.java line 48: > 46: import javafx.util.Duration; > 47: > 48: import com.sun.javafx.binding.Logging; This looks unused import. Please remove it. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From kcr at openjdk.java.net Tue Dec 22 13:38:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 13:38:53 GMT Subject: RFR: 8254101: Update copyright header for files modified in 2020 In-Reply-To: <1JCDAOm99sKWng7huG6DB924eO2ZNvp2w-GFTTLTHek=.89f9e890-5069-4409-97ea-3c0f1ceda2e2@github.com> References: <1JCDAOm99sKWng7huG6DB924eO2ZNvp2w-GFTTLTHek=.89f9e890-5069-4409-97ea-3c0f1ceda2e2@github.com> Message-ID: <6WFEwDLbpSpVoHUxOizFZlbxyF4bBDwYwqwu28kOZDI=.83a2793b-0559-4e75-803e-6ac8c9865a03@github.com> On Tue, 22 Dec 2020 08:14:06 GMT, Ambarish Rapte wrote: > Fix for updating last modified year in the files that were modified during year 2020. > @kevinrushforth, Please take a look. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/370 From github.com+31666175+jonathanvusich at openjdk.java.net Tue Dec 22 14:54:12 2020 From: github.com+31666175+jonathanvusich at openjdk.java.net (Jonathan Vusich) Date: Tue, 22 Dec 2020 14:54:12 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v4] In-Reply-To: References: Message-ID: > As noted in the corresponding JBS issue, `Axis` does not properly compute its preferred height when `autoRanging` is turned off. The simplest fix seems to be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees if there is not enough room for the category labels to layout horizontally. This fixes the fact that the axis labels are truncated and also ensures that the chart does not leave unused space from the layout calculations. `CategoryAxis` is already setting the `categorySpacing` property when `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request incrementally with one additional commit since the last revision: Remove unused import ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/6d83f79c..0d11d341 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=342&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342 From arapte at openjdk.java.net Tue Dec 22 14:55:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Dec 2020 14:55:55 GMT Subject: Integrated: 8254101: Update copyright header for files modified in 2020 In-Reply-To: <1JCDAOm99sKWng7huG6DB924eO2ZNvp2w-GFTTLTHek=.89f9e890-5069-4409-97ea-3c0f1ceda2e2@github.com> References: <1JCDAOm99sKWng7huG6DB924eO2ZNvp2w-GFTTLTHek=.89f9e890-5069-4409-97ea-3c0f1ceda2e2@github.com> Message-ID: On Tue, 22 Dec 2020 08:14:06 GMT, Ambarish Rapte wrote: > Fix for updating last modified year in the files that were modified during year 2020. > @kevinrushforth, Please take a look. This pull request has now been integrated. Changeset: e74f679f Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/e74f679f Stats: 196 lines in 196 files changed: 0 ins; 0 del; 196 mod 8254101: Update copyright header for files modified in 2020 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/370 From nlisker at openjdk.java.net Tue Dec 22 17:43:05 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> On Thu, 22 Oct 2020 18:29:19 GMT, Nir Lisker wrote: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the falloff == 0 branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the falloff == 0 branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. I suggest we start with looking at the API and the subclass question. This will unblock the CSR process. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 18:29:19 GMT, Nir Lisker wrote: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the falloff == 0 branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the falloff == 0 branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. I think the API looks good with a few comments about valid ranges. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 48: > 46: * outer angle}, and a {@link #falloffProperty() falloff} factor. For a point whose angle to the light is {@code a}, if > 47: * {@code a < innerAngle} then that point receives maximum illumination, if {@code a > outerAngle} then that point > 48: * receives no illumination, and if {@code innerAngle < a < outerAngle} then the illumination is determined by the that should be `innerAngle <= a <= outerAngle` modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 59: > 57: * effect by setting {@code innerAngle} to be larger than {@code outerAngle} and lowering {@code maxRange}. > 58: *

> 59: * Image of the ring light effect I don't see the value in supporting this type of effect. It would potentially constrain the implementation and would complicate the description of the lighting equation. Without this complication, the equation as described in the earlier paragraph is effectively: if (a < innerAngle) { I = 1 } else if (a > outerAngle) { I = 0 } else { I = pow((cos(a) - cos(outer)) / (cos(inner) - cos(outer)), falloff) } In order to support the ring effect, you would need define the equation differently (i.e., it doesn't just naturally derive from the above equation). In any case, it seems best to just remove this, and document that the valid range of `outerAngle` is `[innerAngle, 180]`. We could clamp on usage as we do in a few other areas. Similarly, we probably want to document that `falloff` should be non-negative. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 163: > 161: * receive no light. At smaller angles, the light intensity starts to increase. > 162: *

> 163: * The angle is clamped between 0 and 180. between innerAngle and 180? modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 165: > 163: * The angle is clamped between 0 and 180. > 164: * > 165: * @defaultValue 90 Should this be 180 be default? I don't have a strong opinion on this. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 194: > 192: * values are allowed, but give unrealistic lighting. > 193: * > 194: * @defaultValue 1 Maybe it should default to 0? I don't have a strong opinion on this either. I do think that it should say that values < 0 are clamped to 0. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> Message-ID: <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> On Tue, 27 Oct 2020 23:30:01 GMT, Kevin Rushforth wrote: >> I suggest we start with looking at the API and the subclass question. This will unblock the CSR process. > > My preference would be for `SpotLight` to subclass `PointLight`. I also somewhat prefer the 1/2 angle (radius) rather than diameter to specify the spread angles (inner and outer). Not that it's all that relevant, but I will note that the (very old) Java 3D API also had [SpotLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/SpotLight.html) as a subclass of [PointLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/PointLight.html). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:04 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:04 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types Message-ID: Added a SpotLight only to the D3D pipeline currently. ### API 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? CSR will be created when the API review is finished. ### Implementation I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). ### Performance Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): Without the falloff == 0 branching: sphere 1000 subdivisions: 120 mesh 5000: 9.5 mesh 200: 111.5 With the falloff == 0 branching: sphere 1000 subdivisions: 120 mesh 5000: 9.3 mesh 200: 112.5 Ubuntu 20: With the patch: Mesh 200: 60 fps Mesh 5000: 15 fps Sphere 1000: 60 fps Without the patch (master branch) Mesh 200: 60 fps Mesh 5000: 16.3 fps Sphere 1000: 60 fps So no major changes. I will repeat these tests to make sure there was no mistake. ------------- Commit messages: - Fixed merged conflict - Fixed whitespaces - OpenGL implementation - Address review comments - Update to the d3d pipeline - Docs images - Small docs clarifications - Subclassed PointLight - Fix whitespaces - Updated test app for SpotLights - ... and 4 more: https://git.openjdk.java.net/jfx/compare/16b697c9...40de36fe Changes: https://git.openjdk.java.net/jfx/pull/334/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234920 Stats: 1142 lines in 34 files changed: 791 ins; 75 del; 276 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:06 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> Message-ID: <2wBW_4JuBzDy_4bdzKkM77GJiiHgAe7UcsELPXHq3EM=.cb9b37c6-b401-41a1-b9f6-6516fe9de92a@github.com> On Fri, 30 Oct 2020 11:52:03 GMT, Nir Lisker wrote: >> Not that it's all that relevant, but I will note that the (very old) Java 3D API also had [SpotLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/SpotLight.html) as a subclass of [PointLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/PointLight.html). > > Is the old implementation worth looking at, or is is completely different? > > I updated the API after subclassing `PointLight`. After we settle on it I will submit a CSR and we can move on to the implementation. Another API point is how to implement the direction - a `Point3D` or 3 doubles. We've had this discussion before when talking about transforms, and didn't reach a conclusion. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> Message-ID: On Mon, 26 Oct 2020 00:43:02 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API >> >> 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> CSR will be created when the API review is finished. >> >> ### Implementation >> >> I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). >> >> ### Performance >> >> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): >> >> Without the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.5 >> mesh 200: 111.5 >> >> With the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.3 >> mesh 200: 112.5 >> >> Ubuntu 20: >> With the patch: >> Mesh 200: 60 fps >> Mesh 5000: 15 fps >> Sphere 1000: 60 fps >> >> Without the patch (master branch) >> Mesh 200: 60 fps >> Mesh 5000: 16.3 fps >> Sphere 1000: 60 fps >> >> So no major changes. I will repeat these tests to make sure there was no mistake. > > I suggest we start with looking at the API and the subclass question. This will unblock the CSR process. My preference would be for `SpotLight` to subclass `PointLight`. I also somewhat prefer the 1/2 angle (radius) rather than diameter to specify the spread angles (inner and outer). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:08 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:08 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 21:56:02 GMT, Kevin Rushforth wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API >> >> 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> CSR will be created when the API review is finished. >> >> ### Implementation >> >> I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). >> >> ### Performance >> >> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): >> >> Without the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.5 >> mesh 200: 111.5 >> >> With the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.3 >> mesh 200: 112.5 >> >> Ubuntu 20: >> With the patch: >> Mesh 200: 60 fps >> Mesh 5000: 15 fps >> Sphere 1000: 60 fps >> >> Without the patch (master branch) >> Mesh 200: 60 fps >> Mesh 5000: 16.3 fps >> Sphere 1000: 60 fps >> >> So no major changes. I will repeat these tests to make sure there was no mistake. > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 165: > >> 163: * The angle is clamped between 0 and 180. >> 164: * >> 165: * @defaultValue 90 > > Should this be 180 be default? I don't have a strong opinion on this. 180 will make it look like a point light, which is probably not what the users want out of the box. The value is arbitrary at the end of the day, so I don't really mind. > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 194: > >> 192: * values are allowed, but give unrealistic lighting. >> 193: * >> 194: * @defaultValue 1 > > Maybe it should default to 0? I don't have a strong opinion on this either. > > I do think that it should say that values < 0 are clamped to 0. I think that having a dropoff as a default is closer to what users will want. 0 will just give a flat circle (thought there is decreased intensity with the angle to the surface). Is there a good reason to limit it? Nothing changes if we allow <0 values. I can remove the documentation for it, but in terms of implementation I don't see the benefit. > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 59: > >> 57: * effect by setting {@code innerAngle} to be larger than {@code outerAngle} and lowering {@code maxRange}. >> 58: *

>> 59: * Image of the ring light effect > > I don't see the value in supporting this type of effect. It would potentially constrain the implementation and would complicate the description of the lighting equation. > > Without this complication, the equation as described in the earlier paragraph is effectively: > > if (a < innerAngle) { > I = 1 > } else if (a > outerAngle) { > I = 0 > } else { > I = pow((cos(a) - cos(outer)) / (cos(inner) - cos(outer)), falloff) > } > In order to support the ring effect, you would need define the equation differently (i.e., it doesn't just naturally derive from the above equation). In any case, it seems best to just remove this, and document that the valid range of `outerAngle` is `[innerAngle, 180]`. We could clamp on usage as we do in a few other areas. Similarly, we probably want to document that `falloff` should be non-negative. Similar to what I said about the falloff, I can remove the documentation, but I don't see a compelling reason to artificially limit the values. The equation is as described in the docs. If someone puts in values outside of physically realistic ranges they will still get whatever the equation spits out. Do you think that there would be a too-large surprise factor? One thing to note is that the user can do the clamping themselves (or we can do it later if we don't commit in the docs), but if we clamp, the user can't unclamp. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:09 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 22:49:01 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 165: >> >>> 163: * The angle is clamped between 0 and 180. >>> 164: * >>> 165: * @defaultValue 90 >> >> Should this be 180 be default? I don't have a strong opinion on this. > > 180 will make it look like a point light, which is probably not what the users want out of the box. The value is arbitrary at the end of the day, so I don't really mind. A default of 90 seems fine. >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 194: >> >>> 192: * values are allowed, but give unrealistic lighting. >>> 193: * >>> 194: * @defaultValue 1 >> >> Maybe it should default to 0? I don't have a strong opinion on this either. >> >> I do think that it should say that values < 0 are clamped to 0. > > I think that having a dropoff as a default is closer to what users will want. 0 will just give a flat circle (thought there is decreased intensity with the angle to the surface). > > Is there a good reason to limit it? Nothing changes if we allow <0 values. I can remove the documentation for it, but in terms of implementation I don't see the benefit. I think a default of 1 is fine then. Also, I don't have the same concern over negative falloff values as I do for the inner and outer angles. >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 59: >> >>> 57: * effect by setting {@code innerAngle} to be larger than {@code outerAngle} and lowering {@code maxRange}. >>> 58: *

>>> 59: * Image of the ring light effect >> >> I don't see the value in supporting this type of effect. It would potentially constrain the implementation and would complicate the description of the lighting equation. >> >> Without this complication, the equation as described in the earlier paragraph is effectively: >> >> if (a < innerAngle) { >> I = 1 >> } else if (a > outerAngle) { >> I = 0 >> } else { >> I = pow((cos(a) - cos(outer)) / (cos(inner) - cos(outer)), falloff) >> } >> In order to support the ring effect, you would need define the equation differently (i.e., it doesn't just naturally derive from the above equation). In any case, it seems best to just remove this, and document that the valid range of `outerAngle` is `[innerAngle, 180]`. We could clamp on usage as we do in a few other areas. Similarly, we probably want to document that `falloff` should be non-negative. > > Similar to what I said about the falloff, I can remove the documentation, but I don't see a compelling reason to artificially limit the values. The equation is as described in the docs. If someone puts in values outside of physically realistic ranges they will still get whatever the equation spits out. Do you think that there would be a too-large surprise factor? > > One thing to note is that the user can do the clamping themselves (or we can do it later if we don't commit in the docs), but if we clamp, the user can't unclamp. The main issue I have is that the specified equation matches the proposed implementation only for values that satisfy the range constraints: `0 <= innerAngle <= outerAngle <= 180`. The reason for this is that the shader implementation compares cosines not angles, and clamps the result of the division rather than testing whether the angle is < inner or > outer. These are very reasonable implementation choices. We have a few options that I can see: 1. List the expected range, and specify that values outside the expected range are clamped on usage. 2. List the expected range, and specify that the results are undefined for values outside the expected range. 3. Describe the equation that is actually happening. 4. Implement what the equation actually specifies, even for out-of-range values. This would constrain the implementation and likely require extra if tests in the shader. Option 4 makes no sense to me. I don't care for 3, since it is less easy to explain and understand, and it precludes other implementations that are equivalent for in-range values but might behave differently for out-of-range values. So that leaves option 1 or 2 as workable options. I prefer option 1, although I'll admit we aren't consistent on this point: we let the implementation do whatever it will do with out of range color values for PhongMaterial or Lights. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:09 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:09 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 00:54:14 GMT, Kevin Rushforth wrote: >> Similar to what I said about the falloff, I can remove the documentation, but I don't see a compelling reason to artificially limit the values. The equation is as described in the docs. If someone puts in values outside of physically realistic ranges they will still get whatever the equation spits out. Do you think that there would be a too-large surprise factor? >> >> One thing to note is that the user can do the clamping themselves (or we can do it later if we don't commit in the docs), but if we clamp, the user can't unclamp. > > The main issue I have is that the specified equation matches the proposed implementation only for values that satisfy the range constraints: `0 <= innerAngle <= outerAngle <= 180`. > > The reason for this is that the shader implementation compares cosines not angles, and clamps the result of the division rather than testing whether the angle is < inner or > outer. These are very reasonable implementation choices. > > We have a few options that I can see: > > 1. List the expected range, and specify that values outside the expected range are clamped on usage. > 2. List the expected range, and specify that the results are undefined for values outside the expected range. > 3. Describe the equation that is actually happening. > 4. Implement what the equation actually specifies, even for out-of-range values. This would constrain the implementation and likely require extra if tests in the shader. > > Option 4 makes no sense to me. I don't care for 3, since it is less easy to explain and understand, and it precludes other implementations that are equivalent for in-range values but might behave differently for out-of-range values. > > So that leaves option 1 or 2 as workable options. I prefer option 1, although I'll admit we aren't consistent on this point: we let the implementation do whatever it will do with out of range color values for PhongMaterial or Lights. I see. I also dislike 3 and 4. I prefer 2, but if you are convinced that 1 is better I'll go with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:09 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 01:06:45 GMT, Nir Lisker wrote: >> The main issue I have is that the specified equation matches the proposed implementation only for values that satisfy the range constraints: `0 <= innerAngle <= outerAngle <= 180`. >> >> The reason for this is that the shader implementation compares cosines not angles, and clamps the result of the division rather than testing whether the angle is < inner or > outer. These are very reasonable implementation choices. >> >> We have a few options that I can see: >> >> 1. List the expected range, and specify that values outside the expected range are clamped on usage. >> 2. List the expected range, and specify that the results are undefined for values outside the expected range. >> 3. Describe the equation that is actually happening. >> 4. Implement what the equation actually specifies, even for out-of-range values. This would constrain the implementation and likely require extra if tests in the shader. >> >> Option 4 makes no sense to me. I don't care for 3, since it is less easy to explain and understand, and it precludes other implementations that are equivalent for in-range values but might behave differently for out-of-range values. >> >> So that leaves option 1 or 2 as workable options. I prefer option 1, although I'll admit we aren't consistent on this point: we let the implementation do whatever it will do with out of range color values for PhongMaterial or Lights. > > I see. > > I also dislike 3 and 4. I prefer 2, but if you are convinced that 1 is better I'll go with it. I'm OK with option 2. So that would mean removing any mention of the "ring" effect, and documenting that the valid ranges are: innerAngle: [0, 180] outerAngle: [innerAngle, 180] But we wouldn't clamp them or otherwise enforce it. Instead we could add a sentence that the results are undefined (or maybe "unpredictable"?) if the angles are outside that range. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:06 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> Message-ID: On Fri, 6 Nov 2020 23:57:01 GMT, Kevin Rushforth wrote: > This is a direction vector similar to the rotation axis in Rotate, so using Point3D for this property seems most consistent. This is the current implementation. The only downside is that it's more difficult to use bindings with. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 22 17:43:06 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 22 Dec 2020 17:43:06 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> Message-ID: On Tue, 27 Oct 2020 23:50:08 GMT, Kevin Rushforth wrote: >> My preference would be for `SpotLight` to subclass `PointLight`. I also somewhat prefer the 1/2 angle (radius) rather than diameter to specify the spread angles (inner and outer). > > Not that it's all that relevant, but I will note that the (very old) Java 3D API also had [SpotLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/SpotLight.html) as a subclass of [PointLight](https://download.java.net/media/java3d/javadoc/1.5.0/javax/media/j3d/PointLight.html). Is the old implementation worth looking at, or is is completely different? I updated the API after subclassing `PointLight`. After we settle on it I will submit a CSR and we can move on to the implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:10 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:10 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 21:55:19 GMT, Kevin Rushforth wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API >> >> 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> CSR will be created when the API review is finished. >> >> ### Implementation >> >> I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). >> >> ### Performance >> >> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): >> >> Without the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.5 >> mesh 200: 111.5 >> >> With the falloff == 0 branching: >> sphere 1000 subdivisions: 120 >> mesh 5000: 9.3 >> mesh 200: 112.5 >> >> Ubuntu 20: >> With the patch: >> Mesh 200: 60 fps >> Mesh 5000: 15 fps >> Sphere 1000: 60 fps >> >> Without the patch (master branch) >> Mesh 200: 60 fps >> Mesh 5000: 16.3 fps >> Sphere 1000: 60 fps >> >> So no major changes. I will repeat these tests to make sure there was no mistake. > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 163: > >> 161: * receive no light. At smaller angles, the light intensity starts to increase. >> 162: *

>> 163: * The angle is clamped between 0 and 180. > > between innerAngle and 180? If we aren't going to clamp the values to be between `innerAngle` and 180 then this sentence should just be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Tue Dec 22 17:43:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Dec 2020 17:43:06 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types In-Reply-To: References: <8JuREWJeGhY7VwH-PWvs_-AGMEoLJxDkgxy9NlGbEvU=.cc4b4c41-10e8-42ae-8443-f88b151803cc@github.com> <-TlbazE_L2BB8A11dkqYozstOf1Ga4eXN5akxjcmhUk=.a44fa80e-5a80-4f9d-9acf-1aaed9dff889@github.com> Message-ID: On Fri, 30 Oct 2020 11:52:03 GMT, Nir Lisker wrote: > Is the old implementation worth looking at, or is is completely different? No, the Java 3D implementation was done using fixed-function pipeline (not shaders), so not really a good starting point. > Another API point is how to implement the direction - a Point3D or 3 doubles. Yes, we need to sort this one out for `SpotLight`. This is a direction vector similar to the rotation axis in `Rotate`, so using `Point3D` for this property seems most consistent. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From swpalmer at gmail.com Tue Dec 22 20:22:15 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 22 Dec 2020 15:22:15 -0500 Subject: list digest In-Reply-To: References: Message-ID: You might consider supplying your own sortPolicy (see sortPolicyProperty ). It could remove your "total" object, call the DEFAULT_SORT_POLICY and then add your total object back. Scott On Sun, Dec 20, 2020 at 4:50 PM Chuck Davis wrote: > Thanks guys for the link to the digest. > > I've looked through a couple of years and find nothing that addresses my > interest. As background, I write financial applications and usually when a > user selects something to display in a table it's because they're > interested in the total amount. And it is easy to provide that information > to them on the initial display. > > The rub comes when they select a column header or otherwise sort the > table. I need, first of all, to eliminate the total object from the model > (this is done easily by listening to the onSort property). Then, after the > sort is complete I need to add the total object back to the model. If I > don't eliminate the total object from the model the sort puts it in very > strange places..... What I need to know is when the sort is complete so > that I can add the total object back into the model and get it displayed. > > I've been looking at the TableView source and find the following code near > the start of the sort() method: > SortEvent> sortEvent = new SortEvent<>(TableView.this, > TableView.this); > fireEvent(sortEvent); > > It seems to me it would be trivial to invent another event type > SORT_COMPLETE and emit it at the end of the sort() method to notify the > program that the sort has been completed. And that would certainly solve a > major headache with showing a total amount for financial tables. What I > don't know is whether the sort is done on another thread in which case a > Future would probably be required to detect the sort completion. > > If this were implemented we programmers would be able to detect both the > start and completion of a sort of the table and proceed accordingly. It > would be VERY helpful. > > Thanks for reading. > From cjgunzel at gmail.com Tue Dec 22 20:57:32 2020 From: cjgunzel at gmail.com (Chuck Davis) Date: Tue, 22 Dec 2020 12:57:32 -0800 Subject: list digest In-Reply-To: References: Message-ID: Thanks Scott for the advice. I played a little with that but didn't think about using it in that way. I'll investigate more. I think it is a work around that should not be necessary but I'll check'er out. Thanks. On Tue, Dec 22, 2020 at 12:22 PM Scott Palmer wrote: > You might consider supplying your own sortPolicy (see sortPolicyProperty > ). > It could remove your "total" object, call the DEFAULT_SORT_POLICY > and > then add your total object back. > > Scott > > On Sun, Dec 20, 2020 at 4:50 PM Chuck Davis wrote: > >> Thanks guys for the link to the digest. >> >> I've looked through a couple of years and find nothing that addresses my >> interest. As background, I write financial applications and usually when >> a >> user selects something to display in a table it's because they're >> interested in the total amount. And it is easy to provide that >> information >> to them on the initial display. >> >> The rub comes when they select a column header or otherwise sort the >> table. I need, first of all, to eliminate the total object from the model >> (this is done easily by listening to the onSort property). Then, after >> the >> sort is complete I need to add the total object back to the model. If I >> don't eliminate the total object from the model the sort puts it in very >> strange places..... What I need to know is when the sort is complete so >> that I can add the total object back into the model and get it displayed. >> >> I've been looking at the TableView source and find the following code near >> the start of the sort() method: >> SortEvent> sortEvent = new >> SortEvent<>(TableView.this, >> TableView.this); >> fireEvent(sortEvent); >> >> It seems to me it would be trivial to invent another event type >> SORT_COMPLETE and emit it at the end of the sort() method to notify the >> program that the sort has been completed. And that would certainly solve >> a >> major headache with showing a total amount for financial tables. What I >> don't know is whether the sort is done on another thread in which case a >> Future would probably be required to detect the sort completion. >> >> If this were implemented we programmers would be able to detect both the >> start and completion of a sort of the table and proceed accordingly. It >> would be VERY helpful. >> >> Thanks for reading. >> > From kcr at openjdk.java.net Wed Dec 23 00:01:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Dec 2020 00:01:02 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v5] In-Reply-To: References: Message-ID: On Mon, 21 Dec 2020 18:49:11 GMT, Frederic Thevenet wrote: >> This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). >> >> Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). >> >> The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: >> >> - The node, or one of its parents, must have set `Node::cacheProperty` to `true` >> >> - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) >> >> - The effective layout X or Y coordinates for the cached node must be != 0; >> >> Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. >> >> Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. >> >> Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Added a test The test and the fix look good. I left a couple inline comments. modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 947: > 945: > 946: /** > 947: * Cached snapScale values, used for to determine if snapped cached insets values Minor typo: `for to` --> `to` modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 1825: > 1823: public final double snappedTopInset() { > 1824: // invalidate the cached values for snapped inset dimensions > 1825: // if the screen scale changed since they were last computed. Minor: Maybe copy this comment to the other 4 methods for consistency? tests/system/src/test/java/test/javafx/scene/UIRenderSnapToPixelTest.java line 77: > 75: if (node instanceof ScrollPane) { > 76: var sp = (ScrollPane) node; > 77: Assert.assertEquals("Top inset not snapped to pixel", 0, (sp.snappedTopInset() * scale) % 1, 0.0001); This could fail if snapped inset * scale is just less than an integer pixel. For example, if `sp.snappedTopInset() * scale` is 1.999999, then `(sp.snappedTopInset() * scale) % 1` would be 0.999999 which would fail. I suggest adding an epsilon value (perhaps 0.00001 so it won't affect the delta comparison) before doing the modulo. ------------- PR: https://git.openjdk.java.net/jfx/pull/308 From nlisker at openjdk.java.net Wed Dec 23 02:54:13 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 23 Dec 2020 02:54:13 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v2] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update to the d3d pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/40de36fe..dc37e2e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=00-01 Stats: 17 lines in 6 files changed: 0 ins; 15 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From fthevenet at openjdk.java.net Wed Dec 23 09:55:14 2020 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 23 Dec 2020 09:55:14 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: > This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). > > Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). > > The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to `true` > > - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. > > Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. > > Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Addressed comments from review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/308/files - new: https://git.openjdk.java.net/jfx/pull/308/files/969f23f0..12db9288 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=308&range=04-05 Stats: 12 lines in 2 files changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/308/head:pull/308 PR: https://git.openjdk.java.net/jfx/pull/308 From kcr at openjdk.java.net Wed Dec 23 16:52:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Dec 2020 16:52:57 GMT Subject: RFR: 8211294: ScrollPane content is blurry with 125% scaling [v6] In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 09:55:14 GMT, Frederic Thevenet wrote: >> This PR aims to fix the blurriness to sometimes affects some controls (such as TextArea) in a scene when rendered with a scaling factor that is not an integer (typically when viewed on a HiDPI screen with a 125%, 150% or 175% output scaling). >> >> Please note that regardless of what the JBS issue (and therefore the title of this PR) states, this does not appear to be a Windows only issue as I have observed the same issue on Linux (Ubuntu 20.04). >> >> The following conditions are necessary for the blurriness to appear, but do not guarantee that it will: >> >> - The node, or one of its parents, must have set `Node::cacheProperty` to `true` >> >> - The scaling factor (as detected automatically or explicitly set via glass.win/gtk.uiScale) must be a non integer number (e.g. 1.25, 1.5, 175) >> >> - The effective layout X or Y coordinates for the cached node must be != 0; >> >> Under these conditions, the translate coordinates for the transform used when the cached image for a node is rendered to the screen may be non integer numbers, which is the cause for the blurriness. >> >> Based on these observations, this PR fixes the issue by simply rounding the translate coordinates (using `Math.round`) before the transform is applied in `renderCacheToScreen()` and as far as I can tell, it fixes the blurriness in all the previously affected applications (both trivial test cases or with complex scenegraphs) and does not appear to introduce other noticeable visual artifacts. >> >> Still, there might be a better place somewhere else higher up in the call chain where this should be addressed as it could maybe be the root cause for other rendering glitches, though I'm not yet familiar enough with the code to see if it is really the case. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Addressed comments from review Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/308 From kevin.rushforth at oracle.com Wed Dec 23 22:56:33 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Dec 2020 14:56:33 -0800 Subject: Access to private EventHandlers In-Reply-To: References: Message-ID: <2962c544-5fa2-d36a-6b57-6588481c6e2b@oracle.com> Yes, this could be useful. I would characterize this as an enhancement request to "add additional event handlers" rather than "access private event handlers", though. It would be good to be informed by what the current implementation happens to do. As was done when creating the public API for Robot, any new API would need to be designed to fit into the existing event framework, probably extending from javafx.input.Event. So it's better to think of this in terms of coming up with a new API that provides the needed events to applications, rather than in terms of moving an existing package-scope class to a public package. We likely wouldn't want / need to duplicate all of what it in the current interface. Other considerations to think about: 1) What should the API look like? What will applications do with those events? 2) Is this something that makes sense on more than just macOS? And if not, how useful is it to most applications? If it's still useful, do we need some way at runtime to let apps know whether it is available (beyond just documenting that it is platform-specific)? 3) We have an open RFE for adding "desktop" like functionality to JavaFX. It's not high on the list of things likely to be worked on, but we would want to consider how any new event handler would fit into such if/when we ever did it. -- Kevin On 12/17/2020 10:57 AM, Jos? Pereda wrote: > While chasing down an issue on Mac with application events, we have noticed > that there is some code under a private package that apparently it is > supposed to be used by developers, which of course it is discouraged: > com.sun.glass.ui.Application:EventHandler [1] is a public static inner > class under a private package, that is added to the Application class for > subclassing. > > So far, only QuantumToolkit does subclass it [2] (just for Quit action and > Theme changed events). However the EventHandler class has more methods for > listening to MacOS/iOS application events. > > While most of those events happen before the app starts (and it wouldn't > make sense to try to listen to them app-wise), in particular, the > OpenFilesAction event is forwarded [3] when a second EventHandler is set. > Other events like resign/become active actions can be listened to as well. > > A developer could provide a subclass of such EventHandler if it were public > API, but so far, that has to be done accessing private API. > > At this point, and following on this other thread [4] that discussed a > similar issue with EventHandlerManager, we should start considering the > design of new public API that could provide developers with access to such > events, with considerations to possible platform specifics. > > Regards, > Jose > > > [1] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L45 > [2] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java#L352 > [3] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java#L346 > [4] > https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-October/027909.html > > > > -- From kevin.rushforth at oracle.com Wed Dec 23 23:38:56 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Dec 2020 15:38:56 -0800 Subject: Glass backends - xGravity and yGravity In-Reply-To: References: Message-ID: <47a56371-ec9f-f50f-9fd9-09e84a3b7493@oracle.com> I missed seeing this earlier. I can confirm that xGravity and yGravity are not used at all on Mac or Windows. I don't know why the Linux glass backend uses it, but it may have something to do with the asynchronous nature of X11. If you ignore it, does it change anything relating to the initial positioning? The only place I see x/yGravity set to a non-zero value is in the centerOnScreen method. -- Kevin On 12/14/2020 2:26 PM, Thiago Milczarek Say?o wrote: > Hi, > > Question: Are the xGravity and yGravity still in use? > > Windows glass backend seems to ignore it, and I can't think of any scenario > where this would be used on Linux glass backend. > > package com.sun.glass.ui; > > > public abstract class Window { > ...... > > /** > * Sets the window bounds to the specified values. > * > * Gravity values specify how to correct window location if only its size > * changes (for example when stage decorations are added). User initiated > * resizing should be ignored and must not influence window location through > * this mechanism. > * > * The corresponding correction formulas are: > * > * {@code x -= xGravity * deltaW} > * {@code y -= yGravity * deltaH} > * > * @param x the new window horizontal position, ignored if xSet is set to > * false > * @param y the new window vertical position, ignored if ySet is set to > * false > * @param xSet indicates whether the x parameter is valid > * @param ySet indicates whether the y parameter is valid > * @param w the new window width, ignored if set to -1 > * @param h the new window height, ignored if set to -1 > * @param cw the new window content width, ignored if set to -1 > * @param ch the new window content height, ignored if set to -1 > * @param xGravity the xGravity coefficient > * @param yGravity the yGravity coefficient > */ > public void setBounds(float x, float y, boolean xSet, boolean ySet, > float w, float h, float cw, float ch, > float xGravity, float yGravity) From kcr at openjdk.java.net Thu Dec 24 00:35:56 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Dec 2020 00:35:56 GMT Subject: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v4] In-Reply-To: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> References: <8Sfjd_giA9HEnBNhkPW0hTijcze_4KNYeoggt24PgTQ=.af8a0648-9155-442f-ba58-c8a950bb05be@github.com> Message-ID: <-fH6EW-r_Mv_9-yhjg7Ukv1y7BTl6i1lsNegE6d-nfQ=.dce56c08-f6ad-4f78-9c19-ac93028f1516@github.com> On Wed, 25 Nov 2020 15:56:05 GMT, Jonathan Vusich wrote: >> While this does fix the specific problem, it introduces a new one. If the labels are initially too big, but after resizing the window would now fit, it does not recompute the orientation. This means that you are left with labels that are rotated even when they don't need to be. > > @kevinrushforth Thank you for catching that. Do you think it would be acceptable to simply rotate the labels back to zero if the user expands the window? The fix seems fine to me. I recommend also adding a test for a vertical axis. ------------- PR: https://git.openjdk.java.net/jfx/pull/342 From thiago.sayao at gmail.com Thu Dec 24 00:59:31 2020 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 23 Dec 2020 21:59:31 -0300 Subject: Glass backends - xGravity and yGravity In-Reply-To: <47a56371-ec9f-f50f-9fd9-09e84a3b7493@oracle.com> References: <47a56371-ec9f-f50f-9fd9-09e84a3b7493@oracle.com> Message-ID: Thanks for the reply. It does not change the initial window position or the centerOnScreen() positioning. > * Gravity values specify how to correct window location if only its size > * changes (for example when stage decorations are added). User initiated > * resizing should be ignored and must not influence window location through > * this mechanism. This says "when stage decorations are added". Are there any scenarios where decorations are added after the window is shown? I think it's not possible, except fullscreen/unfullscren (but it does not apply). Decoration sizes are up to the window manager, so there is no way the "java side" would know about them. Cheers. Em qua., 23 de dez. de 2020 ?s 20:41, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > I missed seeing this earlier. I can confirm that xGravity and yGravity > are not used at all on Mac or Windows. I don't know why the Linux glass > backend uses it, but it may have something to do with the asynchronous > nature of X11. If you ignore it, does it change anything relating to the > initial positioning? The only place I see x/yGravity set to a non-zero > value is in the centerOnScreen method. > > -- Kevin > > > On 12/14/2020 2:26 PM, Thiago Milczarek Say?o wrote: > > Hi, > > > > Question: Are the xGravity and yGravity still in use? > > > > Windows glass backend seems to ignore it, and I can't think of any > scenario > > where this would be used on Linux glass backend. > > > > package com.sun.glass.ui; > > > > > > public abstract class Window { > > ...... > > > > /** > > * Sets the window bounds to the specified values. > > * > > * Gravity values specify how to correct window location if only its > size > > * changes (for example when stage decorations are added). User > initiated > > * resizing should be ignored and must not influence window location > through > > * this mechanism. > > * > > * The corresponding correction formulas are: > > * > > * {@code x -= xGravity * deltaW} > > * {@code y -= yGravity * deltaH} > > * > > * @param x the new window horizontal position, ignored if xSet is set > to > > * false > > * @param y the new window vertical position, ignored if ySet is set to > > * false > > * @param xSet indicates whether the x parameter is valid > > * @param ySet indicates whether the y parameter is valid > > * @param w the new window width, ignored if set to -1 > > * @param h the new window height, ignored if set to -1 > > * @param cw the new window content width, ignored if set to -1 > > * @param ch the new window content height, ignored if set to -1 > > * @param xGravity the xGravity coefficient > > * @param yGravity the yGravity coefficient > > */ > > public void setBounds(float x, float y, boolean xSet, boolean ySet, > > float w, float h, float cw, float ch, > > float xGravity, float yGravity) > > From nlisker at openjdk.java.net Thu Dec 24 03:55:11 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 24 Dec 2020 03:55:11 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v3] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update to the d3d pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/dc37e2e6..b3ca78ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From jpereda at openjdk.java.net Tue Dec 29 09:52:58 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 29 Dec 2020 09:52:58 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> Message-ID: On Tue, 22 Sep 2020 09:14:31 GMT, yosbits wrote: >> yosbits has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > I commented. I've run SelectListView and SelectTableView tests and both run fine. As for the SelectTableView test, with 700_000 rows, when there is no selection, pressing SelectToEnd takes around 3.1 seconds, as expected. However, if there is one single row selected, after pressing SelectToEnd, the selection doesn't complete, and I have to abort and quit the app. Instead of: tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); this: int focusedIndex = tableView.getSelectionModel().getFocusedIndex(); tableView.getSelectionModel().clearSelection(); tableView.getSelectionModel().selectRange(focusedIndex, tableView.getItems().size()); seems to work and times are again around 3 seconds or less. Maybe you can check why that is happening? And about the test discussion above, I understand that running the included tests as part of the automated test wouldn't make much sense (as these can take too long). However, maybe these could be added as unit tests with a reduced number of item/rows. Instead of measuring performance (selection times would depend on each machine), I'd say you could simply verify that selection works as expected. While most of the changes are just about caching `size()`, the new implementation of `MultipleSelectionModelBase::indexOf` adds some new code that should be tested, as part of the unit tests, again not for performance, but to assert it returns the expected values. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From nlisker at openjdk.java.net Tue Dec 29 11:50:15 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Dec 2020 11:50:15 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v4] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update to d3d pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/b3ca78ad..0c6dc9bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=02-03 Stats: 80 lines in 7 files changed: 53 ins; 12 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 29 11:57:15 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Dec 2020 11:57:15 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v5] In-Reply-To: References: Message-ID: <_VnxIFJxfTbR2QH_B4NtIVsE0wtCS78w52VcfSmOsEc=.a89e39a7-8536-4b92-b6c7-38844aeba54d@github.com> > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update default values ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/0c6dc9bd..9d06099d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=03-04 Stats: 57 lines in 4 files changed: 35 ins; 13 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 29 12:03:14 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Dec 2020 12:03:14 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v6] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update for the manual test utility ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/9d06099d..1bdfc1d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=04-05 Stats: 94 lines in 5 files changed: 62 ins; 10 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Tue Dec 29 15:03:15 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 29 Dec 2020 15:03:15 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API > > 1. Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > 2. The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > CSR will be created when the API review is finished. > > ### Implementation > > I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies the shader a lot and removes branching over the light type. This is covered anyway by a possible optimization in the pixel shader, which I've noted in an inline comment, that skips the spotlight computation if `falloff` is 0 (this is the case for non-spotlights). > > ### Performance > > Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114): > > Without the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.5 > mesh 200: 111.5 > > With the `falloff != 0` branching: > sphere 1000 subdivisions: 120 > mesh 5000: 9.3 > mesh 200: 112.5 > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no mistake. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update to the gl pipeline ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/1bdfc1d6..e699127d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=05-06 Stats: 205 lines in 6 files changed: 139 ins; 22 del; 44 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From github.com+7517141+yososs at openjdk.java.net Wed Dec 30 08:41:55 2020 From: github.com+7517141+yososs at openjdk.java.net (yosbits) Date: Wed, 30 Dec 2020 08:41:55 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> Message-ID: On Tue, 29 Dec 2020 09:50:42 GMT, Jose Pereda wrote: >> I commented. > > I've run SelectListView and SelectTableView tests and both run fine. As for the SelectTableView test, with 700_000 rows, when there is no selection, pressing SelectToEnd takes around 3.1 seconds, as expected. However, if there is one single row selected, after pressing SelectToEnd, the selection doesn't complete, and I have to abort and quit the app. > > Instead of: > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > this: > int focusedIndex = tableView.getSelectionModel().getFocusedIndex(); > tableView.getSelectionModel().clearSelection(); > tableView.getSelectionModel().selectRange(focusedIndex, tableView.getItems().size()); > seems to work and times are again around 3 seconds or less. > > Maybe you can check why that is happening? > > And about the test discussion above, I understand that running the included tests as part of the automated test wouldn't make much sense (as these can take too long). However, maybe these could be added as unit tests with a reduced number of item/rows. Instead of measuring performance (selection times would depend on each machine), I'd say you could simply verify that selection works as expected. > > While most of the changes are just about caching `size()`, the new implementation of `MultipleSelectionModelBase::indexOf` adds some new code that should be tested, as part of the unit tests, again not for performance, but to assert it returns the expected values. As an overview, the new implementation can handle selectRange up to 50_000 records. This assumes general manual operation. However, after clearing the selection (a rare operation in manual operation), it is as efficient as selectAll. However, this is a two-time change. The response difference is caused by the next conditional branch (size == 0) of SortedList. This will be the next hotspot to improve as seen by this improvement. I can't include it in this PR because I don't have time to work. I haven't tried it, but if I change the per-record insertToMapping call of this method to per-range setAllToMapping, the performance seems to be around selectAll. javafx.collections.transformation.SortedList.java SortedList.java private void addRemove(Change c) { if (c.getFrom() == 0 && c.getRemovedSize() == size) { removeAllFromMapping(); } else { for (int i = 0, sz = c.getRemovedSize(); i < sz; ++i) { removeFromMapping(c.getFrom(), c.getRemoved().get(i)); } } if (size == 0) { setAllToMapping(c.getList(), c.getTo()); // This is basically equivalent to getAddedSubList // as size is 0, only valid "from" is also 0 } else { for (int i = c.getFrom(), to = c.getTo(); i < to; ++i) { insertToMapping(c.getList().get(i), i); } } } ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From kavedaa at gmail.com Wed Dec 30 15:50:51 2020 From: kavedaa at gmail.com (Knut Arne Vedaa) Date: Wed, 30 Dec 2020 16:50:51 +0100 Subject: JDK-8195750 - FilteredList Message-ID: <9a1832d7-ff4d-28cc-d496-9ebda039690e@gmail.com> Does this bug: https://bugs.openjdk.java.net/browse/JDK-8195750 have any chance of being fixed? It's been open for almost 3 years and it essentially makes FilteredList unusable. Knut Arne Vedaa From nlisker at openjdk.java.net Thu Dec 31 10:16:57 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 31 Dec 2020 10:16:57 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v7] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 22:00:07 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update to the gl pipeline > > I think the API looks good with a few comments about valid ranges. The default direction was updated to (0, 0, 1) to points away from the camera instead of (0, 0, -1). I think it makes more sense. I also updated the default outer angle to 30 instead of 90. I think that it is a more reasonable value for the use of a spotlight. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From sproket at videotron.ca Thu Dec 31 23:38:42 2020 From: sproket at videotron.ca (Dan Howard) Date: Thu, 31 Dec 2020 18:38:42 -0500 Subject: JDK-8195750 - FilteredList In-Reply-To: References: Message-ID: Second. On 12/30/2020 10:50 AM, Knut Arne Vedaa wrote: > Does this bug: > > https://bugs.openjdk.java.net/browse/JDK-8195750 > > have any chance of being fixed? It's been open for almost 3 years and > it essentially makes FilteredList unusable. > > > Knut Arne Vedaa